Use-case:
Command-line application (which is deployed to a 3rd party machine) needs to be able to download a tarball copy of a private repo that belongs to an organization via the GitHub API (v3)
Application should only be able to access this one private repo and no other repos with read-only permission.
I have been able to accomplish (1) by creating an authorization for the application after registering a client_id/secret on my github account. However, it does not seem that the tokens returned by the authorization allow read-only access to the repo nor are they restricted to one repo (e.g. one could potentially use the token to modify this repo along with others belonging to the organization).
Is it possible to restrict access via the proper scope? I don't see anything relevant in the API docs (https://developer.github.com/v3/oauth/#scopes).
When you enable GitHub Actions, GitHub installs a GitHub App on your repository. The GITHUB_TOKEN secret is a GitHub App installation access token. You can use the installation access token to authenticate on behalf of the GitHub App installed on your repository.
Obtaining your GitHub personal access tokenSign in to your GitHub account. Change the settings for your GitHub profile by clicking your profile image in the upper right, and then click Settings. At the bottom of the left menu, in the Developer settings section, click the Personal access tokens link.
I don't believe you can restrict github OAuth tokens in that way. The github docs for OAuth say that
While Git over HTTP with OAuth reduces friction for some types of applications, keep in mind that unlike deploy keys, OAuth tokens work for any repository for which the user has access.
So while you can limit the scope of the token in terms of the types of activities, you can't limit it to a subset of repos.
Deploy keys can be restricted to a single repo, but allow write access.
The obvious tactic (as mentioned by Thomas) is to create a dummy account that represents the application. Given the goals of OAuth, this might be a better workflow in any case -- it'll let you easily change the permissions the app has as if it were in fact a user.
Github even mentions/endorses this strategy explicitly, calling them machine users.
Deploy keys are the way to go.
By default they don't allow write access and they are scoped to the specific repository (unlike the GitHub personal access token). So you can now generate a private/public key pair, set one as read/pull only deploy key on a single repository in GitHub and use the private key in your CI.
For instance run a bash script:
eval "$(ssh-agent -s)"; ssh-add <your private deploy key>;
Now your CI has rights to access private repo's during the build.
You can add a Deploy key by going to your repository on Github and then clicking Settings > Deploy keys > Add deploy key
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With