EKS Pod Identity IAM delivery for applications

At the last AWS re:Invent in 2023, the EKS Pod Identity emerged as an AWS feature that promises to further enhance security and efficiency in identity management within Kubernetes environments. This article explores the foundations and benefits of EKS Pod Identity, outlining its crucial role in advancing security and simplifying containerized application development.

Handling identity in Kubernetes environments can be a real puzzle. The whole process of granting the right permissions to containers to do what they need without giving them free rein is like walking on a tightrope. In the past, connecting Kubernetes identities to external systems, such as IAM in the cloud, was a bit like mixing water and oil. A mess! Manually tinkering with credentials without a unified solution was a guarantee of headaches and security risks.

It's in this scenario that EKS Pod Identity comes into play, introduced as a kind of turbocharged evolution of IAM Roles for Service Accounts (IRSA). EKS Pod Identity emerges to upgrade the identity game in Kubernetes environments. While IRSA in the past already brought the power to associate IAM roles with service accounts, now, with Pod Identity, things get even more interesting. Imagine a version 2.0 that makes life even easier for developers and enhances security in clusters. Pod Identity takes a step forward by simplifying the association of AWS identities directly to running pods in Kubernetes.

And that's what we are going to learn today – how EKS Pod Identity works, how we can configure it in our cluster, and the key points compared to IRSA.

EKS Pod Identity incurs no additional costs for your EKS environment. This feature is available starting from version 1.24, and it is essential that your applications are using the latest versions of their respective SDKs to ensure full compatibility.

To start using Pod Identity, unlike IRSA, it is necessary to install a plugin on our cluster. Simply access your EKS cluster, choose the "Add-ons" option, select "Get mode add-ons," and look for the EKS Pod Identity Agent.

To begin using EKS Pod Identity, simply follow the steps in the wizard and choose the latest available version. With the plugin installed, let's now configure a simple application that we have used as an example in previous articles, involving access to an S3 bucket. Our next step is to understand the changes in the IAM policy.

First, let's create a role by adding a trust relationship through trust relationships. To create the role, let's assume that we will use the namespace eks-s3-example, and the service account that will have permission to access the role will be eks-s3-example-iam-role-sa.

For the configuration to take effect, we need to set up the trust relationship using pods.eks.amazonaws.com as the principal:

 With the JSON file created, let's now create the permission role (Role) using the AWS CLI.

For the lab, we'll need to create an S3 bucket. This process can be executed through the AWS console or using the CLI with the following command. Remember that the bucket name needs to be globally unique, so insert a custom name:

Well, at this stage of the game, we should have everything created. To carry out a test, let's create a job manifest. For everything to work the way we expect, we need to create the namespace:

To create the service account, run the command below on your machine to create the manifest file, once again:

Simply create our Job following the manifesto below, remember to replace <BUCKET-NAME> with the name of your previously created bucket:

 Execute the command kubectl create -f <FILE-NAMES> to create the resources in your EKS cluster.
 

Now, we need to navigate to the Access tab in our EKS cluster. In the Pod Identity associations section, select the option "Create Pod Identity association" to map my IAM role to the Kubernetes pods.

Select the options related to the role, namespace, and service account, and complete the association.

For a better understanding of the execution, if there's a file named "aws.png" in the bucket, the result of listing the bucket should be similar to the one below:

This is the plugin that arrives to revolutionize the way IAM identities are delivered to applications within EKS, simplifying the process of creating and associating identities for the EKS environment.

It proves to be a great alternative to the complex trust relationships that we had to configure previously using IRSA. I really liked the integration and the graphical ease of making changes and assigning permissions. I hope that soon we'll have this functionality for Infrastructure as Code (IaC) tools, as until today, I haven't identified anything related in the Terraform documentation.