build/bake,build: add Chainguard OIDC keyless cgr.dev auth (opt-in)#196
Open
danilohorta wants to merge 3 commits into
Open
build/bake,build: add Chainguard OIDC keyless cgr.dev auth (opt-in)#196danilohorta wants to merge 3 commits into
danilohorta wants to merge 3 commits into
Conversation
Add four opt-in inputs to bake.yml and build.yml: chainguard-identity, chainguard-registry, chainguard-apk-host, chainguard-libraries-host. When chainguard-identity is set, the build and finalize jobs install chainctl via chainguard-dev/setup-chainctl@v0.5.1 and register it as a Docker credential helper for cgr.dev. The Chainguard pull token is minted inside the build/finalize job runners and never crosses the workflow_call boundary into the caller's registry-auths secret, where it would be silently stripped by GitHub's cross-job output masker (docker#146 documents the equivalent GCP WIF failure mode). No existing input changes; registry-auths continues to handle every static-credential registry as before and can be combined with chainguard-identity for multi-registry builds. Refs: docker#146
danilohorta
added a commit
to danilohorta/github-builder
that referenced
this pull request
May 12, 2026
…rtifacts When bake.yml runs as a reusable workflow on a fork, the OIDC identity in sigstore certificates and GHA cache signatures is the fork's path (https://github.com/<fork-owner>/github-builder/...), not docker/github-builder. The two verify policies in this file (verifyImageAttestations regex; cache.gha.verify.policy SAN glob) hardcode docker/github-builder, so any fork's run fails its own self-verification. Relax both to also accept this fork (danilohorta/github-builder) so the chainguard-keyless-auth changes stacked on feat/... can be exercised end-to-end from PhysicsXLtd/tmp-component-base while docker#196 is in review. This branch is the px-internal stacking branch — intentionally not on feat/chainguard-keyless-auth so PR docker#196 stays a clean upstream diff. Drop this branch once docker#196 merges and release.yml repins to the upstream tag.
|
Would love to see a similar thing done for GCP WIF. Just saying. Happy to submit PR, provided maintainers are open to that. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
bake.ymlandbuild.ymlcurrently only accept registry credentials via the staticregistry-authssecret, so any runtime-minted credential (Chainguard OIDC pull token, GCP WIF, AWS OIDC, …) has to be substituted across theworkflow_callboundary, where GitHub's cross-job output masker silently strips values that look like secrets.This PR adds three opt-in inputs (
chainguard-identity,chainguard-apk-host,chainguard-libraries-host) that drivechainguard-dev/setup-chainctl@v0.5.1inside thebuildandfinalizejobs so the Chainguard pull token is minted on the build runner and never leaves it.Issue: #146