AWS eks medium security documentation change
Summary
Updated EKS Pod Identity documentation with enhanced security controls: Added PrincipalTags/ExternalId conditions in trust policy examples, removed optional delegation step, and clarified cross-account access patterns.
Security assessment
Added explicit security controls using PrincipalTags (eks-cluster-arn, kubernetes-namespace, kubernetes-service-account) and sts:ExternalId in IAM trust policies. These changes implement attribute-based access control (ABAC) to restrict role assumption to specific EKS resources, mitigating confused deputy risks. The removal of the external delegation section suggests consolidation of security best practices into core documentation.
Diff
diff --git a/eks/latest/userguide/pod-id-assign-target-role.md b/eks/latest/userguide/pod-id-assign-target-role.md index 9337cdcdb..030336fdc 100644 --- a//eks/latest/userguide/pod-id-assign-target-role.md +++ b//eks/latest/userguide/pod-id-assign-target-role.md @@ -5 +5 @@ -PrerequisitesHow It WorksCaching considerationsStep 1: Create and associate a Target IAM RoleStep 2: Associate the Target IAM Role to a Kubernetes service account(Optional) Step 3: Add External Permissions to an IAM Target Role +PrerequisitesHow It WorksCaching considerationsStep 1: Create and associate a Target IAM RoleStep 2: Associate the Target IAM Role to a Kubernetes service account @@ -13 +13 @@ To contribute to this user guide, choose the **Edit this page on GitHub** link t -When running applications on Amazon Elastic Kubernetes Service (Amazon EKS), you might need to access AWS resources that exist in the same or different AWS accounts. This guide shows you how to set up access between these accounts using EKS Pod Identity, which enables your Kubernetes pods to access other AWS resources. +When running applications on Amazon Elastic Kubernetes Service (Amazon EKS), you might need to access AWS resources that exist in different AWS accounts. This guide shows you how to set up cross account access using EKS Pod Identity, which enables your Kubernetes pods to access other AWS resources using target roles. @@ -28 +28,3 @@ Before you begin, ensure you have completed the following steps: -Pod Identity enables applications in your EKS cluster to access AWS resources across accounts through a process called role chaining. When creating a Pod Identity association, you can provide two IAM roles—an [EKS Pod Identity role](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) in the same account as your EKS cluster and a Target IAM Role from the account containing your AWS resources (like S3 buckets or DynamoDB tables). The [EKS Pod Identity role](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) must be in your EKS cluster’s account due to [IAM PassRole](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_iam-passrole-service.html) requirements, while the Target IAM Role can be in any AWS account. PassRole enables an AWS entity to delegate role assumption to another service. EKS Pod Identity uses PassRole to connect a role to a Kubernetes service account, requiring both the role and the identity passing it to be in the same AWS account as the EKS cluster. When your application pod needs to access AWS resources, it requests credentials from Pod Identity. Pod Identity then automatically performs two role assumptions in sequence: first assuming the [EKS Pod Identity role](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html), then using those credentials to assume the Target IAM Role. This process provides your pod with temporary credentials that have the permissions defined in the target role, allowing secure access to resources in other AWS accounts. +Pod Identity enables applications in your EKS cluster to access AWS resources across accounts through a process called role chaining. + +When creating a Pod Identity association, you can provide two IAM roles: an [EKS Pod Identity role](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) in the same account as your EKS cluster and a Target IAM Role from the account containing your AWS resources you wish to access, (like S3 buckets or RDS Databases). The [EKS Pod Identity role](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) must be in your EKS cluster’s account due to [IAM PassRole](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_iam-passrole-service.html) requirements, while the Target IAM Role can be in any AWS account. PassRole enables an AWS entity to delegate role assumption to another service. EKS Pod Identity uses PassRole to connect a role to a Kubernetes service account, requiring both the role and the identity passing it to be in the same AWS account as the EKS cluster. When your application pod needs to access AWS resources, it requests credentials from Pod Identity. Pod Identity then automatically performs two role assumptions in sequence: first assuming the [EKS Pod Identity role](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html), then using those credentials to assume the Target IAM Role. This process provides your pod with temporary credentials that have the permissions defined in the target role, allowing secure access to resources in other AWS accounts. @@ -32 +34 @@ Pod Identity enables applications in your EKS cluster to access AWS resources ac -Due to caching mechanisms, updates to an IAM role in an existing Pod Identity association may not take effect immediately in the pods running on your EKS cluster. The Pod Identity Agent caches IAM credentials based on the association’s configuration at the time the credentials are fetched. If the association includes only an [EKS Pod Identity role](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) ARN and no Target IAM Role, the cached credentials last for 6 hours. If the association includes both the [EKS Pod Identity role](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) ARN and a Target IAM Role, the cached credentials last for 59 minutes. Modifying an existing association, such as updating the [EKS Pod Identity role](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) ARN or adding a Target IAM Role, does not reset the existing cache. As a result, the agent will not recognize updates until the cached credentials refresh. To apply changes sooner, you can recreate the existing pods; otherwise, you will need to wait for the cache to expire. +Due to caching mechanisms, updates to an IAM role in an existing Pod Identity association may not take effect immediately in the pods running on your EKS cluster. The Pod Identity Agent caches IAM credentials based on the association’s configuration at the time the credentials are fetched. If the association includes only an [EKS Pod Identity role](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) and no Target IAM Role, the cached credentials last for 6 hours. If the association includes both the [EKS Pod Identity role](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) ARN and a Target IAM Role, the cached credentials last for 59 minutes. Modifying an existing association, such as updating the [EKS Pod Identity role](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) ARN or adding a Target IAM Role, does not reset the existing cache. As a result, the agent will not recognize updates until the cached credentials refresh. To apply changes sooner, you can recreate the existing pods; otherwise, you will need to wait for the cache to expire. @@ -65 +67,5 @@ In this step, you will establish a secure trust chain by creating and configurin - 4. In the policy editor, replace the default JSON with your trust policy. Replace the placeholder values for role name and `111122223333` in the IAM role ARN with the AWS account ID hosting your EKS cluster. For example: + 4. In the policy editor, replace the default JSON with your trust policy. Replace the placeholder values for role name and `111122223333` in the IAM role ARN with the AWS account ID hosting your EKS cluster. You can also optionally use PrincipalTags in the role trust policy to authorize only specific service accounts from a given cluster and namespace to assume your target role . For example: + + + + @@ -66,0 +73,25 @@ In this step, you will establish a secure trust chain by creating and configurin + { + "Version": "2012-10-17", + "Statement": [ + { + "Effect": "Allow", + "Principal": { + "AWS": "arn:aws:iam::111122223333:root" + }, + "Action": [ + "sts:AssumeRole", + "sts:TagSession" + ], + "Condition": { + "StringEquals": { + "aws:PrincipalTag/eks-cluster-arn": "arn:aws:eks:us-east-1:111122223333:cluster/example-cluster", + "aws:PrincipalTag/kubernetes-namespace": "ExampleNameSpace", + "aws:PrincipalTag/kubernetes-service-account": "ExampleServiceAccountName" + }, + "ArnEquals": { + "aws:PrincipalARN": "arn:aws:iam::111122223333:role/eks-pod-identity-primary-role" + } + } + } + ] + } @@ -67,0 +99 @@ In this step, you will establish a secure trust chain by creating and configurin +The above policy policy lets the role `eks-pod-identeity-primary-role` from AWS account 111122223333 with the relevant [EKS Pod Identity Session Tags](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-abac.html) assume this role. @@ -68,0 +101 @@ In this step, you will establish a secure trust chain by creating and configurin +If you [Disabled Session Tags](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-abac.html#pod-id-abac-tags) in your EKS Pod Identity, EKS Pod Identity also sets the `sts:ExternalId` with information about the cluster, namespace, and service account of a pod when assuming a target role. @@ -77 +110 @@ In this step, you will establish a secure trust chain by creating and configurin - "AWS": "arn:aws:iam::111122223333:role/eks-pod-identity-primary-role" + "AWS": "arn:aws:iam::111122223333:root" @@ -79 +112,9 @@ In this step, you will establish a secure trust chain by creating and configurin - "Action": "sts:AssumeRole" + "Action": "sts:AssumeRole", + "Condition": { + "StringEquals": { + "sts:ExternalId": "region/111122223333/cluster-name/namespace/service-account-name" + }, + "ArnEquals": { + "aws:PrincipalARN": "arn:aws:iam::111122223333:role/eks-pod-identity-primary-role" + } + } @@ -84 +125 @@ In this step, you will establish a secure trust chain by creating and configurin - "AWS": "arn:aws:iam::111122223333:role/eks-pod-identity-primary-role" + "AWS": "arn:aws:iam::111122223333:root" @@ -90,0 +132,2 @@ In this step, you will establish a secure trust chain by creating and configurin +The above policy helps ensure that only the expected cluster, namespace and service account can assume the target role. + @@ -152,42 +194,0 @@ In this step, you will create an association between the Target IAM role and the -## (Optional) Step 3: Add External Permissions to an IAM Target Role - -At times, you might need to give a third party access to your AWS resources (delegate access). For example, you decide to hire a third-party company called Example Corp to monitor your AWS account and help optimize costs. In order to track your daily spending, Example Corp needs to access your AWS resources. In this case, we recommend adding an `ExternalId` to the trust policy of your IAM Target Role to avoid possible [Confused Deputy](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html) issues. - -### Edit the trust policy - - 1. After creating the role, you’ll be returned to the **Roles** list. Find and click the new role you created in the previous step (e.g., `MyCustomIAMTargetRole`). - - 2. Select the **Trust relationships** tab. - - 3. Click **Edit trust policy** on the right side. - - 4. In the policy editor, replace the default JSON with your trust policy. Replace the `ExternalId` placeholder value for `aws-region/other-account/cluster-name/namespace/service-account-name`, where "region" is the AWS region of your cluster, "111122223333" is the other AWS account ID, "cluster-name" is the EKS cluster name, "namespace" is the Kubernetes namespace, and "service-account-name" is the Kubernetes service account name. For example: - - - - - - { - "Version": "2012-10-17", - "Statement": [ - { - "Effect": "Allow", - "Principal": { - "AWS": "arn:aws:iam::111122223333:role/eks-pod-identity-primary-role" - }, - "Action": "sts:AssumeRole", - "Condition": { - "StringEquals": { - "sts:ExternalId": "region/111122223333/cluster-name/namespace/service-account-name" - } - }, - { - "Effect": "Allow", - "Principal": { - "AWS": "arn:aws:iam::111122223333:role/eks-pod-identity-primary-role" - }, - "Action": "sts:TagSession" - } - ] - } -