-
Notifications
You must be signed in to change notification settings - Fork 78
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
More clarity on id-token: write #329
Comments
Related issue full of confused people: |
Another issue about how confusing this is, closed without resolution: |
This is my fault. As I understand it, any contributor with write access could write to a repo a script which uses that token for nefarious purposes. It's also very hard to lock-down once you've enabled the github OIDC as an AuthN provider; with a third-party provider. The AuthZ you configure on the trusted (acting as) user is set, in the external system; so if I were to have a repo and manage it's infrastructure as code with Amazon AWS; then there are not great ways (I think environment is one) to restrict other workflows from say deleting an RDS. Recently a co-worker on a private repo, accidentally deleted a cognito user pool because they forgot to rebase. Not the type of change or risk I would like to invite for the discussed use-case of deploying github pages sites. The convenience seems to be at the cost of needing to make sure nobody points the barrel at anything you value. I Believe even less teams will use this responsibly than for novelty purposes; so I'd mentioned publicly to Simon that I am deeply distrustful of public repos using this as a mechanism. I would like to seek clarification on the claims and grants that
In the same issue Simon just linked, there is a link to some docs which state that |
Another closed issue about this (apparently I'm collecting them now): |
I filed an issue here with my own attempt at explaining this feature: |
There is even a When I use |
👋 I cannot talk for the questions about OIDC itself (though they are good ones and I see you have opened issues against the right repos already to get the confusions addressed). I can talk about GitHub Pages' specific use case for an OIDC token. First, you need to be aware of GitHub's automatic token authentication. This is the default GitHub API token (we usually refer as The To start a Pages deployment today, the In the context of building and deploying a Pages site with Actions, a regular token like In a perfect world, the Pages deploy API would not require an extra token. Unfortunately GitHub's API tokens predates the OIDC specification! |
Thanks for the explainer @yoannchaudet I'll be interested to see what the other permissions of id-token are or if it's just "hey, it's me GitHub". There must be lots more information in there, otherwise AWS etc would be wide open from any github user |
@Lewiscowles1986 The OIDC token is actually a big "hey it's me GitHub" (I like that image and I think you were spot on). It has no "permissions" associated on its own but it is minted in the context of an Action job and comes with a bunch of context. It's for third-party to decide if a token is allowed to do anything (say do something in AWS or Azure) – it's a trust relationship between GitHub and a third-party. GitHub Pages does use the token (like a third-party) to gate deployment but not alone, it has to be paired with a regular GitHub API token. They actually document further what the claims look like here which I find useful: https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#understanding-the-oidc-token. Anyhow, I agree that we can better elaborate about Pages' use of OIDC tokens in this repository. I'll track it on our side (Pages team). |
Ah I think I see something here that I will get updated. Looks like
@simonw so from this I think I might be able to lock down a token at the integration level so that third-party actions are unable to use the id-token to escalate from within a step; which next to user-stupidity is a primary concern. What if an actions provider used the fact that my job had an This definitely isn't immediately obvious; but I also wonder if it's too dry and boring for most users. |
It would also be nice if it was clearly documented that setting id-token:write reverts all other default permission scopes to "none." This is rather inconvenient, as there is no way to say "set id-token to write, but retain all previous permissions" (which could possibly have been set at the workflow level). As it is, using id-token:write requires one to explicitly supply permissions to scopes that were previously set to "read" or "write." |
If I'm reading these docs correctly, explicitly setting any permission will revoke access to almost everything that you don't set:
|
Should be in a callout box, everywhere folks are documenting just changing some flags. |
The README includes this comment:
deploy-pages/README.md
Line 32 in d6db901
Could we get more information on this?
It looks pretty scary.
id-token: write
implies that there is some deep and mysterious extra permission being granted to this workflow, potentially involving the ability to make writes and involving a token which might have permission to do other privileged things, maybe even at the account or organization level.It's really hard to figure out the security impact of this configuration from existing GitHub documentation.
The text was updated successfully, but these errors were encountered: