How to set up a Kubernetes service account to take an AWS Identity and Access Management (IAM) role using EKS Pod Identity. Any Pods that are set up to use the service account can then access any AWS service that the role has permission to access.
An EKS Pod Identity association can be created in a single step using the AWS Management Console, AWS CLI, AWS SDKs, AWS CloudFormation, and other technologies. There is no data or information about the cluster's affiliations in any Kubernetes objects, and you do not annotate the service accounts.
Prerequisites:
- An existing cluster.
- The IAM principal that is creating the association must have iam:PassRole.
- The latest version of the AWS CLI installed and configured on your device or AWS CloudShell. You can check your current version with aws --version | cut -d / -f2 | cut -d ' ' -f1. Package managers such yum, apt-get, or Homebrew for macOS are often several versions behind the latest version of the AWS CLI.
- The kubectl command line tool is installed on your device or AWS CloudShell. The version can be the same as or up to one minor version earlier or later than the Kubernetes version of your cluster. For example, if your cluster version is 1.29, you can use kubectl version 1.28, 1.29, or 1.30 with it.
- An existing kubectl config file that contains your cluster configuration. To create a kubectl config file
Creating the EKS Pod Identity association
Open the Amazon EKS console at https://console.aws.amazon.com/eks/home#/clusters.
In the left navigation pane, select Clusters, and then select the name of the cluster that you want to configure the EKS Pod Identity Agent add-on for.
Choose the Access tab.
In the Pod Identity associations, choose Create.
For the IAM role, select the IAM role with the permissions that you want the workload to have.
Note
The list only contains roles that have the following trust policy which allows EKS Pod Identity to use them.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowEksAuthToAssumeRoleForPodIdentity",
"Effect": "Allow",
"Principal": {
"Service": "pods.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
sts:AssumeRole
EKS Pod Identity uses AssumeRole to assume the IAM role before passing the temporary credentials to your pods.
sts:TagSession
EKS Pod Identity uses TagSession to include session tags in the requests to AWS STS.
You can use these tags in the condition keys in the trust policy to restrict which service accounts, namespaces, and clusters can use this role.
For a list of Amazon EKS condition keys, see Conditions defined by Amazon Elastic Kubernetes Service in the Service Authorization Reference. To learn which actions and resources you can use a condition key with, see Actions defined by Amazon Elastic Kubernetes Service.
For the Kubernetes namespace, select the Kubernetes namespace that contains the service account and workload. Optionally, you can specify a namespace by name that doesn't exist in the cluster.
For the Kubernetes service account, select the Kubernetes service account to use. The manifest for your Kubernetes workload must specify this service account. Optionally, you can specify a service account by name that doesn't exist in the cluster.
(Optional) For the Tags, choose Add tag to add metadata in a key and value pair. These tags are applied to the association and can be used in IAM policies.
You can repeat this step to add multiple tags.
- Choose Create.
Confirm configuration
Confirm that the role and service account are configured correctly.
- Confirm that the IAM role's trust policy is configured correctly.
aws iam get-role --role-name my-role --query Role.AssumeRolePolicyDocument
- Confirm that the policy that you attached to your role in a previous step is attached to the role.
aws iam list-attached-role-policies --role-name my-role --query AttachedPolicies[].PolicyArn --output text
- View the default version of the policy.
aws iam get-policy --policy-arn $policy_arn
---
Top comments (0)