A GitHub Actions workflow assumes an AWS production role through OIDC. The role's trust policy checks only the audience and that the subject begins with the organization's repository path, so a workflow on any feature branch can assume it. How should the trust be tightened?
Select an answer to reveal the explanation.
Short Explanation
The trust policy is the one part you control that an attacker can't edit from a branch, so that's where the rule has to live. Match the subject claim to the production environment or the main branch, and feature-branch tokens simply don't get in. A check inside the workflow file is useless, because whoever writes the branch writes the workflow.
Full Explanation
Federated trust is only as narrow as the claims the cloud provider checks. A GitHub Actions OIDC token's subject identifies the repository and the context of the job, such as a branch reference or a deployment environment. Conditioning the AWS role's trust policy on a subject that names the protected production environment, or the main branch, means tokens from feature branches do not match and AssumeRoleWithWebIdentity fails. Environment protection rules and required reviewers in GitHub then guard which jobs can run in that environment. The audience claim is chosen by the requesting workflow, so any workflow, on any branch, can ask for the same audience and match a policy that checks only that value. A step that exits unless the branch is main lives in workflow code that a feature-branch author can delete or edit, so it is not a security boundary. Session duration controls how long a credential lasts once issued; a feature-branch job can still assume the role and act within that time. Exam caveat: the same principle applies to HCP Terraform dynamic credentials, where the subject names the project, workspace and run phase. Operational check: run the workflow from a feature branch and confirm role assumption is denied, then confirm the production deployment still succeeds.