Add support for a custom az-path

[Craig Duncan (duncan3dc)]

In some of our workflows we use docker containers to ensure we've got a consistent environment. We use this action to authenticate with OIDC, but this action assumes the az CLI is running on the GitHub actions machine.

This PR allows a custom az path to be specified, so that we can authenticate inside the docker container, and then run our following az commands in there.

For example:

- name: Setup docker container
  run: |
    docker build . -t ci-image
    docker run --interactive --detach \
      --env ACTIONS_ID_TOKEN_REQUEST_URL=$ACTIONS_ID_TOKEN_REQUEST_URL \
      --env ACTIONS_ID_TOKEN_REQUEST_TOKEN=$ACTIONS_ID_TOKEN_REQUEST_TOKEN \
      --name ci ci-image

- name: Authenticate with Azure
  uses: azure/login@v2
  with:
    client-id: "${{ secrets.AZURE_CLIENT_ID }}"
    tenant-id: "${{ secrets.AZURE_TENANT_ID }}"
    subscription-id: "${{ secrets.AZURE_SUBSCRIPTION_ID }}"
    az-path: "docker exec ci az"

- name: Now we can run az inside our container
  run: docker exec ci az account show

[Shiying Chen (MoChilia)]

Hi Craig Duncan (@duncan3dc), thank you for your contribution. I appreciate this feature. But I would prefer setting it as an environment variable rather than using a parameter.

Yan Xu (@YanaXu) For consistency, should we consider whether Azure PowerShell will also require a custom path?

[Nguyenxu29y123 (srceenr29y1)]

vại tương lơ . Cấm mọi quyền cả admins( nguyên ; Nguyễn ...) phát hiện ban vĩnh viễn Vào Thứ 6, 6 thg 3, 2026 lúc 20:06 Mattias Vinberg ***@***.***> đã viết:

…

***@***.**** approved this pull request. — Reply to this email directly, view it on GitHub <#559 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BSDHOMFEIRD7TEDSEUP7JB34PLENRAVCNFSM6AAAAACI2RT57OVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZTSMBTGYZDENZRGQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[Joey Donner (joe345-str)]

ok

[MaddyMicrosoft]

What this PR seems to address looks achievable two ways today without a new input:

1. Login inside the container directly. Fetch the OIDC token and run the login there with something like:

oidc_token=$(curl -s -H "Authorization: bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" \
  "$ACTIONS_ID_TOKEN_REQUEST_URL&audience=api://AzureADTokenExchange" | jq -r '.value')
docker exec ci az login --service-principal \
  --username "$AZURE_CLIENT_ID" --tenant "$AZURE_TENANT_ID" --federated-token "$oidc_token"

2. Share the credential cache. Set AZURE_CONFIG_DIR to a folder bind-mounted into the container, so a normal host login writes there and the container reads it (SDK code can use AzureCliCredential).

Is there a scenario neither of these covers?

On the consistency point: a per-tool path override doesn't scale well. If we add it for the CLI, we'd want an equivalent for Azure PowerShell, and the two store their context differently, so we'd end up maintaining two parallel overrides. Sharing the credential/context location instead covers both az and Connect-AzAccount uniformly, without a per-tool path.

If there's a real gap, it might be cleanest to capture it as a feature request or PR framed around the shared credential/context location, which works for CLI and PowerShell together.