feat(auth): support Workload Identity Federation for Artifact Registry - #163
Closed
lucaghersi wants to merge 1 commit into
Closed
lucaghersi wants to merge 1 commit into
lucaghersi wants to merge 1 commit into
Conversation
|
All contributors have signed the CLA ✍️ ✅ |
Author
|
I have read the CLA Document and I hereby sign the CLA |
This was referenced Sep 14, 2026
lucaghersi
force-pushed
the
gar-workload-identity-auth
branch
from
September 14, 2026 15:36
2c7f44d to
883b8d0
Compare
Adds gcp-workload-identity-provider and gcp-service-account as an alternative to docker-username / docker-password. When both are set the action exchanges the job's OIDC token for a short-lived Google access token and logs in with it, so pushing to Artifact Registry needs no long-lived key. The calling job must grant permissions: id-token: write, which a composite action cannot request for itself. Artifact Registry accepts that token as a basic-auth password under the fixed username oauth2accesstoken, so the retag step keeps working against the registry v2 API without changes. The split is deliberate: the script decides whether authentication is possible, and the steps select the credential inline. Neither half of a credential passes through a step output or the environment file. The three steps previously gated on docker-username and docker-password now share that resolved flag, so they run under either credential source. Half-configured credentials now stop the run instead of skipping the build. A username with no password, or a provider with no service account, are what a mistyped secret name looks like, and skipping the build there left the job green while the deployment went stale. Each case names the missing half. Supplying no credentials at all stays a warning: that is the documented deploy-only usage. Both inputs are left without a default on purpose: this action is public, and a default would make every caller attempt Google authentication and fail any job that has not granted id-token: write. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
lucaghersi
force-pushed
the
gar-workload-identity-auth
branch
from
September 14, 2026 15:42
883b8d0 to
215c331
Compare
3 tasks
Author
|
Not needed. Artifact Registry accepts a Google access token as a basic-auth password under the fixed username oauth2accesstoken, so this action works against GAR as it already is — the caller mints the token and passes it as docker-password. Federation now lives in one place, Staffbase/gha-workflows#511, and this action stays unaware of Google. That also removes the release dependency: no version bump is needed for the migration. The one independently useful change here was failing on half-configured credentials instead of silently skipping the build. Worth reopening as its own PR if someone wants it. |
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
1 participant
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.
Type of Change
Description
Goal: let this action push to Google Artifact Registry without a long-lived key, as the first step of moving off Harbor.
Adds
gcp-workload-identity-provider+gcp-service-account. When both are set, the action exchanges the job's OIDC token for a short-lived Google access token and logs in with that. GAR accepts it as a basic-auth password under the fixed usernameoauth2accesstoken, soretag-image.shneeds no changes — it keeps working against the registry v2 API.Federation only. A service account key input was considered and dropped: Staffbase is migrating straight to Workload Identity Federation, and a public action should not advertise a long-lived-credential path that its own consumers have rejected.
Also fixes a silent failure. Half-configured credentials (username with no password, provider with no service account) used to skip the build and leave the job green while the deployment went stale. They now fail with the missing half named — including the
id-token: writecase, which is the first thing a caller will hit. Passing no credentials stays a warning: that is the documented deploy-only mode, where skipping is the point.How to review:
scripts/resolve-registry-auth.sh— the whole decision. The password never passes through a step output.action.yml— the new auth step, and the Buildx / Login / Build gates now sharing oneauthenticatedflag.tests/resolve-registry-auth.bats— 10 cases, all passing.mise run lintclean.Nothing changes for existing callers: no GCP inputs means the old path.
Not defaulted on purpose. This repo is public. A default would make every caller attempt Google auth and fail any job without
id-token: write. Staffbase-wide defaults live ingha-workflows.Consumers: Staffbase/gha-workflows#510 pins this action and is blocked on it being tagged. The GCP side is applied (Staffbase/infrastructure#17340).
Checklist
🤖 Generated with Claude Code