My production GitHub Actions pipeline assumes an AWS IAM role through OIDC so it can push images to ECR, but STS returns "Not authorized to perform sts:AssumeRoleWithWebIdentity." The workflow runs on version-tag pushes, the job uses environment: production, and id-token: write is enabled. The IAM role trusts the token.actions.githubusercontent.com provider with audience sts.amazonaws.com and a subject condition of repo:MY_ORG/MY_REPO:environment:production. I also added a refs/tags/v* ref condition and verified the provider, role ARN, repository and environment names, and tag trigger. What else could cause the trust policy not to match?
4 Answers
The likely problem is the ref condition added by the IAM console. If you selected main in the console’s branch field, it may have created a condition such as refs/heads/main. Your workflow runs from refs/tags/v..., so that condition can never match. Remove the ref condition and trust the exact environment subject instead: repo:ORG/REPO:environment:production, along with aud: sts.amazonaws.com. Since the production job always targets that environment, this remains tightly scoped. Also check that the repository has not enabled a customized or immutable subject-claim format.
Also verify exact capitalization in the organization and repository names. If the policy was previously working and suddenly stopped, check CloudTrail for the claims and consider external causes such as an AWS Organizations service-control policy or a GitHub subject-claim configuration change.
The corrected trust policy should contain the federated provider, sts:AssumeRoleWithWebIdentity, and conditions for the audience and environment subject, without an incompatible branch or tag condition. For example, use StringEquals for sts.amazonaws.com and repo:ORG/REPO:environment:production. If the tag restriction is required, make sure it matches a claim that is actually present in the token and use the correct trigger-specific subject format.
Use CloudTrail to inspect the failed AssumeRoleWithWebIdentity event and compare the presented claims byte-for-byte with the IAM conditions. The actual sub is more reliable than relying on documentation or the console-generated policy. You can also temporarily broaden the subject with StringLike, for example repo:ORG/*, to confirm that OIDC works, then narrow the policy one condition at a time. Do not leave the broad wildcard in production.
A temporary workflow_dispatch job that only runs configure-aws-credentials followed by aws sts get-caller-identity is a useful smoke test. Give it the same role and environment settings, then restore the strict policy after confirming the claim values.
A job-level environment changes the subject claim from the branch form to the environment form. Check the exact token rather than guessing, because newer or customized subject formats may include additional repository or owner identifiers.