Cram Sheet281 words
Topic 4.1 — Authentication and authorization — cram sheet
Topic 4.1 — Authentication and authorization · cram sheet
Azure identities
| Need | Choose |
|---|---|
| Workload runs on an Azure resource | Managed identity — no secret to store |
| Caller outside Azure | Service principal + workload identity federation |
| Identity should die with the resource | System-assigned |
| Many resources, same role assignments | User-assigned |
GitHub authentication
| Mechanism | Identity | Lifetime |
|---|---|---|
GITHUB_TOKEN | The workflow run | Ends with the job |
| GitHub App | The app installation | Short-lived install token |
| PAT | A person | Until expiry/revocation |
- Declare
permissions:to narrowGITHUB_TOKEN— defaults are broad. - Cross-repository work → GitHub App, not a PAT.
Azure DevOps connections
- Current ARM pattern: workload identity federation — no stored secret.
- The Azure DevOps issuer is deprecated → convert to the Microsoft Entra issuer (convert, don't replace).
- Authorise each pipeline individually, never "all pipelines".
GitHub permissions
Read · Triage (issues/PRs, no write) · Write · Maintain (manage, no destructive) · Admin. Grant to teams; outside collaborator for contractors.
Azure DevOps permissions
- Assign to groups.
- Deny beats Allow; Not set = inherit.
- Service connections, agent pools, variable groups and environments carry their own permissions and checks.
Access levels
Stakeholder is free — work items, backlogs, dashboards, approvals; no Repos. The answer for a product owner or approver who never touches code. Access level = which features (licensing). Permissions = what you may do.
Projects and teams
Fewer projects, more teams. A team is defined by the area paths it owns.