EN_AWS_IAM

AWS IAM & Assume Role

How to obtain temporary credentials via STS sts:AssumeRole to access cross-account and same-account resources, and how it differs from OIDC/SAML-based sts:AssumeRoleWithWebIdentity, written as interview Q&A.

---

Q1-1. What Is Assume Role, and When Do You Use It?

One-line answer: You "assume" a role to obtain temporary security credentials (access key, secret access key, session token), letting you access resources in another account — or with different permissions in the same account — without long-term credentials.

• 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.

---

Q1-2. How Do You Configure Cross-Account Assume Role? (Account A → Account B EKS)

One-line answer: Create a role in target Account B that trusts A (trust policy), attach an sts:AssumeRole permission policy to requesting Account A, then have A call assume-role to receive temporary credentials and manage B's resources — 4 steps.

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.

---

Q1-3. What's the Difference Between sts:AssumeRole and sts:AssumeRoleWithWebIdentity?

One-line answer: AssumeRole uses AWS IAM credentials for cross-account access within AWS; AssumeRoleWithWebIdentity uses an OIDC/SAML federated token to authenticate external identities like GitHub Actions or Kubernetes SAs without long-term keys.

sts:AssumeRoleWithWebIdentity is 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: CI/CD systems such as 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.

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