GitHub Actions OIDC Cloud-Access Boundary for Offshore DevOps

Write the caller identity before the trust policy

Start from claims captured safely for the exact workflow context, then author the cloud trust relationship from allowlisted values. Repository, organization, ref, tag, pull-request context, environment, workflow identity, issuer, and audience are different boundaries; a wildcard chosen for convenience can admit an unintended caller. Use a protected deployment environment when human approval or branch restrictions are required, and keep the cloud role permissions narrower than its trust eligibility. Exercise default branch, feature branch, fork pull request, unapproved environment, different repository, altered audience, reusable workflow, and expired token. Record cloud session names and audit correlation without persisting the JWT. Test metadata or provider failure as closed, and remove legacy static secrets only after every legitimate path works. Security owns federation policy and incident response; platform owners approve deployment authority; the developer maintains workflow code and denied-case tests.

List the organization, repository, workflow file, ref or environment, issuer, audience, and cloud role for each permitted job. Keep these as separate fields. A policy that says "this repository may deploy" is incomplete when feature branches, pull requests, reusable workflows, and protected environments produce different claims. Capture claims from a safe test exchange without storing the token itself.

Constrain token permission to the job that needs it

Review workflow and job permissions together. Grant id-token: write only where the exchange occurs, and keep repository-content and package permissions at the minimum required for that job. A job-level grant exposes token minting to every step in the job, including third-party actions. Pin those actions under the repository's approved immutable-reference policy and examine what runs before the exchange.

Separate trust from authorization. The cloud trust policy decides which workload may assume the role. The role policy decides what an admitted session may do. A narrow subject attached to an administrator role is still excessive, while a read-only role with a wildcard subject may leak data to unintended callers. Review both documents in the same packet.

Buyer decision record

Scroll sideways to read every column on a small screen.

Build denied neighbors around the allowed case

Exchange from the approved default-branch or protected-environment job, then repeat from a feature branch, a similarly named branch, a fork pull request, another repository, an unapproved environment, and an altered audience. Include a repository name that shares the allowed prefix. Each denial should be attributable to a specific claim condition rather than to a broken test credential or network path.

Reusable workflows need an additional check. Record the claims that describe the caller and the called workflow under the chosen provider. Do not assume the workflow repository becomes the only identity simply because its YAML contains the deployment steps. The trust rule should reflect the provider's documented claims and the organization’s intended authority.

Treat environment protection as part of the boundary

If human approval or branch restrictions are required, use the real protected environment in the fixture. Test a rejected approval, an absent approval, and an environment name with punctuation that affects the subject format. The exchange must not occur before the environment rules pass. Preserve the workflow run, commit, environment, and approval record as linked evidence.

Mutable names deserve care. Display names and branch labels help an operator read logs, but trust should rely on the exact supported claims and patterns. A prefix wildcard can admit names that merely look related. Enumerate the allowed forms and place a denied example beside every pattern.

Follow the cloud session after exchange

Pin third-party actions by the repository’s approved immutable reference policy and review which step can request id-token: write. Job-level permission can expose token minting to more steps than intended. In reusable workflows, distinguish the caller identity from the workflow repository claims supported by the provider. Test an environment name containing unexpected punctuation and a branch whose name resembles an allowed prefix. Cloud audit events should identify the workflow run and commit without granting trust based on mutable display text. If an exchange succeeds unexpectedly, revoke or narrow cloud trust first; editing logs or deleting the workflow does not invalidate an already issued session. Record maximum session duration and downstream role chaining.

Record the session name, role, start and expiry, requested audience, workflow run, source revision, and cloud audit event. Verify maximum session duration and any downstream role chaining. Do not log the JWT. The goal is to trace an action back to an approved workload without turning the evidence system into a credential leak.

Remove static credentials only after migration proof

Run every legitimate deployment path through federation before deleting the old secret. Then revoke the static credential, remove it from repository or environment configuration, and demonstrate that the workflow still succeeds. Search configuration references and rotation procedures as well as workflow YAML. A secret hidden from the current job can still remain usable elsewhere.

Test provider metadata failure, audience mismatch, expired tokens, and unavailable cloud identity service. The job should stop without falling back to a long-lived key. If an unexpected exchange succeeds, narrow or revoke cloud trust first. Deleting a workflow or editing a log does not invalidate a cloud session that has already been issued.

Approval rests on both allowed and denied evidence

Approve only when intended workflow contexts exchange successfully and every neighboring repository, ref, fork, environment, and audience is denied. The cloud session must have bounded lifetime and permissions, correlate in audit logs, and fail closed. Static keys remain until migration validation, then their removal is separately evidenced.

The packet contains the workflow revision, pinned actions, effective permissions, issuer and audience, subject conditions, environment protections, cloud role policy, allowed exchange, denied neighbors, session duration, audit correlation, fail-closed tests, legacy-secret removal evidence, and revocation procedure. Security owns federation and incident response. Platform owners approve deployment authority. The developer maintains the workflow and fixtures but does not broaden trust to make a failing branch pass.

Questions about assessing Philippine developers