5 min to read
What is AWS Assume Role?

Overview
Learn about AWS Assume Role, a powerful feature that allows temporary access to AWS resources across accounts securely.
🔍 What is AWS Assume Role?
AWS Assume Role is a function that allows one user or service to temporarily accept another role in AWS and temporarily use the authority set for that role.
This function increases security and management convenience while safely using only the necessary authority.
- The
sts:AsumeRole
operation allows you to take on other AWS accounts or roles that exist within your own account. When you take on a role, you temporarily acquire privileges related to that role.- Cross-account access: You can take on the role of another AWS account to access the resources of that account.
- Within the same account: take on a role with different privileges than the user or service running the current command.
Example of using the Assume Role
The following is how to use the Assume Role to grant account A access to EKS resources in account B.
Step 1: Create IAM Role in Account B
Create an IAM role using a trust policy that allows account A to take on this role in account B. This role grants account B the right to manage EKS resources.
- Example of creating an AssumeRole role in account B: This policy allows the user or role of account A to take on the following roles.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:root" // Account A ID
},
"Action": "sts:AssumeRole"
}
]
}
Alternatively, you can specify a specific role in account A.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:role/AccountARole" // Replace with specific role in Account A
},
"Action": "sts:AssumeRole"
}
]
}
- Link EKS permissions to account B’s role.
- To manage EKS resources, attach required EKS policies, such as Amazon EKSClusterPolicy or custom permissions, to roles.
Step 2: Create IAM Policy in Account A
Create an IAM policy in Account A to allow users or services in Account A to take on the role of Account B.
Example Account A Policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::111122223333:role/EKSAdminRole"
}
]
}
Step 3: Assume Role from Account A
A user or service with a role assumption policy in Account A can now assume a role in Account B using the AWS CLI, SDK, or AWS console.
- This command provides temporary credentials (access keys, secret keys, and session tokens) that you can use to access and manage EKS clusters in Account B.
Step4: Use temporary credentials for access
Temporary credentials allow you to manage the resources of account B as if you have permissions on account A.
Example of updating kubeconfig to manage EKS clusters in account B:
What is sts:AssumeRoleWithWebIdentity?
The
sts:AssumeRoleWithWebIdentity
operation allows you to take on another role in AWS using an OIDC token or SAML assertion.
- Purpose: Used to take on roles based on the federation ID of external providers (OIDC or SAML), such as Google, GitHub Actions, AWS Cognito, or OIDC-compatible ID providers.
- Authentication Method: OIDC token or SAML assistance is required instead of AWS IAM credentials.
Use Cases
- OIDC Integrated Access: CI/CD systems such as GitHub Actions, Kubernetes service accounts, AWS Cognito, or external IdP.
- Secure and short-term access to AWS resources is possible without the need for long-term IAM credentials.
Process
- An external IDP (OIDC provider) issues an OIDC token to a user or service. The token is sent to AWS as part of an AssumeRoleWithWebIdentity API call.
- AWS checks tokens for configured OIDC providers and then issues temporary credentials for delegated roles if tokens and conditions are valid.
AssumeRole vs AssumeRoleWithWebIdentity
Feature | sts:AssumeRole | sts:AssumeRoleWithWebIdentity |
---|---|---|
Authentication | AWS IAM credentials | OIDC token or SAML assertion |
Use Cases | Cross-account access within AWS | External provider integration |
Identity Support | IAM entities | Federated identities |
Common CI/CD Usage | - | GitHub Actions, Kubernetes |
Best Practices
1. Security: - Use least privilege principle
- Implement proper role policies
- Regular rotation of credentials
2. Implementation: - Clear trust relationships
- Proper session naming
- Appropriate timeout settings
3. Monitoring: - Track role assumptions
- Audit access patterns
- Monitor for suspicious activity
Comments