Exploring the new EKS Pod Identity Functionality

One announcement that caught my attention in the EKS space during this year’s AWS re:Invent conference was the addition of the Amazon EKS Pod Identities feature. This new addition helps simplify the complexities of AWS Identity and Access Management (IAM) within Elastic Kubernetes Service (EKS). EKS Pod Identities simplify IAM credential management in EKS clusters, addressing a problematic area over the past few years as Microservice adoption has risen across the industry. 

EKS Pod Identities integrates Kubernetes service accounts with AWS IAM roles, thereby eliminating the cumbersome credential distribution and management process plaguing EKS administrators for some time. This new feature allows administrators to associate IAM roles directly with Kubernetes service accounts, ensuring that applications running in EKS have the necessary permissions to access AWS services efficiently and securely. The new feature simplifies IAM permissions management, which is essential for cloud-native app development.

A look at EKS Pod Identities

EKS Pod Identities is an attempt to improve IAM management in Kubernetes, especially for apps that need to interact with AWS services. This feature streamlines credential management, akin to Amazon EC2 instance profiles, by associating IAM roles with Kubernetes service accounts. This association allows Pods using these accounts to inherit IAM permissions automatically, simplifying credential management and enhancing security. Unlike traditional methods that involve distributing AWS credentials directly to containers or relying on an Amazon EC2 instance’s role, this approach seamlessly integrates IAM roles into the Kubernetes environment, making it easier for applications in Pods to authenticate and interact with AWS services.

Administrators can create identical associations in different clusters without modifying the IAM role’s trust policy, ensuring consistency in security practices across various deployments. When using a service account with an EKS Pod Identity, Amazon EKS automatically configures the necessary environment variables within containers. This automation instructs the AWS SDKs and CLI to utilize the EKS Pod Identity credentials, eliminating manual configuration and simplifying access to AWS services.

The use of EKS Pod Identities is based on the principle of least privilege, which means that applications are given only the necessary permissions, thereby minimizing the risk of unauthorized access. EKS Pod Identities are designed to simplify the management of AWS credentials in Kubernetes, enhancing the security and operational management of cloud-native applications.

EKS Pod Identities bring numerous benefits:

– Least Privilege: IAM permissions are scoped to specific service accounts, granting access only to the Pods using those accounts. This approach negates the need for third-party solutions like kiam or kube2iam.

– Credential Isolation: Containers in a Pod can only access credentials for the IAM role associated with their service account. This isolation ensures that containers don’t access credentials meant for other containers.

– Auditability: AWS CloudTrail facilitates access and event logging for retrospective auditing.

These identities are simpler than IAM roles for service accounts as they don’t rely on OIDC identity providers. They provide independent operations, reusability with a single IAM principal, and scalability by reducing credential load per node instead of per pod.

Setting Up EKS Pod Identities

To set up EKS Pod Identities in your cluster, you can either use the AWS CLI or the AWS management console. 

To get started with the Idenety agent via the CLI, install the EKS Pod Identity Agent on your cluster. You can do this by running the following AWS CLI command, ensuring that you replace the-cluster with the actual name of your cluster:

aws eks create-addon --cluster-name the-cluster --addon-name eks-pod-identity-agent --addon-version v1.0.0-eksbuild.1

It’s important to note that the EKS Pod Identity Agent operates differently from the IAM roles for service accounts; it doesn’t use the service-account-role-arn. Instead, you must provide the necessary permissions directly in the node role for the EKS Pod Identity Agent to function correctly.

Once you have executed the command to create the add-on, you should verify that the EKS Pod Identity Agent pods are actively running on your cluster. You can do this by executing the following kubectl command, which filters the relevant pods within the kube-system namespace:

kubectl get pods -n kube-system | grep 'eks-pod-identity-agent'

The expected output should list the eks-pod-identity-agent pods, showing their status as Running. 

Considerations and Compatibility

– One IAM Role per Service Account: Each Kubernetes service account in a cluster can associate with one IAM role, though this can be changed as needed.

– Account and Role Restrictions: Roles must be in the same AWS account as the cluster, with cross-account access delegated as necessary.

– EKS Pod Identity Agent: This agent, running as a Kubernetes DaemonSet, is essential for providing credentials to Pods.

It is also important to note that EKS Pod Identities are compatible with specific Amazon EKS cluster versions and require Linux Amazon EC2 instances as worker nodes. They are unavailable in China Regions, AWS GovCloud (US), AWS Outposts, Amazon EKS Anywhere, or Kubernetes clusters on Amazon EC2.

A Practical Use Case with Amazon DynamoDB

Let’s look at an example of an application that interacts with DynamoDB, running in an Amazon EKS cluster. To enable this application to access DynamoDB, we utilize the new EKS Pod Identities. The process starts with creating an IAM role, including the necessary DynamoDB permissions and setting pods.eks.amazonaws.com as the principal in the role’s trust policy:

{

    "Version": "2012-10-17",

    "Statement": [

        {

            "Effect": "Allow",

            "Principal": {

                "Service": "pods.eks.amazonaws.com"

            },

            "Action": "sts:AssumeRole"

        }

    ]

}

After the IAM role setup, we activate the Amazon EKS Pod Identity Agent add-on for the cluster and map the IAM role to the Kubernetes namespace and service account intended for the application.

Final Thoughts

Amazon EKS Pod Identities simplifies and secures the management of AWS IAM permissions for Kubernetes applications. Integrating IAM roles with Kubernetes service accounts enables a more efficient, auditable, and secure way of granting AWS service access to applications. This addition helps streamline administrative tasks, enhances overall security, and makes applications running on Amazon EKS more operationally efficient. Check out the AWS EKS pod identity docs to learn more about pod identities. 

While we are on the topic of EKS operational efficiencies, trace and troubleshoot your Kubernetes apps using Lumigo. Sign up for a free Lumigo account and automatically use our Kubernetes operator to trace a namespace in minutes!

Please share your thoughts if you found this article informative and helpful. Your feedback and engagement are appreciated and essential in helping shape future content. So, if you’ve found this post helpful, please consider liking, commenting, and sharing it with your network. Your interaction helps spread the word and supports the creation of more valuable resources like this.