How to Replace Azure Service Principal Secrets with Workload Identity

Replace long-lived Azure service principal secrets with workload identity federation. Use OIDC, narrowly scoped federated credentials, least-privilege RBAC, migration steps, validation, and troubleshooting.

Target Architecture

CI Runner -> OIDC Token -> Microsoft Entra ID -> Azure Access Token -> Azure Resource

Implementation

1. Create a dedicated Entra application identity.
2. Configure a federated credential restricted to the trusted repository and branch/environment.
3. Assign only the Azure RBAC role and resource scope required by the pipeline.
4. Configure the CI workflow for OIDC authentication.
5. Test trusted and untrusted authentication paths.
6. Revoke the old client secret after successful migration.

Example

permissions:
  id-token: write
  contents: read

steps:
  - name: Azure Login
    uses: azure/login@v2
    with:
      client-id: ${{ secrets.AZURE_CLIENT_ID }}
      tenant-id: ${{ secrets.AZURE_TENANT_ID }}
      subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

Security Validation

Verify that an unauthorized repository or branch cannot authenticate, production access is restricted, old credentials are revoked, and Entra sign-in activity is visible.

Common Mistakes

• Trusting every repository or branch
• Assigning subscription-wide Owner permissions
• Reusing one identity across unrelated pipelines
• Leaving old secrets active

Final Takeaway

Workload identity changes the model from protecting a reusable secret to trusting a specific workload under defined conditions.