The booking portal of Nordlicht Reisen GmbH, a fictional travel agency, has meanwhile gained several automations, and each one signs in somewhere. A GitHub action deploys to Azure, an Azure DevOps pipeline does the same for a second team, a script reads pull requests from Azure Repos, and a workflow is supposed to open a pull request itself. On the wiki page "Access", two of these cases list a personal access token of Ms. Berger, who leaves the company in the fall. You are to decide which identity each automation gets, and to set up the access so that no human is behind it.
The exam calls this: weighing service principals and managed identities, using GitHub Apps, GITHUB_TOKEN and PATs, and managing Azure DevOps service connections and PATs. A service principal is the identity of an application in Microsoft Entra; a PAT (personal access token), on the other hand, always belongs to a human.
Prior knowledge: What a managed identity is, is covered in K3, lesson 3.3.1. How a pipeline deploys to Azure without a secret (workload identity federation, the subject, azure/login) is shown in K3, lesson 3.7.5; the permissions of the token in Actions and Azure Pipelines are covered in K3, lesson 3.7.7. Here the decision is the focus: which identity for what, within which limits.
Service principal or managed identity
Microsoft contrasts the two like this on its page about service principals and managed identities in Azure DevOps:
| Identity | Best for | Who manages the credential |
|---|---|---|
| Managed identity | Workloads that run in Azure | Azure; your application stores no client secret |
| Service principal | Workloads outside Azure, or when a transferable application identity is needed | You: workload identity federation, a key pair (certificate) or a client secret |
Microsoft's recommendation: for a workload in Azure, a managed identity; for a service principal, federation or a key pair ahead of the client secret, if the environment allows it. A managed identity is a special service principal whose credentials Azure manages. A system-assigned identity belongs to exactly one resource and is deleted with it; a user-assigned identity is a resource of its own that can be assigned to several resources.
What that means for pipelines
A Microsoft-hosted agent or a GitHub-hosted runner is not a resource to which you attach an identity in Azure. That is why workload identity federation exists: The pipeline proves to the provider who it is, and Microsoft Entra exchanges that proof for a short-lived token. No secret sits in the pipeline.
For the Azure Resource Manager service connection, Microsoft names these options:
- App registration (automatic) with federation. Among other things, the prerequisite is the Owner role on the subscription; Azure DevOps creates the app and the federation itself.
- Managed identity with federation, connected to an existing user-assigned identity. Microsoft recommends this if you are not allowed to create an app registration.
- App registration or managed identity (manual): more work, only if the automatic option doesn't succeed.
Only for reasons of backward compatibility do these exist, and they are not recommended: app registration with a secret, the managed identity assigned by the agent (a self-hosted agent on an Azure VM) and the publish profile. You switch an existing connection to federation with the tool Convert. According to Microsoft, that works only if Azure DevOps created the connection itself and only one project uses it; an automatically created connection can be rolled back for seven days. The page also announces that the previous issuer of the federation from Azure DevOps will be retired in favor of the Entra issuer; new connections already use the Entra issuer, and you read the date there.