Managed Identities and Service Principals

What it is

A workload identity is an identity for software, not for a person. Code running in Azure, in a pipeline or in another cloud needs to sign in to reach resources such as Key Vault or a database. Storing a password in the code is risky, so Microsoft Entra offers better options: managed identities, service principals and workload identity federation.

Choosing the right one is the core skill for this topic.

How it works

Choosing the identity type

The decision is simple. If the code runs on an Azure resource that supports managed identities, use a managed identity. If it runs elsewhere and an external token exists, use federation. Use a service principal with a certificate when neither fits.

System assigned and user assigned managed identities

Using a managed identity

1. Enable a system assigned identity on the resource, or create a user assigned identity and assign it.
2. Grant access. Assign an Azure role to the identity on the target, for example Key Vault Secrets User on a vault, or Storage Blob Data Reader on a storage account.
3. Use it in code. The app requests a token from the local identity endpoint, usually through DefaultAzureCredential, which finds the identity automatically.

from azure.identity import DefaultAzureCredential
from azure.keyvault.secrets import SecretClient

client = SecretClient(vault_url="https://contoso-vault.vault.azure.net", credential=DefaultAzureCredential())
secret = client.get_secret("db-password")

On a developer laptop signed in with the Azure CLI, the same code works because DefaultAzureCredential falls back to that sign in.

Azure SQL Database needs one extra step. The identity must exist as a contained database user created FROM EXTERNAL PROVIDER, and then database roles are granted to that user. Falling back to a SQL login with a password defeats the purpose.

Workload identity federation

With federated identity credentials, an external workload is trusted without a secret. You add a federated credential to an app registration or a user assigned managed identity. It records the issuer, which is the external identity provider, and the subject, which identifies the workload. When the workload presents a token from that issuer with that subject, Entra exchanges it for an access token.

• GitHub Actions: issuer is GitHub, subject names the repository and environment or branch.
• Azure Kubernetes Service (AKS): the cluster's OIDC issuer URL is the issuer, and the subject is system:serviceaccount:<namespace>:<service account name>.

A maximum of 20 federated identity credentials can be added to an application or a user assigned managed identity. The combination of issuer and subject must be unique.

For AKS, Microsoft Entra Workload ID uses a service account annotated with the identity's client ID (azure.workload.identity/client-id) and a pod label (azure.workload.identity/use) that opts the pod in to receive a projected token. Each cluster has its own OIDC issuer URL. To move a workload to a new cluster while the old one keeps running, add a second federated credential with the new cluster's issuer URL and the same subject, and leave the first one alone.

Troubleshooting

To review activity, use the Managed identity sign-ins and Service principal sign-ins tabs of the sign in logs. Background token activity of users is on the non interactive tab, which is a different tab.

A worked scenario

A web app on Azure App Service reads secrets from Key Vault. The team turns on a system assigned managed identity and gives it the Key Vault Secrets User role, so the code needs no password. Three other apps share the same storage access, so a user assigned managed identity is created and attached to all three. A GitHub Actions pipeline deploys the app. Instead of a stored secret, a federated credential on an app registration trusts the repository, and the workflow exchanges its token for an access token.