GitHub Actions to Azure, with zero stored secrets.

The old way to let a pipeline into Azure was to create a service principal, generate a client secret, and paste it into your CI system. That secret is long-lived, copyable, and a headache to rotate — exactly the thing that ends up in a breach post-mortem. OpenID Connect replaces it with federation: GitHub issues each workflow run a signed token describing who it is (this repo, this branch), and you configure Azure to trust tokens matching that description. No secret is stored anywhere; the token that is minted lasts minutes and cannot be reused. This is now the recommended pattern in every serious posting, and it is genuinely simple once you have done it once.

You will create an app registration for the pipeline, grant it a role on a single resource group, tell Azure to trust your repository's main branch, and then watch a workflow deploy with nothing but three non-secret IDs.

A stored secret is a liability with a shelf life. A federated token is a handshake that expires in minutes.

Create an app registration and its service principal — the identity your workflow will act as — then capture the IDs you will need.

# Windows/Git Bash: stop it mangling /subscriptions/... arguments (harmless on macOS/Linux)
export MSYS_NO_PATHCONV=1

SUB_ID=$(az account show --query id -o tsv)
TENANT_ID=$(az account show --query tenantId -o tsv)

APP_ID=$(az ad app create --display-name "campux-gh-oidc" --query appId -o tsv)
az ad sp create --id "$APP_ID"

echo "client-id (appId): $APP_ID"
echo "tenant-id:         $TENANT_ID"
echo "subscription-id:   $SUB_ID"

Make a resource group for the pipeline to deploy into, and give the app Contributor only on that group — never the whole subscription.

RG="campux-lab-oidc-rg"
az group create -n "$RG" -l eastus

az role assignment create \
  --assignee "$APP_ID" \
  --role Contributor \
  --scope "/subscriptions/$SUB_ID/resourceGroups/$RG"

Add a federated identity credential. The subject is the exact identity GitHub will present; here it means "a run of OWNER/REPO on the main branch." The audience is the fixed value Azure expects.

az ad app federated-credential create --id "$APP_ID" --parameters '{
  "name": "gh-main",
  "issuer": "https://token.actions.githubusercontent.com",
  "subject": "repo:OWNER/REPO:ref:refs/heads/main",
  "audiences": ["api://AzureADTokenExchange"]
}'

Because none of the three is sensitive, store them as repository variables. (You can use the GitHub UI under Settings → Secrets and variables → Actions → Variables, or the gh CLI.)

# with the GitHub CLI, from a clone of your repo
gh variable set AZURE_CLIENT_ID --body "$APP_ID"
gh variable set AZURE_TENANT_ID --body "$TENANT_ID"
gh variable set AZURE_SUBSCRIPTION_ID --body "$SUB_ID"

Two things make OIDC work in a workflow: the id-token: write permission (so the run may request a token) and azure/login with the three IDs. Commit this as .github/workflows/deploy.yml.

name: deploy
on:
  push:
    branches: [ main ]

permissions:
  id-token: write        # lets the run request an OIDC token
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Azure login (OIDC)
        uses: azure/login@v2
        with:
          client-id: ${{ vars.AZURE_CLIENT_ID }}
          tenant-id: ${{ vars.AZURE_TENANT_ID }}
          subscription-id: ${{ vars.AZURE_SUBSCRIPTION_ID }}

      - name: Deploy a storage account
        uses: azure/cli@v2
        with:
          azcliversion: latest
          inlineScript: |
            az deployment group create \
              --resource-group campux-lab-oidc-rg \
              --template-uri https://raw.githubusercontent.com/kloudcaptain/campux-labs/main/lab-github-actions-oidc/bicep/main.bicep

Back in Cloud Shell, confirm the workflow actually created the resource, and confirm there is no secret behind it.

az resource list -g campux-lab-oidc-rg --query "[].{name:name,type:type}" -o table
az ad app credential list --id "$APP_ID" --query "length(@)"   # -> 0 client secrets

Delete the resource group and the app registration so nothing lingers.

az group delete -n campux-lab-oidc-rg --yes
az ad app delete --id "$APP_ID"
az group exists -n campux-lab-oidc-rg      # -> false

You federated GitHub Actions to Microsoft Entra ID with OIDC, scoped the pipeline's identity to a single resource group, and deployed to Azure from a workflow that stores no secret — verifying afterwards that the app registration has zero credentials. That is precisely the "secure, auditable, no-secrets CI/CD" line that appears in nearly every cloud-engineer posting, and now you have done it, not just read about it. Pair it with the Terraform lab and you have the two halves of how modern teams ship infrastructure: code in a repo, deployed by a pipeline that no one had to trust with a password.