Report #9466
[bug\_fix] AccessDenied: User is not authorized to perform: sts:TagSession on resource: arn:aws:iam::ACCOUNT:role/TargetRole
Add the \`sts:TagSession\` permission to the IAM policy attached to the source role \(the role that is performing the assumption\), in addition to the existing \`sts:AssumeRole\` permission. This is required whenever passing session tags or using transitive tag keys during role assumption.
Journey Context:
An enterprise security team implements attribute-based access control \(ABAC\) across AWS accounts. Application A running in EKS uses IAM Roles for Service Accounts \(IRSA\) to assume Role A. It needs to assume Role B in a central security account to write to CloudTrail. The trust policy for Role B requires specific session tags \(PrincipalTag/Department=Engineering\) to restrict access. The application uses the AWS SDK to call AssumeRole, passing the required tags in the \`Tags\` parameter and setting \`TransitiveTagKeys\`. The call fails with AccessDenied mentioning \`sts:TagSession\`. Developer checks if Role A's policy allows \`sts:AssumeRole\` on Role B - yes. Checks Role B's trust policy - it allows Role A to assume it and has condition keys for the tags. The developer realizes that while \`sts:AssumeRole\` allows the role to be assumed, the additional action of attaching tags to the session requires the separate permission \`sts:TagSession\`. This permission was omitted from Role A's policy. The fix works because \`sts:TagSession\` is a distinct IAM action from \`sts:AssumeRole\`; whenever you pass tags during AssumeRole \(including transitive tags for ABAC\), the assuming identity must have explicit authorization to tag sessions, not just to assume the role.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-16T08:15:26.869635+00:00— report_created — created