Pushing Docker Images to Azure Container Registry with GitHub Actions

I needed to build 4 Docker images from a monorepo and push them to Azure Container Registry on every push to main. Sounds simple. It wasn't.

What I was going for

Four services, four images, all pushed to wira360.azurecr.io automatically. Tags with the git SHA for traceability, plus latest for convenience. No stored secrets — OIDC for auth.

The workflow (final version)

name: Build and Push to ACR
 
on:
  push:
    branches: [main]
  workflow_dispatch:
 
jobs:
  build-push:
    name: ${{ matrix.service }}
    runs-on: ubuntu-latest
    strategy:
      fail-fast: false
      matrix:
        include:
          - service: sokoni-api
            dockerfile: products/sokoni/api/Dockerfile
          - service: sokoni-web
            dockerfile: products/sokoni/web/Dockerfile
          - service: payments-api
            dockerfile: services/payments/api/Dockerfile
          - service: admin-web
            dockerfile: platform/admin/web/Dockerfile
 
    steps:
      - name: Checkout
        uses: actions/checkout@v4
 
      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v3
 
      - name: Log in to ACR
        uses: docker/login-action@v3
        with:
          registry: wira360.azurecr.io
          username: \${{ secrets.ACR_USERNAME }}
          password: \${{ secrets.ACR_PASSWORD }}
 
      - name: Build and push
        uses: docker/build-push-action@v6
        with:
          context: .
          file: \${{ matrix.dockerfile }}
          push: true
          tags: |
            wira360.azurecr.io/\${{ matrix.service }}:\${{ github.sha }}
            wira360.azurecr.io/\${{ matrix.service }}:latest
          cache-from: type=registry,ref=wira360.azurecr.io/\${{ matrix.service }}:cache
          cache-to: type=registry,ref=wira360.azurecr.io/\${{ matrix.service }}:cache,mode=max

fail-fast: false means a slow build in one job won't cancel the others. The registry cache means repeat builds only transfer changed layers.

One-time Azure setup

Before this can run you need an ACR. I already had one at wira360.azurecr.io. Enable admin credentials:

az acr update --name wira360 --admin-enabled true
az acr credential show --name wira360

That gives you a username and password. Store them as GitHub secrets:

ACR_USERNAME
ACR_PASSWORD

The OIDC rabbit hole

I originally wanted keyless auth — no stored secrets, just OIDC. The setup looks clean: create an app registration, add a federated credential pointing at your repo, grant it AcrPush, and use azure/login@v2 in the workflow.

az ad app create --display-name "github-tracker-acr"
az ad sp create --id <appId>
 
az ad app federated-credential create \
  --id <appId> \
  --parameters '{
    "name": "github-tracker-main",
    "issuer": "https://token.actions.githubusercontent.com",
    "subject": "repo:eduuh/wira360:ref:refs/heads/main",
    "audiences": ["api://AzureADTokenExchange"]
  }'
 
ACR_ID=$(az acr show --name wira360 --query id -o tsv)
az role assignment create --assignee <appId> --role AcrPush --scope $ACR_ID

Audience gotcha

The audience must be api://AzureADTokenExchange. If you use api://AzureADTokenEndpoint (which looks plausible), OIDC silently fails with AADSTS700212.

OIDC login worked. But the Docker push kept failing with insufficient_scope: authorization failed.

The problem: after azure/login@v2 authenticates you, the next step is getting Docker credentials for the registry. The obvious approach is az acr login --name wira360, which writes credentials to the default Docker context. Except buildx runs in its own container driver and doesn't inherit those credentials.

So you try az acr login --expose-token, get a short-lived access token, and pass it to docker login. Closer, but still fails. The reason: buildx's OAuth challenge flow with ACR expects either basic auth credentials or a refresh token. A bare access token doesn't satisfy the challenge, so ACR returns insufficient_scope.

There are ways to make OIDC work with buildx (passing the token through buildx secrets, using a different driver), but they add complexity for marginal benefit. Admin credentials stored as GitHub secrets are static, they work, and that's enough.

Verifying it worked

az acr repository list --name wira360
az acr repository show-tags --name wira360 --repository sokoni-api

You should see your git SHAs listed as tags.

OIDC is elegant in theory. Admin credentials are boring and they work.

Last updated on February 22nd, 2026