stacklok
Least Permissive Scope Set for GitHub Authorization
Describe the issue
Currently, Minder requests the following permissions:
user:email repo read:packages write:packages workflow read:org
https://github.com/stacklok/minder/blob/8c4bab84f4f0838689139bca9d510a3edb6a3e99/internal/auth/oauth.go#L57-L62
Minder allows users to configure events but not scopes.
Just-in-time access or bare minimum scopes should be provided. Additional scopes can be requested as per the rules used by the user. Also, GH rate limiting of ten tokens should also be kept in mind.
To Reproduce
Follow getting started guide
What version are you using?
main branch
This might require significant changes as scopes are not fine-grained.
Note: Consider building a GitHub App instead of an OAuth app. GitHub Apps use fine-grained permissions instead of scopes, which give you more control over what your app can do. For more information, see "Differences between GitHub Apps and OAuth apps" and "About creating GitHub Apps."
We currently use OAuth apps. The point is how programmable permissions/features are in GH apps instead of OAuth apps.
I would be fine with grabbing the scopes from a config, server admins can then select what they want.
I did originally look at using GH apps, but hit issues trying to get it work with the CLI flow of registering a repo. GitHub requires users visit the permission grant page on github.com every time they install the app (to a new repo). I guess we could revisit this again as someone else might figure it out. The main consideration (afaik) is we have on one hand the concept of a user and group_id in minders controlplane and then a token granted via github - both of these need to be mapped somehow, while going from CLI -> minder controlplane -> github.com(auth server).
I would be fine with grabbing the scopes from a config, server admins can then select what they want.
There aren't a whole lot of options. Available scopes barely offer anything. There is no subset of repo scope which is useful for minder.
Minder may be open source, but granting read/write permissions to all public and private repos to any app is not something I would personally go for.
You might want to take a look at openssf allstar then (its a GH app).
Looks cool, would be awesome to get minder to do the same :)
Looks cool, would be awesome to get minder to do the same :)
Minder can do a lot more than allstar (bespoke / roll your own policies), but the permissions are what github provides us with. GitHub Apps are generally more of a end user marketplace offering. You either install them on everything and all future repos , or select repos. If you elect for select repos and want to later add another repo later on, you keep needing to go via their webpage portal (which breaks session continuity, as in minder we have our own concept of a user which will have its own rbac etc). We use the OAuth2 app as all we need to do then is provision a webhook to a repo (or remove it), and this can be done headless. A few of us are going to look into this more, to see if we can bend a GitHub App into what minder needs, but its very restrictive if you want to just enroll once and then register more repos later.
I agree with what you say. My only point is giving permission to every repo, that too read and write initially is really alarming for me. Agreed that GitHub Apps will break session continuity, and this is more problematic from GH side due to which other apps like CodeClimate are also affected.
Let's say there is some vulnerability (hypothetical situation) in OAuth apps, although all apps would be affected, but having an fine grained app would be better in that scenario, improbable but still worth securing.
The other option is to use a fine grained PAT token. I have not played with this part of the code for awhile, but I do remember @yrobla worked on this. Instead of going via the provider enroll flow, you just enroll your own token.
This may be interesting as GitHub App tokens are blocked for the registration of new repos, it needs to be a PAT. Thanks for raising this @Vyom-Yadav , I have been mindful for a while it would benefit revisiting at some point.
https://docs.github.com/en/rest/apps/installations?apiVersion=2022-11-28#add-a-repository-to-an-app-installation
We've switched to using a GitHub App, and we're looking at how to reduce permissions by using two GitHub apps (a read and a read-write) implementation.
The multiple GitHub Apps experience has some additional complications, so we've shelved it for now. The GitHub App does allow you to limit which repos within an org it applies to, which covers much of the original request.