3.2 Workload Identities and Managed Identities

3.2 Workload Identities and Managed Identities

In modern cloud architecture, non-human entities—such as automated deployment scripts, background workers, microservices, container workloads, and Virtual Machines—require access to Azure resources. Traditionally, developers authenticated these workloads using hardcoded credentials, service principal secrets, or certificates, creating severe secret-sprawl and credential rotation risks. Microsoft Entra Workload Identities and Managed Identities eliminate credential management entirely by providing Azure-managed identity lifecycles for workloads.

---

1. Workload Identity Concepts: Service Principals vs. Managed Identities

A Workload Identity is an identity assigned to a software entity (application, service, container, or script) to enable authentication and authorization against Entra ID and Azure Resource Manager.

                  Workload Identities in Entra ID
                                 │
           ┌─────────────────────┴─────────────────────┐
           ▼                                           ▼
   Service Principals                         Managed Identities
(App Registrations with                     (Azure Infrastructure
 Client Secrets / Certificates)               Managed Credentials)
           │                                           │
 ┌─────────┴─────────┐                       ┌─────────┴─────────┐
 ▼                   ▼                       ▼                   ▼
Manual Secret      External App            System-Assigned     User-Assigned
Rotation Needed    Authentication          (1:1 with Host)     (Standalone 1:N)

Service Principals vs. Managed Identities Comparison:

• Service Principals: Created when registering an application in Microsoft Entra ID. Authentication requires generating a client secret (symmetric key) or uploading an X.509 certificate. Administrators must manually track, store, and rotate these credentials before expiration.
• Managed Identities: A specialized category of Service Principals that are tied directly to Azure resources. Azure infrastructure handles credential provisioning, token acquisition, and key rotation automatically behind the scenes without developer intervention. Managed identities are free of charge.

---

2. System-Assigned vs. User-Assigned Managed Identities

Azure offers two distinct operational modes for Managed Identities. Understanding their lifecycle and sharing characteristics is essential for proper architecture design:

---

3. Credential-Less Access to Azure Key Vault using Managed Identities

The gold standard for zero-trust application design in Azure is retrieving secrets, keys, or connection strings from Azure Key Vault without storing any credentials in application code, appsettings.json, or environment variables.

┌────────────────────────────────────────────────────────────────────────┐
│                          Azure VM / App Service                        │
│                                                                        │
│  ┌────────────────────┐   1. OAuth Token Req  ┌─────────────────────┐  │
│  │  Application Code  │ ────────────────────> │ Local IMDS Endpoint │  │
│  │ (DefaultAzureCred) │ <──────────────────── │ (169.254.169.254)   │  │
│  └─────────┬──────────┘   2. Entra ID Token   └─────────────────────┘  │
└────────────┼───────────────────────────────────────────────────────────┘
             │
             │ 3. HTTP Authorization Header (Bearer Token)
             ▼
┌────────────────────────────────────────────────────────────────────────┐
│                          Azure Key Vault                               │
│  (Data Plane RBAC: Key Vault Secrets User)                             │
└────────────────────────────────────────────────────────────────────────┘

Authentication Execution Flow:

1. Enable Identity: Enable System-Assigned (or assign User-Assigned) Managed Identity on the VM, App Service, or Function App.
2. Assign Data Plane RBAC: Grant the Managed Identity the Key Vault Secrets User role (4633005b-24ab-44da-8c2e-9f310fa57263) on the target Key Vault scope.
3. Local Token Acquisition: Application code initializes the Azure Identity SDK (e.g., DefaultAzureCredential() in .NET, Python, or Java).
4. IMDS Query: The SDK makes a local HTTP GET request to the internal Azure Instance Metadata Service (IMDS) non-routable IP address: http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://vault.azure.net
5. Bearer Token Usage: IMDS returns an Entra ID OAuth 2.0 access token signed by Entra ID. The application includes this bearer token in the HTTP Authorization header when querying Key Vault data plane APIs (https://<vault-name>.vault.azure.net/secrets/<secret-name>).

---

4. Workload Identity Federation (Secretless External Authentication)

While Managed Identities work seamlessly for workloads hosted inside Azure, external workloads—such as GitHub Actions CI/CD runners, Amazon Web Services (AWS) EC2 instances, or on-premises Kubernetes clusters—historically required storing long-lived Azure Service Principal client secrets in external credential stores.

Workload Identity Federation (WIF) eliminates external client secrets by leveraging OpenID Connect (OIDC) standards to establish a direct trust relationship between an external identity provider and Microsoft Entra ID.

┌────────────────────────┐                   ┌────────────────────────┐
│ GitHub Actions Runner  │                   │  Microsoft Entra ID    │
│                        │  1. Request OIDC  │  (Security Token Svc)  │
│  Obtains OIDC ID Token │ ────────────────> │                        │
│  from GitHub OIDC Prov │                   │  Validates OIDC Claims │
└───────────┬────────────┘                   │  against Federated Cred│
            │                                └───────────┬────────────┘
            │ 2. Present OIDC Token                      │
            └────────────────────────────────────────────┘
                                                         │ 3. Issues Short-lived
                                                         │    Azure Access Token
                                                         ▼
                                             ┌────────────────────────┐
                                             │ Azure ARM / Resources  │
                                             └────────────────────────┐

Configuring Workload Identity Federation for GitHub Actions:

1. Create App Registration / Service Principal in Entra ID.
2. Configure Federated Identity Credentials on the Service Principal by defining three parameters:
   • Issuer: https://token.actions.githubusercontent.com
   • Subject Identifier: Defines exact repo/environment scoping (e.g., repo:my-org/my-repo:environment:Production or repo:my-org/my-repo:ref:refs/heads/main).
   • Audience: api://AzureADTokenExchange
3. Assign Azure RBAC Role: Assign the Service Principal a role (e.g., Contributor or Website Contributor) on the target subscription or resource group.
4. CI/CD Workflow Execution:
   • The GitHub Actions runner requests a short-lived OIDC token from GitHub's OIDC issuer.
   • The workflow presents the OIDC token to the Microsoft Entra Security Token Service (STS).
   • Entra ID validates the signature against GitHub's public keys (/.well-known/jwks.json) and verifies that the sub claim matches the configured Federated Credential.
   • Entra ID exchanges the OIDC token for a short-lived Azure access token (valid for 1 hour).
   • The pipeline deploys code to Azure securely without any client secret stored in GitHub Secrets.