In Kubernetes, Role-Based Access Control is essential for securing your cluster. In 2019, AWS introduced IAM roles for service accounts (IRSA).
Also, we mentioned IRSA in one of our blog posts here.
Briefly, IRSA lets you associate an IAM role with a Kubernetes service account. It helps you to implement the principle of least privilege by giving pods only the permissions they need.
With Amazon EKS Pod Identity, it’s even easier to configure and automate granting AWS permissions to Kubernetes identities. As the cluster administrator, you no longer need to switch between Amazon EKS and IAM services to authenticate your applications to all AWS resources.
Let’s start by discussing the differences between IRSA and EKS Pod Identity.
If you’re wondering which one is better, here’s a key advantage of using Pod Identity: figuring out which pod can access a specific role in AWS is much easier. You can do this easily by calling ListPodIdentityAssociations. ( Please see here.)
On the other hand, with IRSA, it’s a bit more complex. You have to find IAM roles connected to the cluster’s OIDC provider, analyse some conditions in their policies, and then match those to your pods.
Another perk of Pod Identity is that you can set everything up through the AWS API without needing in-cluster interactions. With IRSA, you have to label service accounts with eks.amazonaws.com/role-arn explicitly.
Another advantage of Pod Identity is that you don’t have to worry about the IAM OIDC provider. With Pod Identity, we won’t need an OIDC provider to give access to the pods.
Steps to start using Amazon EKS Pod Identity can be summarised in a few simple steps:
Once it’s done, any new pods that use that service account will automatically be configured to receive IAM credentials.
Let’s get our hands dirty!
For the demonstration in this post, we need to configure permission for the pod running in the Amazon EKS cluster, which will return the list of objects in the Amazon Simple Storage Service (Amazon S3) bucket.
We can start creating an IAM Role using AWS CLI. First, Let’s create the Trust Policy JSON:
$ cat <<EOF >> Test-Role-Trust-Policy.json |
And using the following AWS CLI command, create the role named EKS-Pod-Identity-Role.
$ aws iam create-role \ |
Now we are ready to create a Policy JSON file:
$ cat <<EOF >> eks-pod-identity-role-for-s3.json { EOF |
And we can attach it to the role we created with the following command:
$ aws iam put-role-policy --role-name EKS-Pod-Identity-Role |
For the sake of the demo, we will give access to the S3 bucket. For that purpose, we’ll create a new bucket. I’ll create a bucket with the name kadir-test-eks-pod-identity. Please don’t forget to change the <BUCKET_NAME> on the eks-pod-identity-role-for-s3.json.
For demonstration, we will upload a test file to the bucket and see if we can access it through the pod on AWS EKS.
Assuming you have an EKS Cluster. If you don’t have an EKS cluster, You can create a new one using eksctl or AWS CLI command.
For demo purposes, we will create a cluster named eks-pod-identity-test-cluster. You can use the following command:
$ eksctl create cluster --name eks-pod-identity-test-cluster --region eu-west-2 |
For detailed information, please visit here
At this stage, the IAM role is ready, and now we need to configure the Amazon EKS Pod Identity Agent in the cluster.
We can use the aws eks create-addon command to install the Amazon EKS Pod Identity Agent add-on into the EKS cluster. Here’s the AWS CLI command:
$ aws eks create-addon \ |
Or, you can use the eksctl command as well:
$ eksctl create addon --cluster eks-pod-identity-test-cluster --name eks-pod-identity-agent |
The output should be as follows:
2023-11-29 20:45:05 [!] no IAM OIDC provider associated with the cluster, try ‘eksctl utils associate-iam-oidc-provider --region=eu-west-2 --cluster=eks-pod-identity-test-cluster’ 2023-11-29 20:45:05 [ℹ] Kubernetes version “1.27” in use by cluster “eks-pod-identity-test-cluster” 2023-11-29 20:45:06 [ℹ] creating addon 2023-11-29 20:46:12 [ℹ] addon “eks-pod-identity-agent” active |
I want you to pay attention to this output. As you can see, no IAM OIDC provider is associated with the cluster. Because with Pod Identity, we won’t need an OIDC provider to give access to the pods.
We need to navigate to the Access tab in the EKS cluster. In the Pod Identity Associations section, we can select Create Pod Identity Association to map the IAM role to Kubernetes pods.
Note: If the namespace and Service account doesn’t exist yet, We can type the names. If they already exist, We can select them from the dropdown menu. Then, We can proceed with Create.
We can create the namespace and service account with the following commands:
$ kubectl create namespace pod-identity-assoc-namespace $ kubectl create serviceaccount pod-identity-assoc-sa -n pod-identity-assoc-namespace |
And using the following command, We can create a Pod Identity Association:
$ aws eks create-pod-identity-association \ |
The output should look as below:
{ |
Those are all the steps we need to do to configure IAM permissions for the applications running on Amazon EKS with EKS Pod Identity. We can see the IAM role is listed in Pod Identity associations.
$ cat << EOF >> deployment.yaml $ kubectl apply -f deployment.yaml $ kubectl logs pod-identity-assoc-deployment-86b689fc7b-cm6rc -n pod-identity-assoc-namespace |
The output is as follows:
arn:aws:sts::<REDACTED>:assumed-role/EKS-Pod-Identity-Role/eks-eks-pod- {'ResponseMetadata': {'RequestId': 'VRP9Q49P4K259M24', 'HostId': |
As you can see from the output, we got the bucket object as an output on the logs. Our pod could access the bucket using the IAM role we created.
Finally, it is worth mentioning that from now on, pods created in this namespace, with the specified service account annotation, will automatically up with these permissions and will be able to perform their operations using these permissions we have determined in the IAM Role associated with the Pod Identity.
Amazon EKS Pod Identity is a powerful feature that can simplify IAM permissions management for applications running on Amazon EKS clusters. By automatically assigning IAM roles to pods, EKS Pod Identity eliminates the need to manage IAM roles for each application manually. It helps to ensure that applications only have the permissions they need. This can save you time and effort and improve security.
Amazon EKS Pod Identity simplifies the experience of managing IAM roles for applications running on Amazon EKS. We can easily reuse IAM roles across multiple EKS clusters without updating the role trust policy each time a new cluster is created.
Another good part is Pricing – Amazon EKS Pod Identity is available at no charge.
If you run applications on Amazon EKS, let me encourage you to try EKS Pod Identity.
We hope this post helps you make your EKS clusters more secure and use Kubernetes service accounts effectively on AWS.
We also offer a Free Kubernetes Security Audit; if you’d like to hear more about it, please look at our Free Kubernetes Security Audit page.