pipelines-as-code
pipelines-as-code copied to clipboard
Github, fetching task from other repos via token
We want to let the user specify another org/repo to fetch the task from.
- resolver - https://github.com/tektoncd/community/blob/main/teps/0060-remote-resource-resolution.md#controller-makes-http-request-to-resolver-to-get-resources
Pros:
- Standard API
- Nothing to do from our side.
Cons:
- User has to manage a token, lifetime, scopes..
- not available now or for a few osp releases.
- url with k8 secret syntax : If the user specify a magic syntax to the url :
https://kubesecret:remote-url-secret@path/to/task.yaml
we can grab the remote-url-secret from the current namespace, and use the value of username/password from it and use the path..
Pros:
- Can be implemented easily
- Use the annotations as what we have currently.
Cons
- Not standard proof as where we want to go with upstream resolver.
- User has to manage a token, lifetime, scopes..
- via the app token -- We already have a token when doing GithubApps why don't we use it ?
We could but it's actually not easy.
The user send a payload from a fork user/repo to org/repo, the token generated have access to everything in “user” but not to private repo in the “org”. To get access to the private repo in that org (via api) we would need to generate a token for it and access.
We could perhaps offer an option :
GitHubAppsTokenAccessToEveryOrgInstalled - yes/no
what this option would do if enabled is when you request a remote task from a organisation/repo where the github apps has been installed, it will automatically generate a token for that organisation.
Or we could offer whitelists/blacklist too.
Pros:
- AutoMagick, users has nothing to do.
- No token to manage, all short lived tokens.
Cons:
- May be complicated.
- May raise eyebrows of security conscious people
- There is another use case with GHE, when we have GHE instance that are closed and needs a login, is the github apps token suffice to access the "public" repos behind that instance?