Entra Workload Identities and Service Principals

Workload identities are identities in Microsoft Entra ID that represent non-human entities such as applications, services, virtual machines, containers, or automation scripts. Unlike user identities (which represent people who authenticate interactively with a username and password or MFA), workload identities authenticate programmatically using secrets, certificates, or managed identities. They are used to grant access to resources like Azure Storage, Microsoft Graph, or custom APIs.

In modern cloud environments, applications and services need to access other resources without human intervention. For example, a web app needs to read from a database, a CI/CD pipeline needs to deploy code to Azure, or a function app needs to write to a blob storage. Using a user account for these tasks is insecure and impractical—user accounts have passwords that expire, are subject to MFA interruptions, and are tied to a person who might leave the organization. Workload identities solve this by providing a secure, non-interactive identity that can be assigned specific permissions and can rotate secrets automatically.

A service principal is the local representation of an application in a specific Entra ID tenant. It is the identity that applications use to authenticate to Azure and access resources. When you register an application in Entra ID, three objects are created: - Application object: The global definition of the application, stored in the home tenant. It contains properties like app ID, reply URLs, and permissions. - Service principal object: The local instance of the application in a tenant. It is this object that is assigned roles and permissions. An application can have multiple service principals (one per tenant). - Managed identity: A special type of service principal automatically managed by Azure, eliminating the need for credential management.

When an application needs to authenticate, it uses its credentials (client secret or certificate) to request an access token from the Microsoft identity platform (Azure AD). The token is issued for a specific resource (e.g., https://graph.microsoft.com). The service principal's permissions are defined by the roles assigned to it (e.g., Azure RBAC roles, app roles, or delegated permissions). The token is then presented to the resource, which validates it and grants access based on the claims.

Managed identities are the recommended way to authenticate Azure services to Azure resources. There are two types: - System-assigned managed identity: Enabled directly on an Azure resource. It has the same lifecycle as the resource—when the resource is deleted, the identity is also deleted. It is unique to that resource. - User-assigned managed identity: Created as a standalone Azure resource. It can be assigned to multiple Azure resources. It has its own lifecycle independent of any resource.

Managed identities automatically handle credential rotation—there are no secrets to manage. They use certificate-based authentication internally, with certificates rotated every 46 days (by default, but can be configured).

Service principals can authenticate using: - Client secret: A string value (like a password) generated by Entra ID. It has an expiration date (max 2 years, can be set to never expire but not recommended). - Certificate: An X.509 certificate uploaded to the app registration. More secure than client secrets. The certificate's thumbprint is used during authentication. - Federated identity credential: Used for workload identity federation, allowing external identity providers (like GitHub Actions, Kubernetes) to exchange tokens for Entra ID tokens without managing secrets.

Service principals are assigned permissions through: - Azure RBAC roles: Grant access to Azure resources (e.g., Contributor, Reader on a subscription or resource group). - App roles: Defined in the application manifest. Applications can define roles and assign them to users or service principals. - Delegated permissions: Used when an application acts on behalf of a user (requires user consent). - Application permissions: Used when the application acts as itself (no user context). Requires admin consent.

To create a service principal via Azure CLI:

az ad sp create-for-rbac --name MyApp --role Contributor --scopes /subscriptions/{subscription-id}

To list service principals:

az ad sp list --all --query "[].{displayName:displayName, appId:appId}" -o table

To get details of a managed identity:

az resource show --ids /subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.ManagedIdentity/userAssignedIdentities/{name}

A DevOps team uses Azure DevOps to deploy infrastructure to Azure. Instead of using a user account (which would break if the user leaves), they create a service principal with Contributor role on the subscription. The pipeline uses the service principal's client secret stored in Azure Key Vault to authenticate. When the secret expires, the pipeline fails—this is a common issue. Best practice is to use a user-assigned managed identity for the Azure DevOps agent, eliminating secret management entirely. In production, the team rotates secrets every 90 days using automation.

A company runs a microservices application on Azure Kubernetes Service (AKS). Each microservice needs to access Azure resources like Cosmos DB and Key Vault. They enable system-assigned managed identities on the AKS cluster and use pod identities to assign identities to specific pods. This way, each pod authenticates to Azure without any secrets in the code. A common misconfiguration is assigning too broad permissions (e.g., Contributor on the whole subscription) instead of scoping to specific resources. The team learned this the hard way when a compromised pod had access to all resources.

An organization uses a third-party SaaS application that needs to read user profiles from Microsoft Graph. The SaaS vendor provides an app registration that requires admin consent for application permissions. The IT admin grants consent, creating a service principal for the SaaS app in their tenant. Later, they realize the app has 'User.Read.All' permission—too broad. They revoke consent and request a more limited permission. This highlights the importance of reviewing delegated vs. application permissions: application permissions allow the app to access data without a signed-in user, which is powerful and risky.