Quartz 5

Lab: DevOps identities, permissions, OIDC, and Key Vault

Properties1
tagslab, az-400, identity, oidc, key-vault, service-connection

3 min read

Lab: DevOps identities, permissions, OIDC, and Key Vault

Outcome

Select an identity from its runtime boundary, configure GitHub and Azure DevOps least access, use OIDC federation instead of a stored cloud secret, and retrieve a Key Vault secret/certificate through authorized workload identity.

Do

  1. Make a one-page identity decision for four cases: service principal for a non-Azure workload; system-assigned managed identity tied to one Azure resource; user-assigned managed identity shared by selected Azure workloads; and OIDC federation for GitHub Actions/Azure Pipelines. Assign only a training resource-group role.
  2. In GitHub, run a workflow with explicit minimal permissions, compare the temporary GITHUB_TOKEN, GitHub App installation token, and short-lived PAT for a one-off legacy action. Give a test outside collaborator only the required repository role and environment deployment permission; remove invitation afterward. In Azure DevOps, create a project/team, area/iteration, and security group; compare Stakeholder versus Basic access and verify least privilege.
  3. Create a resource-group-scoped Azure Resource Manager service connection using workload identity federation. Authorize only the training pipeline, add the issuer/subject/audience federated credential, and deploy a harmless tag. In GitHub, configure Azure OIDC with id-token: write and a subject restricted to the training repo/branch/environment. Keep PATs short-lived, minimum-scope, and outside pipeline automation.
  4. Create a Key Vault, assign the runtime identity only the Key Vault data role required for one training secret/certificate operation, and retrieve it at runtime without printing values. Rotate a test secret/certificate reference and verify the workload uses the intended version.

Verify

Capture the identity decision, effective GitHub/Azure DevOps permissions, project/team boundary, federated credential subject/audience, successful OIDC deployment, service-connection pipeline authorization, Key Vault role, and secret/certificate retrieval without value exposure. You should now understand: an identity authenticates a workload, a role authorizes it, OIDC exchanges short-lived assertions, and a service connection constrains a pipeline’s use of that identity.

Break and fix

  1. Run with mismatched OIDC subject/audience or missing id-token: write; inspect token/federated-credential error, correct only the claim/permission, and retry.
  2. Reference an unauthorized service connection or Key Vault secret; inspect pipeline authorization and data-plane role separately, grant the narrow missing right, then remove it.
  3. Give a test user broad admin/PAT scope; replace it with a role/group, least scope/expiry, and offboard the user.

Scenario practice

  1. Configure: Choose service principal, system/user-assigned identity, GitHub App, GITHUB_TOKEN, PAT, or OIDC for a stated owner/runtime/resource boundary.
  2. Diagnose: A pipeline cannot authenticate or read a secret. Inspect claims, service-connection authorization, Azure role, Key Vault data role, secret version, and log masking.
  3. Distinguish: Contrast identity, role, service connection, PAT, GitHub App, GITHUB_TOKEN, environment permission, and Key Vault secret/key/certificate.

Clean up

Remove test identity roles, federated credentials, service connections, pipeline authorization, Key Vault objects, project/team invitations, and training resource group.

Sources and re-audit

Re-audit when identity, federation, service-connection, GitHub token, or Key Vault behavior changes.

service-account · managed-identity · service-principal · service-connection · key-vault · All labs

Graph View

Backlinks