Two paths to production access
How can human operators and deployment jobs get distinct, bounded production access?
D03 · Authorization & Access Control · D04 · Identity Protocols & Cryptography · D08 · Privileged Access Management (PAM) · D09 · Non-Human Identity (NHI) · D10 · Cloud & Workload Identity · D11 · Identity Security & Zero Trust
Scenario
A fictional team deploys using GitHub Actions and also needs emergency operator access. Shared production credentials have no clear owner.
Learning outcomes
- Constrain workload federation and cloud permissions.
- Explain managed identities and SPIFFE/SPIRE trust.
- Write an allow/deny matrix for a release job, a pull-request job and an on-call engineer.
Engineering investigation
- Separate the engineer identity from the CI/CD workload identity.
- For CI/CD, bind federation to the intended repository, workflow, environment and audience.
- For operators, propose time-bound elevation, approval, session evidence and a tested emergency path.
Proposed trust flow
- Workflow identity
- Federation trust
- Scoped cloud role
- Production resource
This flow is an editorial model to investigate, not a verified deployment.
Engineering trade-off
A short token lifetime limits exposure but does not compensate for overly broad trust or permissions.
Verified source statement
Primary reference: GitHub Docs · OpenID Connect. Reviewed 3 November 2026.
Only the bounded statement above is source-backed. The company context, investigation, controls and flow are teaching proposals. Confirm support and behavior in your chosen environment.
Produce evidence
Write an allow/deny matrix for a release job, a pull-request job and an on-call engineer.
Use L1 to explain the mechanism, L2 to analyze trade-offs, L3 to implement and test, and L4 to design and justify. Reading alone does not establish competence.