build/bake,build: add Chainguard OIDC keyless cgr.dev auth (opt-in)#196
build/bake,build: add Chainguard OIDC keyless cgr.dev auth (opt-in)#196danilohorta 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
…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. |
|
I think this should be handled through the registry identities work in #243 rather than by adding Chainguard-specific top-level inputs to The problem this PR solves is the same class of problem tracked in #146: registry credentials that are minted at runtime should be created inside GitHub Builder, on the runner that needs them, without passing secret-looking values across the The intent of #243 is to introduce a generic So I think we should preserve the behavior goal from this PR, which is minting the Chainguard pull token on the build/finalize runner and avoiding masked cross-job outputs, but rework the interface on top of |
4 participants
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