EN_AWS_IAM

AWS IAM & Assume Role

1. Assume Role

Assuming an AWS role allows you to obtain temporary security credentials (access key, secret access key, and session token) to access AWS resources in another account or use different permissions within the same account. The sts:AssumeRole action allows you to assume a role that exists in another AWS account or within your own account. When you assume a role, you temporarily gain the privileges associated with that role.

• Cross-account access: You can assume a role in another AWS account to access resources in that account.
• Within the same account: Assume a role with different permissions than the user or service executing the current command.

The following explains how to use Assume Role to grant Account A access to Account B's EKS resources.

Step 1: Create an IAM Role in Account B

Create an IAM role in Account B with a trust policy that allows Account A to assume this role. This role grants permission to manage EKS resources in Account B.

Example trust policy for the AssumeRole role in Account B:

This policy allows users or roles in Account A to assume the role:

{
  "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"
    }
  ]
}

• Attach EKS permissions to the role in Account B:
  • Attach the required EKS policies, such as AmazonEKSClusterPolicy or custom permissions, to the role to manage EKS resources.

Step 2: Create an IAM Policy in Account A

To allow a user or service in Account A to assume a role in Account B, create an IAM policy in Account A.

Example IAM policy for Account A:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::111122223333:role/EKSAdminRole" // Role ARN in Account B
    }
  ]
}

• Attach this policy to the required users, groups, or roles in Account A.

Step 3: Assume a Role in Account A

A user or service in Account A that has permission to assume the role can do so using the AWS CLI, SDKs, or AWS Console.

Example with AWS CLI:

aws sts assume-role \
  --role-arn arn:aws:iam::111122223333:role/EKSAdminRole \
  --role-session-name eks-session

• This command assumes the role in Account B and provides temporary credentials (access key, secret key, and session token) that can be used to access and manage resources.

Step 4: Use Temporary Credentials to Access Resources

Using temporary credentials, you can manage resources in Account B with Account A's permissions.

Example for updating kubeconfig to manage an EKS cluster in Account B:

aws eks --region us-west-2 update-kubeconfig --name eks-cluster \
  --role-arn arn:aws:iam::111122223333:role/EKSAdminRole

• This lets you use kubectl from Account A to manage the EKS cluster in Account B.

sts:AssumeRoleWithWebIdentity

Used to temporarily acquire a role based on a federated identity from an external provider (OIDC or SAML) such as Google, GitHub Actions, AWS Cognito, or an OIDC-compatible identity provider.

Authentication Method

Requires an OIDC token or SAML assertion instead of AWS IAM credentials.

Key Use Cases

• OIDC Integrated Access: Used with GitHub Actions, Kubernetes service accounts, AWS Cognito, or external identity providers.
• Enables secure, short-term access to AWS resources without long-term IAM credentials.
• An OIDC provider issues an OIDC token to a user or service, which is included in the AssumeRoleWithWebIdentity API call to access AWS resources.
• AWS validates the token against the configured OIDC provider and, if the token and conditions are valid, issues temporary credentials for the role.

sts:AssumeRole vs sts:AssumeRoleWithWebIdentity

Features	sts:AssumeRole	sts:AssumeRoleWithWebIdentity
Authentication Method	AWS IAM Credentials (Access Key and Secret Key)	OIDC token or SAML assertion
Use Case	Cross-account access within AWS	Integrated access from external providers
Supported ID Types	AWS IAM entities (users, groups, roles)	Federated ID (e.g., Google, GitHub, Cognito)
CI/CD Integration	Rarely used	Frequently used in GitHub Actions, Kubernetes, etc.

→ Back to List