Deploy from GitHub Actions to Azure without storing a single secret

The old way to deploy from GitHub to Azure was to create a service principal, generate a client secret and paste it into GitHub as a secret. That secret lasts months or years and works from anywhere if it leaks.

Workload identity federation replaces it. GitHub issues a short-lived OpenID Connect token for each workflow run, and Entra exchanges it for an Azure token, but only if it comes from the repository and branch you trust.

1. Create the identity

Use an app registration or a user-assigned managed identity. Then grant it the Azure role it needs, scoped as tightly as possible, such as Contributor on one resource group.

2. Add a federated credential

On the app registration, go to Certificates & secrets → Federated credentials, or the equivalent on the managed identity. Choose the GitHub Actions scenario and enter:

• Organization and repository, such as contoso/infra
• Entity type: branch, environment, tag or pull request. For deployments, an environment like production is the best choice, because GitHub environments can have their own approval rules.

The resulting subject looks like repo:contoso/infra:environment:production, with issuer https://token.actions.githubusercontent.com and audience api://AzureADTokenExchange.

3. Update the workflow

Store the client ID, tenant ID and subscription ID as GitHub variables or secrets. They're identifiers, not credentials. The workflow needs permission to request an OIDC token:

permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v4
      - uses: azure/login@v2
        with:
          client-id: ${{ vars.AZURE_CLIENT_ID }}
          tenant-id: ${{ vars.AZURE_TENANT_ID }}
          subscription-id: ${{ vars.AZURE_SUBSCRIPTION_ID }}
      - run: az group show --name rg-app

Gotchas

• The subject must match exactly. A job using an environment presents the environment subject, not the branch one.
• Each federated credential matches one subject. Add more if you deploy from several branches or environments.
• Delete the old client secret once the new setup works.

Troubleshooting

The JWT decoder is handy here: print the GitHub token's claims in a debug step and compare the sub with your federated credential.

• Use GitHub environments for production, with required reviewers
• One federated credential per environment
• Least-privilege role, scoped to a resource group
• Delete the old client secret once OIDC works