Secure Azure CI/CD: Replacing GitHub Client Secrets with Workload Identity Federation

You’ve been giving GitHub a key to your Azure. Here’s how to stop.

Workload Identity Federation replaces static passwords with short-lived OIDC tokens issued per deployment run. This system eliminates the need to store AZURE_CLIENT_SECRET in external repositories, a practice that currently requires manual rotation every 12 months.

Why This Matters

The technical reality is that most teams rely on long-lived client secrets that are prone to silent leaks, survival past team membership changes, and expiration-induced pipeline failures. By shifting to a trust-based model using OpenID Connect (OIDC), organizations remove an entire class of supply chain risk by ensuring no secret ever leaves the Azure tenant or is stored in a third-party system like GitHub.

Key Insights

• Standard Azure App Registrations typically require manual secret rotation every 12 months to prevent pipeline breakage.
• OIDC tokens provide a cryptographically signed proof of identity that includes specific metadata like repo, branch, and commit.
• Azure Login v2 enables secret-less authentication by using public identifiers (Client ID, Tenant ID) combined with a dynamic OIDC token.
• The trust-based model follows the logic of identity verification rather than credential transfer, similar to showing a physical ID instead of sharing a password.

Working Examples

Creating a federated credential in Entra ID to establish trust with a specific GitHub repository and branch.

az ad app create --display-name "github-actions-pipeline"
APP_ID=$(az ad app list --display-name "github-actions-pipeline" --query "[0].appId" -o tsv)
az ad sp create --id "$APP_ID"
az ad app federated-credential create \
--id "$APP_ID" \
--parameters '{
"name": "github-main",
"issuer": "https://token.actions.githubusercontent.com",
"subject": "repo:<org>/<repo>:ref:refs/heads/main",
"audiences": ["api://AzureADTokenExchange"]
}'

GitHub Actions workflow configuration using id-token permissions for OIDC-based Azure login without secrets.

name: Deploy to Azure
on:
  push:
    branches: [ main ]
permissions:
  id-token: write
  contents: read
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Login to Azure (no secret)
        uses: azure/login@v2
        with:
          client-id: ${{ secrets.AZURE_CLIENT_ID }}
          tenant-id: ${{ secrets.AZURE_TENANT_ID }}
          subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
      - name: Deploy
        run: az group list

Practical Applications

• Use case: GitHub Actions pipelines deploying to Azure production environments using short-lived, scoped tokens generated per run.
• Pitfall: Relying on legacy client secrets which can be exposed in logs or survive past the tenure of the engineer who created them.
• Use case: Automated infrastructure management where Entra ID validates the specific repository and branch before issuing access tokens.
• Pitfall: Failing to include ‘id-token: write’ permissions in the workflow, which prevents the generation of the necessary OIDC proof.

References:

• https://dev.to/florianlenz/youve-been-giving-github-a-key-to-your-azure-heres-how-to-stop-fi9