How should GitHub authenticate to Azure without storing a long-lived secret?
Why B is the answer
A federated credential using OpenID Connect
Federated credentials issue short-lived tokens, so no secret is stored in GitHub.
In detail
- A federated credential using OpenID Connect issues a short-lived token.
- No long-lived secret is stored.
- Limit the credential to one repository and branch.
Use case
An illustrative scenario, not a real incident.
A pipeline stored a long-lived secret that nobody rotated. A federated credential with OpenID Connect replaces it with short-lived tokens.
See it in different ways
sequenceDiagram participant G as GitHub Actions participant E as Microsoft Entra ID participant A as Azure G->>E: Federated token E-->>G: Access token G->>A: Deploy resources
sequenceDiagram participant D as Developer participant G as GitHub participant A as GitHub Actions participant Z as Azure D->>G: Merges a Bicep change G->>A: Starts the workflow A->>Z: Signs in with OpenID Connect A->>Z: Deploys to dev, test and prod
sequenceDiagram participant P0 as GitHub workflow participant P1 as Microsoft Entra ID participant P2 as Azure P0->>P1: Identity token P1-->>P0: Short-lived token P0->>P2: Deploy
Key point: OpenID Connect removes stored secrets.
Why the other options are wrong
- A. A personal password stored in the workflow file
- A personal password in a file is exposed.
- C. A service principal secret stored as a repository secret
- That is still a long-lived secret.
- D. A storage account key kept in the repository README
- A key in a README is public.