You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Me and @Mark-Simulacrum with our release hats have been thinking on how to securely expand the permissions to publish new releases to the wider release team. This became possible thanks to the effort from both Mark (mostly) and me (a bit) to automate more and more of the rustc release process, to the point that no privileged access is required now except for actually starting CodeBuild.
We had a discussion a few weeks ago on #t-release about how to securely grant this access, because just granting the permission to invoke the CodeBuild job would be too risky1.
So the solution that we came up with is to create a new start-release lambda that only accepts the action you want to do (like publish-rust-prod-stable) and is then responsible to invoke CodeBuild. Something similar to the existing promote-release.py but with more guardrails. Then we'd have a small wrapper to invoke the lambda (that I think would be better placed in the rust-lang/release-team repository). This extra layer of indirection would provide the necessary protection to allow t-release to safely start releases.
We would then change promote-release.py to be a more flexible and less opinionated tool to start the promote-release job with arbitrary commands, to allow infra-admins to bypass the restrictions of the lambda in the rare case it's needed.
The content you are editing has changed. Please copy your edits and refresh the page.
The permission to start a CodeBuild job not only allows to start the job, but also override anything about the build, including the environment variables and the commands being executed. We actually use this to change the environment variables and configure promote-release. Unrestricted access to this though would allow exfiltrating secrets, as an attacker could replace the promote-release invocation. ↩
The text was updated successfully, but these errors were encountered:
Me and @Mark-Simulacrum with our release hats have been thinking on how to securely expand the permissions to publish new releases to the wider release team. This became possible thanks to the effort from both Mark (mostly) and me (a bit) to automate more and more of the rustc release process, to the point that no privileged access is required now except for actually starting CodeBuild.
We had a discussion a few weeks ago on #t-release about how to securely grant this access, because just granting the permission to invoke the CodeBuild job would be too risky1.
So the solution that we came up with is to create a new
start-release
lambda that only accepts the action you want to do (likepublish-rust-prod-stable
) and is then responsible to invoke CodeBuild. Something similar to the existingpromote-release.py
but with more guardrails. Then we'd have a small wrapper to invoke the lambda (that I think would be better placed in the rust-lang/release-team repository). This extra layer of indirection would provide the necessary protection to allow t-release to safely start releases.We would then change
promote-release.py
to be a more flexible and less opinionated tool to start the promote-release job with arbitrary commands, to allow infra-admins to bypass the restrictions of the lambda in the rare case it's needed.Tasks
start-release
lambda #441Footnotes
The permission to start a CodeBuild job not only allows to start the job, but also override anything about the build, including the environment variables and the commands being executed. We actually use this to change the environment variables and configure promote-release. Unrestricted access to this though would allow exfiltrating secrets, as an attacker could replace the promote-release invocation. ↩
The text was updated successfully, but these errors were encountered: