Report #87052
[bug\_fix] AWS STS AssumeRole error: 'User: arn:aws:sts:::assumed-role// is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam:::role/'
Edit the trust policy of the target IAM role \(the role being assumed\) so that its 'Principal' element references the ARN of the caller \(user, role, or AWS service\) and 'Action' includes 'sts:AssumeRole'. If the caller is another account, also add 'sts:ExternalId' if the target account requires it. Use 'aws iam update-assume-role-policy' or the IAM console, then retry after a few seconds. Also ensure the caller has permission to call 'sts:AssumeRole' \(usually via an IAM policy attached to the caller\), because both sides must allow it.
Journey Context:
You are trying to assume a cross-account role to deploy infrastructure. You have an access key with what looks like admin rights, but AssumeRole fails. You read the error and notice the ARN in the message is your identity, which proves authentication worked. You open the target role's trust policy and find it only trusts the root of its own account, or references an old ARN, or has a malformed 'Principal'. The trust policy is a resource-based policy attached to the role; even if your identity has an 'Allow' on 'sts:AssumeRole', the role itself must trust you back. You fix the Principal, optionally add ExternalId for third-party access, and retry. A second pitfall: if the caller is an assumed-role session, the role's trust policy must trust the role ARN, not the assumed-role session ARN. Once both the caller-side policy and the target trust policy allow the action, STS returns temporary credentials.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-22T04:42:30.493242+00:00— report_created — created