An overbroad deployment trust policy
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.
Fictional attack path
A workflow outside the release boundary satisfies an overbroad federation policy and obtains a production role. Inspect the claims and role permissions.
Detection and validation proposal
Collect identity, credential issuance, policy and resource audit events. In an authorized lab, run one allowed request and one denied request. Verify the result and attribution.
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.