Lesson 1 of 4 · 25 min

Bind CI identity to the exact deployment authority

Evaluate an OIDC trust policy for a build-to-cloud workflow.

Mechanism and reasoning

A CI workflow can request an identity token and exchange it for cloud credentials when the cloud trusts the token's issuer and claims. This can remove a stored long-lived cloud key from the repository's secret configuration. It does not remove authorization design. The trust policy decides which workflow context may obtain which authority.

Verify issuer, audience and subject or equivalent claims according to the provider's documented mechanism. A signature from the right issuer proves that the issuer made the claim. It does not prove that every repository or branch under that issuer should deploy production. The relying service must restrict the accepted context.

Separate pull-request validation from trusted deployment. A workflow that runs untrusted contributor code should not automatically receive production credentials. The event, repository, ref, environment and reusable-workflow identity can affect the intended boundary. Review the actual emitted claims and the cloud provider's condition syntax.

Temporary credentials still need least privilege. A fifteen-minute administrator token can change policies or create persistent access during those minutes. Scope the cloud role to the required deployment resources and operations, then log assumption and use. Do not describe short lifetime as a complete containment boundary.

A useful interview answer traces who asserts identity, who validates it and who grants permission. It also shows a negative test for an untrusted branch or repository. The point is to make the trusted path narrow and testable, not merely to replace one credential format with another.

Trust-policy worksheet

Teaching system has repository org/payments. Only its protected production deployment environment may assume role deploy-payments. Pull-request tests from forks must never assume that role. The role can update one service's deployment and read its necessary artifact, but cannot create IAM users or modify account-wide policies.

Claim or authority	Intended condition	Reason
Issuer	The configured CI identity provider	Reject tokens from other issuers
Audience	The cloud exchange endpoint's expected audience	Prevent use of a token minted for another recipient
Repository context	org/payments	Exclude other projects under the same issuer
Deployment context	Approved production environment under its controls	Separate reviewed deployment from ordinary test runs
Cloud role permissions	Payments deployment resources only	Limit the authority after successful identity exchange

This is a conceptual worksheet, not a provider-ready policy document. Exact claim names and matching rules vary. A broad wildcard such as every repository in an organization can accidentally include a low-trust experimental project. A condition that checks only the branch name main can also be insufficient if it does not bind the repository identity.

Attack-free local reasoning test

Use four invented claim sets and evaluate them against the policy. Token A has the correct issuer, audience, repository and production environment. Token B has the correct issuer and repository but belongs to a pull-request test. Token C comes from a different repository with an environment also named production. Token D has the correct repository and environment but an audience for a different service.

Expected decisions are allow A and deny B, C and D. The test does not need a real cloud account or a live token. It checks the policy's intended logic. In a real implementation, add provider integration tests to prove the configured condition syntax matches these decisions and that environment protection is enforced.

Now consider a compromised trusted deployment workflow. The trust conditions can all pass because the workflow is in the authorized context. The cloud role's narrow permissions still matter. A deployment-only role should not be able to create a permanent administrator credential. If it can, the short token lifetime does not bound the resulting access. Review the post-exchange authority separately from token acceptance.

Migration sequence

Inventory current consumers of the stored deployment key. Add the OIDC trust and scoped role in a controlled environment. Test allowed and denied contexts. Move the legitimate workflow to the new exchange path and verify deployment behavior. Then revoke the old key and confirm the old path fails. Leaving the long-lived key available as an indefinite fallback preserves the original exposure path.

Keep rollback realistic. If the new identity exchange fails, a reviewed temporary recovery path may be needed. Do not automatically restore an exposed or overbroad old key. Record the specific trust or permission error. An audience mismatch is different from insufficient deployment permission; granting administrator access will not repair an incorrect audience and can enlarge the risk.

The audit record should connect CI run identity, assumed role and cloud actions. Store run IDs and credential identifiers, not raw tokens. A later investigation needs to know which code and workflow context obtained authority. A generic 'CI deployed' message is weak evidence when several workflows share a role.

Finally, distinguish the security claim from the convenience claim. OIDC can reduce static secret distribution and make identity context available at exchange. The system is secure only to the extent that trust conditions, workflow controls and role permissions preserve the intended boundary. An interview answer that names all three can explain both the benefit and the remaining failure modes.

Worked example

Teaching policy evaluation:

Token	Repository	Context	Audience	Decision
A	org/payments	approved production	expected	Allow
B	org/payments	fork PR test	expected	Deny
C	org/demo	production	expected	Deny
D	org/payments	approved production	other service	Deny

All tokens may be validly signed by the same CI issuer. The decisions differ because valid identity claims still need context-specific authorization.

Exercise

A trust rule accepts any token from the CI issuer if its environment name is production. Another repository can create an environment with that name. Identify the gap and add two conditions or controls that address the intended payments-only deployment path.

Model solution and rubric

The rule does not bind authority to the intended repository and its protected deployment context. Require the correct repository identity and audience, plus the approved environment or workflow/ref conditions supported by the provider. Verify environment protection and restrict the resulting role to payments resources. Test another repository with the same environment name and a fork PR in the correct repository. Both should fail the production exchange.

Score out of four: one point for the correct result, one for showing the intermediate reasoning, one for identifying the stated failure case, and one for a verification that could disprove the answer. Do not award the reasoning point for a tool name alone.

Failure modes and misconceptions

Misconception 1: a valid issuer signature authorizes every workflow under that issuer. The cloud must match the intended repository and context. Misconception 2: a short-lived token cannot create lasting harm. Its permissions may allow persistent policy or credential changes before expiry.

Interview probe

Evidence class: recommended. Original practice.

How can an OIDC migration still leave a dangerous CI deployment path?

Strong answer: The trust policy can accept too many contexts, the workflow can execute untrusted code with deployment authority, or the cloud role can be overprivileged. I would test claim boundaries and post-exchange permissions, then revoke the old static key.

Follow-up: What evidence distinguishes an audience mismatch from a role-permission denial?

Weak answer indicators: Issuer-only trust; branch-name checks without repository binding; retaining the old key forever; treating token lifetime as least privilege.

Sources

Technical references: GitHub Actions OIDC; OWASP secrets management. Sources support the documented mechanisms. The numbers, decisions, rubrics and interview prompts in this lesson are original teaching examples, not measurements or employer question claims.

docsGitHub Actions OIDCdocs.github.com docsOWASP secrets managementcheatsheetseries.owasp.org

Checkpoint

A signed token has the right issuer but a different audience. Expected exchange decision?

AAccept because signature verification is sufficientBReject under the expected audience conditionCAccept and assume the provider reduces permissionsDIgnore audience if the branch is main

Checkpoint

Another repository has an environment named production. What must trust also bind?

AOnly the environment display nameBOnly a short expiryCThe intended repository and approved execution contextDOnly the organization-wide issuer

Checkpoint

A short-lived deployment role can create permanent admin credentials. What remains risky?

AOnly token replay after its expiryBOnly direct actions after the original token expiresCOnly the original session; credentials it creates share its expiryDActions before expiry can create persistent authority

Checkpoint

The OIDC path passes allowed and denied-context tests. What completes removal of the old key path?

ARevoke the replaced static key and verify rejection while valid consumers workBKeep the old key indefinitely in every job for availabilityCAssume OIDC revokes it automaticallyDRemove the key from one file without invalidation

Checkpoint

Fork PR tests need to run without production deployment rights. Which check is decisive?

AWhether the protected branch alone is named in the workflow fileBWhether untrusted execution can obtain the production role or its secretsCWhether untrusted tests pass before their job requests deployment credentialsDWhether a maintainer previously approved an unrelated PR

Explain how you would evaluate an oidc trust policy for a build-to-cloud workflow without reading the solution. State one assumption that could change your answer, and one observation that would make you revise it.

Not yetGetting thereConfident

Wrap-up

Bind identity exchange to the intended context and limit the resulting role. Remove the old credential path after verification.

Sources

Free to read · better with Enzo

Learn it with Enzo

Save your progress, answer the checkpoints, and let Enzo quiz you on what you just read.

Continue with Enzo Sign up free