Replacing a stored cloud access key with OpenID Connect changes how a deployment authenticates. It does not decide which deployment deserves access. That decision lives in the relationship between the workflow's identity, the cloud trust policy and the permissions attached to the resulting session.
This distinction matters when several repositories share an automation platform. A successful production deployment proves that one route is allowed. It says little about an experimental branch, another repository or a caller that invokes the same reusable workflow in an unexpected context. Those refused routes deserve their own tests.
Follow the identity exchange
A GitHub Actions job requests an identity token. The cloud provider examines the token against configured trust conditions and, when those conditions match, issues access according to the chosen role. The role then determines what the job can do to cloud resources.
GitHub's cloud-provider guidance explains that the permission to request an identity token does not itself grant write access to cloud resources. Treat token issuance, role assumption and resource authorisation as separate decisions. A review that checks only one of them leaves an incomplete picture.
The useful shift is from rotating a shared secret to maintaining a verifiable identity relationship. Your operating procedure must now cover changes to repositories, environments, reusable workflows and role conditions. Removing a secret from the settings screen is an intermediate step, not the completion criterion.
Reusable workflows introduce two identities to understand
A central deployment workflow can make release behaviour consistent across teams. However, the calling repository and the reusable workflow are different parts of the trust decision. A shared workflow used by many applications must not accidentally become a route into every production account.
GitHub documents how OIDC tokens represent reusable workflows: ordinary claims describe the caller, while the job_workflow_ref claim identifies the called workflow. Cloud providers differ in which conditions they support. Some designs use a customised subject claim, which requires coordinated configuration rather than an assumption that every claim is available everywhere.
For example, GitHub's AWS configuration guide states that custom OIDC claims are unavailable in AWS and highlights checking the subject in role trust policies. Use the actual provider's supported conditions and test the generated subject. Copying a policy from a different provider can produce a broken deployment or an unintended access boundary.
A small refactor can change the boundary
Imagine a software company with separate application and reporting repositories. Both call a central deployment workflow. The application may update a customer portal; reporting should publish only an internal dashboard. During a cleanup, someone broadens a trust condition to accept the organisation's repositories because the central workflow is shared.
Both legitimate deployments continue to work. The missing test is whether reporting can now obtain the portal's production role. The visible success of the refactor conceals an authorisation change.
A safer design records the intended caller and destination relationship for each deployment. Shared automation can remain shared while resource access stays specific. The policy should be reviewed alongside the workflow change, with a clear owner for both sides.
Make refusal observable
Build a small test environment representing the production identity arrangement. Use resources that cannot affect customers. Establish a successful approved deployment, then exercise cases that should not gain the production role.
- ▸An unapproved repository invokes the reusable workflow.
- ▸An allowed repository uses a disallowed branch or deployment context.
- ▸A workflow bypasses the expected protected environment.
- ▸The token audience does not match the cloud configuration.
- ▸A job obtains its own role but attempts an unrelated resource operation.
Record where each request fails. Failure to obtain a token is different from rejection by the role trust policy, and both differ from a resource permission denial. A red pipeline alone does not establish which security boundary worked.
Test the allowed route again after changing a condition. Security and delivery teams need a policy that refuses the wrong request while permitting the intended release. Preserve sanitised evidence and identifiers rather than saving live identity tokens in build logs.
Protect the material that defines a deployment
Federation cannot compensate for unrestricted modification of a trusted workflow. Decide who can change the deployment definition, the reusable workflow and the environment protections. Review externally maintained actions and version references as part of the release dependency chain.
Separate development, staging and production permissions. If emergency access exists, record how it is approved and withdrawn. A permanent administrator key left behind for troubleshooting can undermine the purpose of the migration even when the ordinary pipeline uses OIDC correctly.
The existing CI/CD security guide covers the surrounding delivery system. This review focuses on the narrower identity exchange and the negative evidence needed to trust it.
Migrate one route before expanding
Select a representative deployment with a clear owner and a manageable failure impact. Document the current permissions, introduce federation, test both acceptance and refusal, and then remove the old key from the systems that used it. Search for remaining references so another scheduled task is not silently dependent on that credential.
Keep the rollback decision explicit. A deployment outage should lead to an approved temporary recovery path, not the creation of an untracked shared secret. Afterwards, update the tests whenever repository structure or cloud ownership changes.
If your team needs help with this transition, explore cloud engineering services and describe your current deployment route. TuniCyberLabs can scope a remote review around one identity boundary, its test cases and a controlled migration to production.