Identities and Permissions: Who Is Actually Making the Change?
Choose managed identities, service principals, GitHub Apps or workflow tokens, and separate Azure DevOps access levels from permissions.
A staff badge is not permission to open every room
Authentication establishes the identity. Authorization determines what that identity may do at a particular scope. A valid token can still be correctly denied access.
Before granting anything, identify the caller: human account, pipeline workload, Azure resource identity, GitHub App installation, or repository workflow token. “The pipeline needs access” is incomplete until you know which identity performs which operation.
Compare Azure workload identities
| Choice | Typical fit | Lifecycle consideration |
|---|---|---|
| System-assigned managed identity | Azure resource needs its own identity | Tied to that resource’s lifecycle |
| User-assigned managed identity | Independently managed identity shared or reused deliberately | Sharing increases its potential blast radius |
| Application/service principal | Application identity needing explicit application configuration | Authentication can use federation/certificate/secret as supported |
A managed identity is represented by a service principal in Microsoft Entra ID; these are not wholly unrelated identity systems. The practical choice concerns how the identity is created, authenticated, governed, and scoped.
Managed identity avoids handling a long-lived application credential in the supported Azure execution environment. It does not automatically grant data access. For example, an application that can obtain a token still needs the appropriate Azure RBAC or service-specific data-plane role.
Use the narrowest useful scope. Subscription Owner is not a normal prerequisite for a workload to read a storage object. Distinguish management-plane access from data-plane access.
Choose a GitHub automation identity
GITHUB_TOKEN is a job-associated installation token provided to Actions with configurable permissions. Start from minimal permissions such as contents: read, then grant a particular job only what it needs. Token context and fork/event restrictions matter.
A GitHub App is often a better fit for durable cross-repository automation: installation scope and explicit permissions are managed separately from one employee’s personal account. Its installation tokens are short-lived, but its private key and app configuration still need protection.
A personal access token represents a user. Fine-grained PATs can be limited to selected resources and permissions where supported; classic PATs have a different scope model. Expiration, organization approval, SSO requirements, and account lifecycle affect reliability.
Do not use a maintainer’s broad PAT simply because it makes an initial prototype work. A person leaving the organization should not silently break a production deployment.
Organize Azure DevOps and GitHub deliberately
In Azure DevOps, an organization contains projects; teams use area/iteration configuration for their work. Security groups and permissions control actions, while access levels determine available product features. A higher access level is not a substitute for repository or project permission.
For a sandbox team:
- Choose the project visibility and process.
- Create the team and its relevant area/iteration paths.
- Assign users through appropriate groups.
- Inspect effective repository, Boards, and pipeline access.
- Test using the intended non-administrator identity.
In GitHub, organization teams can receive repository roles. GitHub Projects organizes planning work; it is not the same security/container concept as an Azure DevOps project. Use roles, teams, branch rules, environment access, and app installations to express the real boundaries.
Diagnose denial without broadening everything
| Failure | Check first |
|---|---|
| Azure token issued, resource denied | Correct tenant/audience, scope, role, data-plane permission |
| GitHub token works in one repo only | Installation/selected repository and token permissions |
| Azure DevOps user sees project but not feature | Access level plus effective feature permission |
| Agent runs locally but fails in cloud | Different identity, secret scope, policy, or tools |
Inspect the actual request identity and target. Do not copy a personal credential into automation to hide a workload identity problem. Record access changes and review them when the workload’s scope changes.
An Azure app obtains a token using managed identity but cannot read a blob. What is the correct next investigation?
Try it: draw an identity-to-action matrix
Prerequisites: read access to a sandbox Azure resource or hosted DevOps project. No role changes are required.
List a developer, build job, deployment job, and application runtime. For each, record identity type, target, action, required scope, and credential lifecycle. Inspect one actual role assignment or repository permission and compare it with the matrix.
Expected observation: build, deploy, and runtime identities need not be the same, and each grant has an identifiable operation and scope.
Cleanup: no mutation is required. If you separately created sandbox identities or tokens, remove only those exercise credentials and grants after checking dependencies.
Decision check: one identity for every environment?
Shared identity simplifies setup but couples access and incident response. Separate identities when environments have different trust or ownership, and scope each to the operations it actually performs.