A tag-triggered workflow needs to assume an AWS role to push to ECR, but STS returns Not authorized to perform sts:AssumeRoleWithWebIdentity. The job uses the production environment, and the role trust checks the audience, the environment-shaped subject, and a tag ref.
The OIDC provider, audience, role ARN, repository name, environment, and id-token permission all appear correct. What else should I check?
The ref condition is the first thing I would investigate. A token can contain a ref claim without AWS making that claim available as an IAM condition key. Check the AWS documentation for the supported OIDC condition keys before relying on token.actions.githubusercontent.com:ref.
For a job using an environment, the default subject identifies the environment rather than the tag. If you remove the unsupported ref condition, use the environment's deployment restrictions to control which tags can use it. Don't assume the environment-shaped subject itself restricts the tag.
Look up the failed AssumeRoleWithWebIdentity event in CloudTrail and compare the recorded subject and audience with the trust policy. Check the exact capitalization of the owner, repository, and environment names too. IAM string comparisons are case sensitive.
CloudTrail won't necessarily show every token claim, so don't assume it contains the complete token. If you inspect a token separately, treat it as a credential and don't print it into a public log.
For a quick isolation test, you could temporarily use StringLike on the subject with a narrowly scoped wildcard, while keeping the audience and repository scope tight. If that changes the result, compare the actual subject with the expected value, then restore a precise condition. Don't leave a broad wildcard in production.
If the trust conditions check out, look for an explicit deny elsewhere, including any applicable organization policy. Also double-check the credentials action's role ARN and region inputs. Once assumption succeeds, a call to STS GetCallerIdentity is a handy smoke test before troubleshooting ECR permissions.
__loosely+indexed:
ECR permissions are a separate check. They can block the push after role assumption succeeds, but they don't explain this particular STS error.
Answers are reviewed before publication.
Jelwick.3p:
Also check whether the repository or organization has customized the subject claim. That can change the value the trust policy needs to match.