-
Notifications
You must be signed in to change notification settings - Fork 64
Add actions admin user impersonation via a --actions-admin-user flag #46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add actions admin user impersonation via a --actions-admin-user flag #46
Conversation
|
I can't request a review, since I don't have permissions in the repo, so I am going to tag people in the message instead. Tagging @talktopri you reopened the original issue @ajaykn you seem to be the maintainer @chrisgavin as you implemented the original logic @zarenner since you participated in the discussions about this long ago |
JacobMillward
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a few really minor suggestions. Otherwise, looks great!
jidicula
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Small change for return type idiom
README.md
Outdated
| **Arguments:** | ||
|
|
||
| - `actions-admin-user` _(optional)_ | ||
| The name of the Actions admin user, which will be used for updating the chosen action. If not specified `actions-admin` will be used. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a basic question:
When creating a personal access token include the repo and workflow scopes.
Include the site_admin scope (optional) if you want organizations to be created as necessary.
With this impersonation to work, what kind of access scope is needed ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When I tested this manually, I used the same scopes as I would normally would for the token: public_repo (or repo for the AE instance) and workflow and it worked for me.
So it seems like nothing is changing there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tested it with GHES today and for whatever reason, I needed to have a site_admin scope in my token. I will investigate further.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe impersonation should require the site_admin scope.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@chrisgavin should this also be true for the AE instances?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AFAIK, yes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just verified it. Here are the example runs with the recent code change:
GHES
A failed request with no site_admin permission:
> actions-sync sync \
> --cache-dir "/tmp/cache" \
> --destination-token "ghp_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" \
> --destination-url "https://ghaebuildXXXXXXXXXXXX.XXXXXXXX.net/" \
> --repo-name actions/setup-node
fetching * refs for actions/setup-node ...
Getting an impersonation token for `actions-admin`..
These are the scopes we have for the current token `repo, workflow`..
The current token doesn't have the `site_admin` scope. The impersonation request for GHES requres the `site_admin` permission to be able to impersonate. For GitHub AE it's not required.error obtaining the impersonation token: Failed to impersonate Actions admin user.: POST https://derwasp-03fbba5321ba8c306.qaboot.net/api/v3/admin/users/actions-admin/authorizations: 404 Not Found []
A successful request with the site_admin permission:
> actions-sync sync \
> --cache-dir "/tmp/cache" \
> --destination-token "ghp_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" \
> --destination-url "https://derwasp-XXXXXXXXXXXX.XXXXXXXX.net/" \
> --repo-name actions/setup-node
fetching * refs for actions/setup-node ...
Getting an impersonation token for `actions-admin`..
These are the scopes we have for the current token `repo, site_admin, workflow`..
Got the impersonation token for `actions-admin`..
syncing `actions/setup-node`
successfully synced `actions/setup-node`
GHAE
Note that there's no site_admin in the scopes, yet it works just fine.
> actions-sync sync \
> --cache-dir "/tmp/cache" \
> --destination-token "ghp_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" \
> --destination-url "https://ghaebuildXXXXXXXXXXXX.XXXXXXXX.net/" \
> --repo-name actions/setup-node
fetching * refs for actions/setup-node ...
Getting an impersonation token for `actions-admin`..
These are the scopes we have for the current token `repo, workflow`..
Running against GitHub AE, changing the repository scope to 'repo'..
Got the impersonation token for `actions-admin`..
syncing `actions/setup-node`
successfully synced `actions/setup-node`
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @derwasp , @chrisgavin for responses.
I think for GHAE as well, not sure why the behaviour is different, but i agree with @chrisgavin that GHAE instance also should have site_admin permissions
Otherwise, normal customers with less priviliges also be able to sync via impersonation ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ajaykn
Who can we verify this behavior with? Unless I am missing something, right now the GHAE instances clearly are not expecting the site_admin permission for the impersonation requests as I verified with the logs above.
I don't mind just asking for the site_admin permission in both cases, but I wanted to minimize the required permissions unless really necessary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@derwasp It seems, we are checking for site_admin even in codeql-sync tool.
https://github.com/github/codeql-action-sync-tool/blob/main/internal/push/push.go#L107
Can we do the same regardless of how it works in ghae.
Making sure site_admin permissions needed for impersonation for ghae as well.
And we can start conversation in slack channels like actions-on-ghae or ghae-engineering to see, why the impersonation logic working regardless of site_admin.
|
for whatever reason clicking "request review" from one person removed the review request from the other person 🤔 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tiniest of nits but otherwise LGTM
Same as in here https://github.com/github/codeql-action-sync-tool/blob/33463970b845ac4bb9e4cae6adc2a8b7cd6f6142/internal/push/push.go#L106-L113 Add a warning about the missing site_admin scope in the token Add a way to ignore the actions admin impersonation.
* Require the impersonation to be explicit with the --actions-admin-user flag * Reword the log messages to look the same way the existing messages are
kgrzebien
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
Nice review conversation, covering multiple topics 🚀
jidicula
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 🎸
Also, fixed casing in the text literals
37946df
* add a note to the readme * add a note to the autogenerated cli help
ajaykn
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me.
Thanks @derwasp for adding this enhancement.
I was wondering if we can add tests here
https://github.com/actions/actions-sync/blob/main/script/test-build#L129
Not sure if the current code design allows.
We can track separately.
Disclaimer
This the first PR in GO for me. I don't know how things are usually done.
Background
The
actions-syncapp seems to also be used for the GHAE instances sometimes. The issue there was that the default admin user doesn't have permission to the actions and the github orgs. The previous workaround was to temporarily add the admin user to the required orgs and then run the app, which is not really convenient for customers who don't have access to the instance console and therefore can't runghe-org-admin-promote.We already have an app which impersonates the
actions-adminuser, and this is how it was implemented: github/codeql-action-sync-tool#48This PR does something similar.
Proposed changes
--actions-admin-userwhich would accept the actions user. By default the flag is not set. To use the default value, a user has to passactions-adminto it. The logic is based on this. This flag is used to impersonate the actions admin user before attempting to push the repository. Note that this logic requires thesite_adminscope to be available in the token.Unrelated changes
.gitignorefileNotes
To manually test this, do the following:
ghae-adminuser.go build.actions-synccommand in your codespaces like so, wheredestination-tokenis the token for theghae-adminuser:Previously the output would look something like this: