L15. Authentication, Authorization & Secrets Management: Managed Identities, Service Connections & Key Vault
Managed identities remove credential management entirely, workload identity federation removes the stored secret entirely, and Azure Pipelines secure files handle certificates that a string secret variable cannot.
Service Principals vs Managed Identities
A service principal is an identity you create and manage explicitly in Azure Entra, generating credentials (client secret or certificate) and rotating them manually. Service principals work from anywhere and are necessary for non-Azure workloads or cross-tenant authentication, but they require active credential lifecycle management.
A managed identity is an Azure-native identity whose credentials are created and rotated by Azure automatically, eliminating your responsibility entirely. Managed identities come in two types: system-assigned (one per Azure resource) and user-assigned (standalone resources assignable to multiple resources).
Choosing the Right Identity
Managed identities are strongly preferred whenever a workload runs on an Azure resource and only needs to authenticate to other Azure resources in the same tenant. Examples include Azure Functions, App Service, VMs, and container instances. Since Azure fully manages credentials, there is no secret to rotate or leak.
Service principals remain necessary when the workload runs outside Azure, needs to authenticate across tenants, or needs to reach non-Azure services.
GitHub and Azure DevOps Authentication
Both platforms offer credential types suited to different scenarios:
| Credential Type | Lifetime | Best For |
|---|---|---|
| GITHUB_TOKEN | Expires at workflow end | Within-repository operations |
| GitHub Apps | Long-lived, revocable | Fine-grained automation |
| Personal access tokens | Long-lived until revoked | Legacy workflows only |
Workload Identity Federation (OIDC)
Workload identity federation (OpenID Connect) eliminates storing long-lived credentials entirely. GitHub Actions or Azure Pipelines exchanges a short-lived OIDC token for Azure access tokens at run time. Configure the trust relationship once, then no client secret needs to be stored or rotated. This removes an entire class of leakable credentials from your CI/CD system.Azure DevOps Service Connections and Secure Files
A service connection in Azure Pipelines encapsulates credentials a pipeline needs to reach an external service. Service connections can use a service principal, managed identity (workload identity federation), or other credential types, and can be restricted to specific pipelines.
Azure Pipelines secure files store and encrypt file-based sensitive content (certificates, provisioning profiles) that string secret variables cannot represent. Azure downloads these to the agent only at job run time and deletes them afterward.
Preventing Secret Leakage
Mark pipeline variables as secret so they are masked in logs (though masking is best-effort, not a guarantee). Avoid echoing secret values directly in script steps. Design pipelines so secrets are only used where needed, and prefer OIDC or managed identities over stored client secrets whenever possible.
Permissions and Access Levels
GitHub offers five permission levels (read, triage, write, maintain, admin) plus outside collaborator access. Azure DevOps offers Project Administrator, Contributor, Reader, and Stakeholder (a limited free access level for business stakeholders needing visibility without full project membership).
- ✓Managed identities (system-assigned or user-assigned) have their credentials fully created and rotated by Azure automatically, and are strongly preferred over service principals whenever a workload runs on Azure and only needs to reach other Azure resources
- ✓GITHUB_TOKEN is an automatically generated, short-lived, workflow-run-scoped token requiring no manual secret setup, while GitHub Apps offer fine-grained, revocable permissions preferred over broad personal access tokens for automation
- ✓Workload identity federation (OpenID Connect) lets GitHub Actions and Azure Pipelines authenticate to Azure by exchanging a short-lived federated token at run time instead of storing a long-lived client secret, removing a class of leakable credential entirely
- ✓Azure DevOps Stakeholder access and GitHub outside collaborator access are both limited access levels suited to people (business stakeholders, external contractors) who need specific visibility or contribution without full project/organization membership
- ✓Azure Pipelines secure files store and encrypt file-based sensitive content (certificates, provisioning profiles), downloading them to the agent only at run time and cleaning them up afterward, which is distinct from simple string-based secret variables
1. A workload running on an Azure Function only needs to read secrets from an Azure Key Vault in the same tenant. What authentication approach is strongly preferred over creating and managing a service principal?
2. What is the security advantage of workload identity federation (OIDC) over storing a client secret as a GitHub Actions secret for authenticating to Azure?
3. A business stakeholder needs to view and comment on Azure Boards work items for visibility into project status, but should not have full Azure DevOps project membership or consume a paid license. What access level fits this?
Recommended: Pluralsight
This free course covers the theory. Pluralsight adds structured DevOps Engineer Expert learning paths, hands-on Azure Pipelines and GitHub Actions labs, and timed practice exams to make it stick before exam day.