AWS
IAM
AssumeRole
Authorization Error
STS

AWS AssumeRole - User is not authorized to perform stsAssumeRole on resource

Master System Design with Codemia

Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.

Understanding the "User is not authorized to perform: sts:AssumeRole on resource" Error in AWS AssumeRole

Amazon Web Services (AWS) is a leading cloud provider offering a wide range of services, including Amazon EC2, Amazon S3, and more. A key feature of AWS's security model is the use of roles to access resources. AWS users often encounter the `sts:AssumeRole` operation when working with cross-account access, allowing a user from one AWS account to perform actions in another account. However, a common issue arises: the error message "User is not authorized to perform: sts:AssumeRole on resource." This article delves into the technical details behind this error, helping you understand and resolve it effectively.

What is AssumeRole?

`AssumeRole` is an API function provided by AWS Security Token Service (STS) that allows you to assume a different role, usually in another AWS account. When you assume a role, STS provides you with temporary security credentials (an Access Key ID, Secret Access Key, and Session Token) that provide the permissions associated with that role. This enables cross-account actions or elevated permissions within the same account.

Error Explanation

The "User is not authorized to perform: sts:AssumeRole on resource" error typically occurs when:

  1. Lack of Trust Relationship: The target role does not trust the user or the user's account.
  2. Insufficient IAM Permissions: The user's IAM policy does not include permission to call `sts:AssumeRole` for the specified role.

Technical Breakdown

1. Trust Relationship

Every AWS role has a trust policy that specifies which AWS accounts or users can assume the role. This policy is usually specified in JSON format and must include the requesting user's account.

Example Trust Policy:

  • The user's account ID or role is listed as a principal in the trust policy.
  • The trust policy is correctly applied to the intended role.
  • The user's IAM policy permits the `sts:AssumeRole` action on the specific target resource.
  • The account ID and role name in the policy resource match the intended target role's ARN.

Course illustration
Course illustration

All Rights Reserved.