search

jupyterhub / gh-scoped-creds

Provide fine-grained push access to GitHub from a JupyterHub
BSD 3-Clause "New" or "Revised" License
25 stars 7 forks source link

Understanding GitHub permissions #5

Open consideRatio opened 2 years ago

consideRatio commented 2 years ago

There are two times that the end user via a GitHub website, and I don't yet understand what roles they have etc. To understand that is quite relevant for anyone being an admin of a hub that provides this if the admin gets questions from users.

I don't clearly understand the parts here. I've typically been very afraid of whenever I've accepted "act on behalf of you". But, I guess perhaps it's just "act on behalf of me" with restricted permissions based on how the application is installed for various repos.

Task to complete

Overview of procedure to understand better

Step 1 - An end-user installs the github application

This can be triggered by visiting https://github.com/apps/hub-jupytearth-org-github-integ.

image

Step 2 - An end-user authorize the application as initiated by github-app-auth-user CLI

This can be triggered by running github-app-auth-user, getting a device code, and opening https://github.com/login/device

image image image

yuvipanda commented 2 years ago

So the actual permissions granted are specified by the admin when they create the app itself. Step 1 grants permissions to the app to act on the repos, while step 2 grants permission for the app to act on behalf of the user on those particular repos - if they users don't have access to the repo they still can't push. So the effective permission requires that:

  1. GitHub app is created with correct scopes (push, pull)
  2. GitHub app is installed in the repos where we want end users to eventually push / pull
  3. Users authorize the app to act on their behalf, so users still need to (independently) have permissions to these repos.

I hope this helps! Should also be more clearly documented

consideRatio commented 2 years ago

Thanks @yuvipanda I think you summarized it as comprehensible as something this complex can be summarized!

Hmmm, so there is like two separate distinctions:

I don't yet understand this as clearly as I hope to, but I do understand it better thanks to your help @yuvipanda!

I think what I look to understand more clearly are the security implications in various scenarios, for example if a GitHub app developer is malicious, and what steps then are needed for that malicious GitHub app developer needs to get done to do harm - and how great that harm will be - and such questions.

yuvipanda commented 2 years ago

@consideRatio oooh, great question. I think the developer of the app could possibly write to the repos even without user authentication :| https://github.com/yuvipanda/git-credential-helpers relies on that to work with nbgitpuller on private repositories. We should make that clear.

consideRatio commented 2 years ago

Ah now i understand that project: 1 create an app 2 create a key (in app settings) to act as the app 3 declare permissions for app 4 install app on org/repo 5 use app credentials (via git cred. helper) to do what you want

Okay, so the app has permissions by itself.

Hmmmm, but in this case (github-app-user-auth) a user knowing the client-id (public) can use the app to generate credentials which is the intersection of the app credentials and the user credentials, and with github-app-user-auth, those stay with the end user rather than to be used by some server doing automation etc?

yuvipanda commented 2 years ago

@consideRatio yeah, so if you just know the client id, you can use it only in conjugation with user credentials to get access to repos with intersection of these permissions. You need access to the GitHub app's private key (not used in this repo) to get access without user authorization. So the presence of the github app ID acts purely as a constraint on what scopes the user's permissions are reduced to.

yuvipanda commented 2 years ago

No key is created here - only the (public) client ID is used.