Repository navigation
fix(ci): replace GITHUB_TOKEN by fine-grained one - #284
Conversation
upils
left a comment
upils
left a comment
There was a problem hiding this comment.
Thanks @cjdcordeiro. I was a bit worried because this workflow is executed in PRs, but this step is only executed for releases and the secret is only loaded for this specific step so I understand this is fine.
I see that we now have a growing collection of fine-grained tokens and it makes me wonder how much of a burden that will be to maintain. Maybe we should revisit at some point and use the permissions keyword at steps/jobs level to give a bit more permissions to the GITHUB_TOKEN when needed.
upils
added
Bug
|
niemeyer
left a comment
niemeyer
left a comment
There was a problem hiding this comment.
After the recent reports, Paul is right that this does feel suspect since it's basically having a secret on a workflow that looks like it's visible. Can we please at least have a comment in there outlining why this safe, so we keep these concerns in people's minds?
@niemeyer sure. Done in 0dd9027. It's a bit lengthy, but given that it's security-related, I feel like the level of detail is justified. |
niemeyer
left a comment
niemeyer
left a comment
There was a problem hiding this comment.
Thanks for the very detailed explanation.
|
After the recent changes to the `GITHUB_TOKEN`, the `build.yml` workflow can no longer push the release artifacts to the GitHub release: https://github.com/canonical/chisel/actions/runs/24026969346 This PR replaces the `GITHUB_TOKEN` with a new one, managed by us. This new token has `contents: write` permissions (similarly to the `GITHUB_TOKEN`), which are unfortunately broad, because GitHub does not offer fine-grained control for releases. The use of the secret is bound to a single step, which runs our own CI script, and always in the context of the base repo and on `release` events.
This is a CI security enhancement. In #284, we improved the security of the build CI workflow, ensuring the whole CI job wouldn't have unnecessary write permissions to the repository, instead shifting towards a fine grained personal token that would only be used within a single, conditional step that only ran on GitHub release events. NEW: this PR goes one step further by removing the need to have a bot account (which owns the aforementioned fine grained personal token) with write permissions in the repository's collaborators list. Instead, this PR splits the privileged step into a separate privileged job. This means the new job can use the ephemeral GITHUB_TOKEN to perform the privileged step, without giving unnecessary privileges to other jobs&steps of the workflow. Closes: #308
After the recent changes to the
GITHUB_TOKEN, thebuild.ymlworkflow can no longer push the release artifacts to the GitHub release: https://github.com/canonical/chisel/actions/runs/24026969346This PR replaces the
GITHUB_TOKENwith a new one, managed by us. This new token hascontents: writepermissions (similarly to theGITHUB_TOKEN), which are unfortunately broad, because GitHub does not offer fine-grained control for releases. The use of the secret is bound to a single step, which runs our own CI script, and always in the context of the base repo and onreleaseevents.