Secrets & Identity

The warehouse app stops connecting after a password change. Ada finds three copies of the old connection string: one in a file, one in deployment configuration, and one in a teammate’s notes. “Which one does the running app use?” she asks. Put a necessary secret in a controlled store, give the app permission to retrieve it, and verify how it receives the new version. Where the target supports identity-based access, investigate removing the password altogether. A vault helps control a secret; it does not stop code from logging the value after retrieval.

Key Vault

A service for storing secrets, keys, and certificates. In an Azure RBAC vault, data-plane roles control who reads or changes their values. Send audit events to a chosen destination with diagnostic settings if the team needs retained access logs; this lab does not configure logging.

First, choose the vault's permission model. In an Azure RBAC vault, Key Vault Secrets User reads secret values and Key Vault Secrets Officer manages them; assign the narrowest needed role and scope.¹ Second, give an App Service or Container App a managed identity and a Key Vault reference when the platform supports it. The platform retrieves the value, but the application still receives that secret as configuration and must avoid logging it. Rotation is not instant everywhere: confirm each service's refresh behavior and test that it picked up the new version.

Phase Three built machinery with real power: identities that deploy to production, tokens that write to your repositories, runners that execute whatever workflows say. This section is the audit you now know enough to run — four questions, asked of every pipeline, each one a callback:

# the pipeline least-privilege audit — run it quarterly
1. What can each deployment identity reach?    (Class 8)
   → Scope the required role to the resources it deploys.
2. Which runs can assume that identity?        (Class 23)
   → Review the federated credential's repo, ref, and environment claims.
3. What can the GITHUB_TOKEN do?               (Class 24)
   → Default to read access; grant write only to jobs that need it.
4. Who reviews the files that grant all this?  (Class 22)
   → Protect workflow changes with owners and required review.

Power accumulates; audits subtract.

Run this review after workflow, identity, or deployment-scope changes and on a recurring schedule. Start from the live Azure role assignments and GitHub settings, not from a saved diagram. Defender for Cloud may surface some broad assignments, but it does not replace checking the federated credential subject, token permissions, and branch protections. Record any exception with its owner and expiry, then test that the workflow can still deploy with the narrower permissions.

Class Eight gave you least privilege in space: who may touch what, scoped to the narrowest resource that still lets the work happen. It said nothing about time. The Owner role granted at 2am to fix an incident is still Owner at noon the following Tuesday, and the month after that, quietly attached to an account nobody remembers elevating. Standing privilege is the liability the §2 audit keeps finding, because an account that is always an administrator is always worth stealing — and the attacker who lands on it inherits every hour of access it was never using.

Privileged Identity Management (PIM) can make a high-privilege role eligible rather than permanently active. The user activates it when needed; the configured policy can require justification, MFA, approval, and a limited duration. An eligible role still creates a path to privilege, so protect the account and review who remains eligible. PIM requires appropriate licensing; check the current licensing and activation policy before designing an incident response around it.

Eligible vs active

Eligible means the user may request or perform activation under the configured policy. Active means the role is currently usable. Eligibility reduces standing access but still needs account protection and review.

Activation

The act of claiming an eligible role: justification, a self-expiring window, and — for the roles that warrant it — approval and MFA at the moment of use, which is exactly when proof of identity is worth demanding.

Access reviews

A reviewer checks whether each assignment is still needed. Removal depends on how the review is configured and completed; do not assume an unused grant expires automatically.

Break-glass accounts

Two excluded emergency accounts, cloud-only, outside PIM and Conditional Access, stored offline and heavily alerted — the way back in the day the identity system itself locks you out. Guard them like the spare key they are.

The pipeline audit limits workload identities; PIM limits standing human privilege. For each, ask what an attacker could do with the account now, what extra steps could grant more access, and whether those steps are monitored.