4.1.1.1. Managed Identities and Service Principals
4.1.1.1. Managed Identities and Service Principals
Authentication in DevOps pipelines centers on managed identities and service principals. Managed identities — assigned to Azure resources like VMs, App Services, and AKS — authenticate without any stored credentials. The Azure platform handles token issuance and rotation automatically. Use managed identities when an Azure resource needs to access other Azure resources (Key Vault, Storage, ACR). Service principals are Azure AD application identities used when the caller isn't an Azure resource — such as on-premises agents or third-party CI systems. The shift toward workload identity federation means even service principals can authenticate without client secrets, using OIDC token exchange instead. Role assignments follow least privilege: grant only the specific permissions needed (e.g., AcrPull for image pulling, Key Vault Secrets User for secret reading) rather than broad roles like Contributor.
The identity hierarchy for Azure DevOps pipeline authentication follows a preference order based on security posture. Managed identities — system-assigned (tied to one resource) or user-assigned (shared across resources) — represent the gold standard: no credentials to manage, automatic token rotation, Azure-managed lifecycle. Use system-assigned for single-resource scenarios (this App Service accesses this Key Vault) and user-assigned when multiple resources need the same identity.
Service principals with federated credentials (workload identity federation) are next: no stored secrets, OIDC-based authentication. Service principals with client secrets are the legacy approach — functional but requiring rotation schedules, expiry monitoring, and secure storage in Key Vault.
Role-Based Access Control (RBAC) assignments determine what each identity can do. Built-in roles (Reader, Contributor, Owner) are convenient but often over-privileged. Custom roles with specific action permissions follow least privilege more precisely: an identity that only needs to read secrets gets Microsoft.KeyVault/vaults/secrets/read, not the entire Key Vault Contributor role.
Conditional Access policies add context-aware security: restrict service principal sign-ins to specific IP ranges or require specific authentication strengths. For high-security environments, Privileged Identity Management (PIM) provides just-in-time elevation — identities operate with Reader permissions by default and temporarily elevate to Contributor only when pipeline tasks require it.
Conditional Access policies applied to service principals add network-based restrictions: only allow authentication from your corporate VNet or specific IP ranges. This prevents stolen credentials from being used outside your network. For the most sensitive resources, enable continuous access evaluation, which revokes tokens in near real-time when conditions change.
Short-lived tokens from managed identities typically expire after 24 hours and refresh automatically.
