OIDC Deployments: Review the Trust Policy First

OIDC deployment credentials remove the need to store a reusable cloud key in a GitHub secret, but they introduce a policy question: which workflow identity may obtain cloud access? That trust policy deserves the same review as the application code being deployed.

The migration succeeds when the wrong workflow cannot obtain credentials and the right workflow receives only the authority it needs. Merely deleting a long-lived secret proves neither condition.

Understand the two independent decisions

GitHub's OIDC integration lets a workflow obtain an identity token and exchange it with a cloud provider for temporary credentials. The provider evaluates claims describing the workflow context. GitHub distinguishes the permission to request an OIDC token from access granted by the cloud provider. GitHub OIDC overview.

For a deployment design, separate two reviews:

1. Trust: May this identity assume this role?
2. Authorization: What may the assumed role do?

A narrow role with an excessively broad trust policy can still be misused by an unintended workflow. A narrow trust policy attached to an administrative role can still make one approved workflow dangerously powerful. Both dimensions need a deliberate answer.

Write the answers in plain language before encoding them. For example: “Only the release job from this repository's protected production environment may update this one application.” That sentence becomes the testable contract.

Treat subject and audience as exact inputs

AWS describes registering the OIDC provider and configuring a role trust relationship using the provider and claim conditions. The accepted audience and subject are part of that relationship; support for arbitrary claims is provider-specific. Do not copy a policy from a different cloud and assume equivalent evaluation. AWS OIDC provider documentation.

The example contract below is a planning document, not deployable IAM JSON:

Issuer: the documented GitHub Actions issuer
Audience: the exact audience expected by this cloud integration
Repository: one explicitly approved repository
Execution context: its protected production environment
Cloud role: deployment permissions for one application
Denied cases: forks, unrelated repositories, unapproved environments

Retrieve the documented claim shape for your chosen workflow context. Branch-based and environment-based subjects should not be assumed interchangeable. If the claim is environment-based, inspect the environment's branch restrictions and approval rules too. A precise string in IAM can still represent an overly permissive environment policy.

Avoid broadening a subject wildcard until the workflow works. A successful token exchange tells you that one identity matched; it says nothing about all the other identities the wildcard admits.

Design a migration that can be rolled back safely

I would migrate a nonproduction deployment first. Create a narrowly scoped role, configure trust, and run the exact release path against a disposable target. Capture the identity information needed for diagnosis without logging the complete token.

Next, exercise the production-shaped approval process using the nonproduction target. This catches a class of mistakes that unit tests cannot address: the workflow expects branch claims, but the deployment environment changes the identity context, or a reused workflow has an identity different from the one the policy author expected.

Keep the old credential only for an explicitly bounded migration window, with a named owner and removal condition. Avoid a silent fallback that automatically retries with the static key when OIDC fails. That fallback can hide broken trust configuration indefinitely and makes it difficult to know which authentication path is actually operating.

After the new route is proven, revoke the old credential, remove its references, and verify deployment still works. Deleting the secret from GitHub without revoking it at the issuing service leaves any other copies outside that deletion's scope.

Test denial as carefully as success

Build a test matrix around the plain-language contract. Include the approved environment, a different environment, an unapproved branch where applicable, and an unrelated repository under your control. A failed cloud operation should be traced to either failure to assume the role or a denial by the role's permission policy.

Those are different outcomes. If the wrong workflow can assume the role but cannot perform your chosen test operation, the trust boundary is still wrong. Conversely, a correctly assumed role that cannot deploy may need a narrowly scoped permission correction rather than broader identity trust.

For the positive case, test the full deployment lifecycle. Creation, updating, reading deployment status, and rollback may use different provider operations. A role that can start a release but cannot observe or reverse it is operationally incomplete.

These tests are recommendations, not measurements from a deployment conducted for this article. Provider-specific claim support and IAM syntax should be checked against the service you actually use.

Keep build-time code away from deployment authority

Temporary credentials can still be abused during their validity. I would keep dependency installation and arbitrary build hooks out of the privileged deployment job where practical. Promote a reviewed, identified artifact and limit the deployment command's inputs.

OIDC is also not a substitute for controlling workflow edits. If someone can change the approved deployment workflow and satisfy its protections, they may change what happens after credentials are issued. Review workflow files, environment administration, cloud role changes, and artifact selection as one release system.

Review the GitHub Actions permission boundaries before granting the workflow a cloud identity. The npm supply-chain discussion explains why code executed during a build belongs in that trust review. Finish by proving approved releases work and unauthorized identities are denied.