registry-auths secret doesn't support dynamic tokens from GCP Workload Identity Federation

Description

Problem

When using build.yml with GCP Artifact Registry authenticated via Workload Identity Federation (WIF), there's no way to pass dynamically obtained access tokens to registry-auths.

WIF is the recommended keyless authentication method for GCP. It requires running google-github-actions/auth to obtain a short-lived access token at runtime — there are no static credentials to store as GitHub secrets.

Current approach (fails)

Since build.yml is a reusable workflow (runs in its own job context), WIF auth must happen in a preceding job that outputs the tokens:

jobs:
  auth:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write
    outputs:
      token: ${{ steps.auth.outputs.access_token }}
    steps:
      - id: auth
        uses: google-github-actions/auth@v3
        with:
          workload_identity_provider: 'projects/123/locations/global/workloadIdentityPools/github/providers/my-provider'
          service_account: 'my-sa@my-project.iam.gserviceaccount.com'
          token_format: access_token

  build:
    needs: auth
    uses: docker/github-builder/.github/workflows/build.yml@v1
    with:
      output: image
      push: true
      platforms: linux/amd64,linux/arm64
      meta-images: us-docker.pkg.dev/my-project/my-repo/my-app
    secrets:
      registry-auths: |
        - registry: us-docker.pkg.dev
          username: oauth2accesstoken
          password: ${{ needs.auth.outputs.token }}

Result

The build fails in Login to registry step with:

Warning: Can't add secret mask for empty string in ##[add-mask] command.
Login to us-docker.pkg.dev
Password required

Root cause

google-github-actions/auth masks the access token (via ::add-mask::). GitHub Actions sanitizes masked values in job outputs when they are passed to reusable workflow secrets inputs, resulting in empty strings.

Impact

This makes build.yml incompatible with any authentication flow that requires runtime token generation, including:

GCP Workload Identity Federation (recommended by Google, no static keys)
AWS OIDC provider (aws-actions/configure-aws-credentials) for ECR
Azure OIDC for ACR
Any setup where registry credentials are obtained dynamically via GitHub's OIDC provider

All of these are the industry-recommended keyless authentication methods for their respective cloud registries.

Underlying limitation

The core issue is that reusable workflows run in an isolated job context and can only receive credentials via secrets inputs. Unlike regular actions (e.g. docker/build-push-action) that run as steps within the caller's job — where pre-auth steps like google-github-actions/auth can run beforehand — reusable workflows have no mechanism for callers to inject dynamic, runtime-obtained credentials.

Since all major cloud providers now recommend OIDC-based keyless auth (GCP WIF, AWS OIDC, Azure OIDC), and GitHub itself promotes this pattern via id-token: write permission, the current registry-auths design effectively excludes the recommended auth flow for all major cloud registries.

Environment

Repository visibility: private
Workflow: docker/github-builder/.github/workflows/build.yml@v1
Auth action: google-github-actions/auth@v3
Registry: Google Artifact Registry (*-docker.pkg.dev)

Question

What options do we have to use github-builder with dynamic creds for registry auth ?

Seems to be directly related to #40

👍 I'm interested in this for Azure container with Federated Identity.

My workaround for now was to push to ghcr from the action,, and then run a second job that uses regctl to copy from GHCR to AzureCR -- using regctl preserves the mutil arch and attestations etc.

Yes this looks like the same underlying limitation as #40, but it's worth calling out separately because it blocks the recommended auth path for cloud registries, not just an arbitrary secret-passing use case.

The problem is not really GCP-specific. Any flow that mints a short-lived token at runtime and masks it, like GCP WIF, AWS OIDC for ECR, or Azure federated identity for ACR, runs into the same workflow_call boundary. Once the value has to cross into the reusable workflow via secrets, GitHub strips the masked output and the login step gets an empty password 😞

#6 closed the original registry auth work by adding registry-auths, which covers static credentials and multi-registry login. But the same thread also documents why dynamic OIDC/WIF tokens still fail across the reusable workflow boundary: #6 (comment)

So unless the reusable workflows expose some way to perform registry login inside the caller job context, or otherwise avoids requiring dynamic credentials to cross the reusable-workflow boundary, keyless/OIDC auth for external registries is effectively unsupported.

I think the workable fix is not "pass the token in", it's "mint the token inside the reusable workflow".

For GCP Artifact Registry, github-builder could support optional WIF inputs such as workload_identity_provider and service_account, then run google-github-actions/auth@v3 inside the workflow before the registry login step and pass the resulting access_token directly to docker/login-action.

That avoids the current failure mode entirely because the short-lived token never has to cross the workflow_call boundary as a secret or job output. I would not make this implicit based only on pkg.dev detection. The registry hostname does not tell the workflow which WIF provider or service account to use, and mixed-registry builds are possible. This needs explicit opt-in inputs imo.

I'd love to use this workflow, as it could help us consolidate a great deal of build steps. Ability to use OIDC & GCP Artifact Registry is currently the only missing piece for us.

+1, confirming this on a third independent auth path: Chainguard's cgr.dev via chainctl OIDC.

So the surface area of this constraint is now confirmed for: GCP WIF (OP), AWS OIDC, Azure federated identity, and Chainguard OIDC-assumable identities. That's every major cloud registry's recommended keyless flow.

build/bake,build: add Chainguard OIDC keyless cgr.dev auth (opt-in)

remove use-private-image workflow

Opened #244

Awesome work 👍 I'm curious if multiple registries support is somewhere in the backlog?
My case is to build arm64+amd64 images and push artifacts into multiple regions using WIF with separate creds per region:

name: Build and Push
on:
  push:
    branches:
      - main
    tags:
      - 'v[0-9]+.[0-9]+.[0-9]+'
      - 'v[0-9]+.[0-9]+.[0-9]+-*'

env:
  GCP_PROJECT: 'example-project'
  GCP_WI_PROVIDER: 'projects/123456789012/locations/global/workloadIdentityPools/github/providers/example-provider'

jobs:
  build:
    name: Build Docker Image
    runs-on: ubuntu-latest
    permissions:
      contents: 'read'
      id-token: 'write'
    steps:
      - uses: actions/checkout@v4

      - name: Set up Docker
        uses: docker/setup-docker-action@v4

      - name: Docker meta
        id: meta
        uses: docker/metadata-action@v5
        with:
          images: |
            europe-west1-docker.pkg.dev/${{ env.GCP_PROJECT }}/eu0-europe-west1/${{ github.event.repository.name }}
            us-central1-docker.pkg.dev/${{ env.GCP_PROJECT }}/us0-us-central1/${{ github.event.repository.name }}
            asia-east1-docker.pkg.dev/${{ env.GCP_PROJECT }}/as0-asia-east1/${{ github.event.repository.name }}
          tags: |
            type=ref,event=tag
            type=ref,event=branch

      - name: Set up QEMU
        uses: docker/setup-qemu-action@v3
        with:
          platforms: linux/arm64

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v3

      # Three registries, three GCP service accounts, three separate WIF logins.
      # Each region has its own SA so a compromised/misconfigured region can't
      # push to the others' Artifact Registry repos.
      - name: login2gar-eu0
        uses: ./.github/actions/gcp-login
        with:
          registry: 'europe-west1-docker.pkg.dev'
          service_account: 'eu0-gh-gar@example-project.iam.gserviceaccount.com'
          project_id: '${{ env.GCP_PROJECT }}'
          workload_identity_provider: '${{ env.GCP_WI_PROVIDER }}'

      - name: login2gar-us0
        uses: ./.github/actions/gcp-login
        with:
          registry: 'us-central1-docker.pkg.dev'
          service_account: 'us0-gh-gar@example-project.iam.gserviceaccount.com'
          project_id: '${{ env.GCP_PROJECT }}'
          workload_identity_provider: '${{ env.GCP_WI_PROVIDER }}'

      - name: login2gar-as0
        uses: ./.github/actions/gcp-login
        with:
          registry: 'asia-east1-docker.pkg.dev'
          service_account: 'as0-gh-gar@example-project.iam.gserviceaccount.com'
          project_id: '${{ env.GCP_PROJECT }}'
          workload_identity_provider: '${{ env.GCP_WI_PROVIDER }}'

      # Single multi-arch build, pushed to all three registries at once.
      - name: Build image
        uses: docker/build-push-action@v6
        with:
          context: ./
          platforms: linux/amd64,linux/arm64
          push: ${{ startsWith(github.ref, 'refs/tags/') }}
          tags: ${{ steps.meta.outputs.tags }}
          labels: ${{ steps.meta.outputs.labels }}

and gcp-login action

name: 'Login to GAR'

inputs:
  registry:
    description: "Registry to login to"
    required: true
  service_account:
    description: "GCP service account email"
    required: true
  project_id:
    description: "GCP project ID"
    required: true
  workload_identity_provider:
    description: "Workload IdP to auth with"
    required: true

runs:
  using: 'composite'
  steps:
    - name: google auth
      id: auth
      uses: 'google-github-actions/auth@v3'
      with:
        project_id: '${{ inputs.project_id }}'
        workload_identity_provider: '${{ inputs.workload_identity_provider }}'
        token_format: 'access_token'
        service_account: '${{ inputs.service_account }}'

    - name: Docker Auth
      uses: 'docker/login-action@v3'
      with:
        username: 'oauth2accesstoken'
        password: '${{ steps.auth.outputs.access_token }}'
        registry: '${{ inputs.registry }}'

Navigation Menu

Repository navigation

registry-auths secret doesn't support dynamic tokens from GCP Workload Identity Federation #146

Description

Problem

Current approach (fails)

Result

Root cause

Impact

Underlying limitation

Environment

Question

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

registry-auths secret doesn't support dynamic tokens from GCP Workload Identity Federation #146

Description

Description

Problem

Current approach (fails)

Result

Root cause

Impact

Underlying limitation

Environment

Question

Activity

voron commented on Mar 13, 2026

ashb commented on Mar 18, 2026

crazy-max commented on Apr 2, 2026

gmile commented on May 6, 2026

danilohorta commented on May 11, 2026

crazy-max commented on Jul 7, 2026

voron commented on Jul 8, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions