A trust policy answers one question: who may become this role. The commonest misreading turns a narrow-looking policy into a delegation to an entire AWS account.
Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.
The answer appears here
Paste on the left and press Analyze. Nothing leaves this tab.
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.
Delegates to the entire account, which is not what it looks like
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": { "AWS": "arn:aws:iam::111122223333:root" },
"Action": "sts:AssumeRole"
}
]
}Assumable from every repository on GitHub, not just yours
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": { "Federated": "arn:aws:iam::111122223333:oidc-provider/token.actions.githubusercontent.com" },
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": { "StringEquals": { "token.actions.githubusercontent.com:aud": "sts.amazonaws.com" } }
}
]
}The confused deputy problem, for a principal every AWS customer shares
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": { "Service": "s3.amazonaws.com" },
"Action": "sts:AssumeRole"
}
]
}These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
It delegates to the whole account, so any principal there whose IAM policy allows the call can assume the role.
Instead:Name the specific role or user ARN. It is still subject to that principal's own policy.
aud is the same value for every identity that provider serves, so the role is assumable by all of them, which for GitHub Actions means every repository on GitHub.
Instead:Add a condition on the sub claim, and check the exact format for your provider.
The principal is shared by every customer of that service, so it can be pointed at your role from another account's resource.
Instead:Add aws:SourceAccount with your account id, and aws:SourceArn where you can be that specific.
arn:aws:iam::123456789012:root in a trust policy means that account may decide for itself who assumes the role. Trust is delegated to its administrators, not restricted to its root user.
Any principal in that account whose own IAM policy allows sts:AssumeRole on this ARN can then do so, without anybody in your account being involved. Naming the specific role ARN instead is one more character of typing and a much narrower grant.
For GitHub Actions that is every repository on GitHub, not just yours. Checking only the aud claim is not enough, because aud is the same value for every repository. The sub condition is the whole control.
The trust policy must permit the principal AND the principal's own IAM policy must allow sts:AssumeRole on the role ARN. An access denied says which, so a cross-account failure means checking a policy you may not be able to see.
OIDC uses sts:AssumeRoleWithWebIdentity and SAML uses sts:AssumeRoleWithSAML. A federated principal paired with plain sts:AssumeRole is refused with an error naming neither the action nor the mismatch.
The resource is the role itself. Including one produces a MalformedPolicyDocument error that names the document rather than the element.