AWS eks documentation change
Summary
Restructured cross-account access documentation into two clear options, added detailed steps for role chaining approach, and emphasized least privilege best practices
Security assessment
The changes add explicit security best practices including avoiding account root in trust policies and restricting OIDC claims to specific service accounts. These are proactive security improvements rather than fixes for existing vulnerabilities. The documentation now better guides users toward secure configurations by emphasizing least privilege principles.
Diff
diff --git a/eks/latest/userguide/cross-account-access.md b/eks/latest/userguide/cross-account-access.md index 6b7a320ca..49daa5299 100644 --- a//eks/latest/userguide/cross-account-access.md +++ b//eks/latest/userguide/cross-account-access.md @@ -4,0 +5,2 @@ +Option 1: Create an identity provider from another account’s clusterOption 2: Use chained AssumeRole operations + @@ -13 +15,6 @@ You can configure cross-account IAM permissions either by creating an identity p -###### Example Create an identity provider from another account’s cluster + * **Option 1** is simpler but requires Account B to create and manage an OIDC identity provider for Account A’s cluster. + + * **Option 2** keeps OIDC management in Account A but requires role chaining through two `AssumeRole` calls. + + + @@ -15 +22 @@ You can configure cross-account IAM permissions either by creating an identity p -###### Example +## Option 1: Create an identity provider from another account’s cluster @@ -26 +33 @@ In this example, Account A provides Account B with the OpenID Connect (OIDC) iss -###### Example Use chained `AssumeRole` operations +## Option 2: Use chained `AssumeRole` operations @@ -28 +35 @@ In this example, Account A provides Account B with the OpenID Connect (OIDC) iss -###### Example +In this approach, each account creates an IAM role. Account B’s role trusts Account A, and Account A’s role uses OIDC federation to get credentials from the cluster. The Pod then chains the two roles together using AWS CLI profiles. @@ -30 +37,5 @@ In this example, Account A provides Account B with the OpenID Connect (OIDC) iss -In this example, Account B creates an IAM policy with the permissions to give to Pods in Account A’s cluster. Account B (`444455556666`) attaches that policy to an IAM role with a trust relationship that allows `AssumeRole` permissions to Account A (`111122223333`). +### Step 1: Create the target role in Account B + +Account B (`444455556666`) creates an IAM role with the permissions that Pods in Account A’s cluster need. Account B attaches the desired permission policy to this role, then adds the following trust policy. + +**Trust policy for Account B’s role** — This policy allows Account A’s specific IRSA role to assume this role. @@ -47 +58,9 @@ In this example, Account B creates an IAM policy with the permissions to give to -Account A creates a role with a trust policy that gets credentials from the identity provider created with the cluster’s OIDC issuer address. +###### Important + +For least privilege, replace the `Principal` ARN with the specific role ARN from Account A instead of using the account root (`arn:aws:iam::111122223333:root`). Using the account root allows _any_ IAM principal in Account A to assume this role. + +### Step 2: Create the IRSA role in Account A + +Account A (`111122223333`) creates a role with a trust policy that gets credentials from the identity provider created with the cluster’s OIDC issuer address. + +**Trust policy for Account A’s role (OIDC federation)** — This policy allows the EKS cluster’s OIDC provider to issue credentials for this role. @@ -68 +87,12 @@ Account A creates a role with a trust policy that gets credentials from the iden -Account A attaches a policy to that role with the following permissions to assume the role that Account B created. +###### Important + +For least privilege, add a `StringEquals` condition for the `sub` claim to restrict this role to a specific Kubernetes service account. Without a `sub` condition, any service account in the cluster can assume this role. The `sub` value uses the format `system:serviceaccount:_NAMESPACE_ :_SERVICE_ACCOUNT_NAME_ `. For example, to restrict to a service account named `my-service-account` in the `default` namespace: + + + "oidc.eks.region-code.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:sub": "system:serviceaccount:default:my-service-account" + +### Step 3: Attach the AssumeRole permission to Account A’s role + +Account A attaches a permission policy to the role created in Step 2. This policy allows the role to assume Account B’s role. + +**Permission policy for Account A’s role** — This policy grants `sts:AssumeRole` on Account B’s target role. @@ -81,0 +112,2 @@ Account A attaches a policy to that role with the following permissions to assum +### Step 4: Configure the Pod to chain roles +