Managing access control is crucial in the ever-evolving world of cloud-native applications, especially in Kubernetes environments where multiple pods and services require secure, scalable access to AWS resources. Traditionally, Kubernetes workloads running on Amazon Elastic Kubernetes Service (EKS) leveraged IAM Roles for Service Accounts (IRSA) to control permissions. However, EKS Pod Identities offers a new, simplified way to manage IAM access. In this post, we will explore the concept of EKS Pod Identities, compare it to IRSA, and provide a step-by-step guide to implementing this new IAM management strategy.

The Current State of IAM Access: The Challenges and Errors of IAM Roles for Service Accounts (IRSA)

IRSA has been a widely adopted method for granting Kubernetes pods access to AWS services using IAM roles. It works by associating service accounts in Kubernetes with IAM roles, allowing fine-grained control over which pods can access specific AWS resources. However, the IRSA process can introduce complexity:

  • Increased overhead: Managing multiple IAM roles and policies tied to individual service accounts can become cumbersome as workloads scale.
  • Potential for misconfigurations: Ensuring that the correct IAM roles are attached to service accounts across different namespaces or environments often leads to errors.
  • Debugging challenges: Identifying IAM permission issues within the Kubernetes ecosystem can be difficult, as error messages aren’t always intuitive, and troubleshooting often requires cross-referencing multiple services.

A Simpler Future with EKS Pod Identities: Introducing a Streamlined Approach to IAM Role Management

Enter EKS Pod Identities, a new feature that simplifies the IAM access management process for Kubernetes pods. EKS Pod Identities allows you to directly assign IAM roles to pods without using IRSA and Kubernetes service accounts. This streamlined approach offers:

  • Simplified role management: EKS Pod Identities reduces the need to create multiple roles for various service accounts by allowing IAM roles to be directly associated with the pods that need them.
  • Cluster-level security: Shifting IAM access management to the cluster level enhances security and reduces misconfiguration potential.
  • Easier troubleshooting: With direct IAM role assignments, debugging permission issues become more accessible, thanks to more meaningful error messages and reduced complexity.

Step-by-Step Guide to Implementing EKS Pod Identities

Let’s walk through implementing EKS Pod Identities in your Kubernetes cluster.

1. Creating IAM Roles

To get started, you need to create IAM roles that will be assigned to your pods. Each role must include a trust policy that allows the EKS Pod Identity to assume it.

aws iam create-role –role-name EKS-Pod-Identity-Role \

    –assume-role-policy-document file://trust-policy.json

The trust policy should specify that EKS can assume this role.

2. Installing the EKS Pod Identity Agent

Next, install the EKS Pod Identity Agent in your cluster. This agent manages the identity mappings between pods and IAM roles.

kubectl apply -f https://raw.githubusercontent.com/aws/eks-pod-identity/main/deploy.yaml

The agent will run as a DaemonSet across all nodes in your cluster, ensuring that every pod can access its assigned IAM role.

3. Attaching IAM Roles to Service Accounts

Attach the created IAM roles to the Kubernetes service accounts using annotations:

apiVersion: v1

kind: ServiceAccount

metadata:

  name: pod-access

  annotations:

    eks.amazonaws.com/role-arn: arn:aws:iam::<aws_account_id>:role/EKS-Pod-Identity-Role

This step ensures that any pod using the pod-access service account will automatically inherit the IAM role.

Creating and Deploying Kubernetes Resources

To validate the setup, create a Kubernetes namespace, service account, and a test pod to leverage the assigned IAM role.

  1. Create a namespace:

kubectl create namespace test-namespace

  1. Create a service account with the IAM role attached:

apiVersion: v1

kind: ServiceAccount

metadata:

  name: test-sa

  namespace: test-namespace

  annotations:

    eks.amazonaws.com/role-arn: arn:aws:iam::<aws_account_id>:role/EKS-Pod-Identity-Role

  1. Deploy a test pod using this service account to access an S3 bucket:

apiVersion: v1

kind: Pod

metadata:

  name: s3-access-pod

  namespace: test-namespace

spec:

  serviceAccountName: test-sa

  containers:

  – name: aws-cli

    image: amazon/aws-cli

    command: [ “/bin/sh”, “-c”, “aws s3 ls” ]

Validating Access and Permissions

After deploying the pod, you can check the logs to ensure they have access to your S3 bucket correctly.

kubectl logs s3-access-pod -n test-namespace

You should see a list of objects from your S3 bucket if everything is set up correctly. If permission errors exist, check the IAM role policies and ensure the EKS Pod Identity agent runs properly.

Navigating Potential Issues: Transitioning from Service-Level to Cluster-Level Access Management

While EKS Pod Identities simplifies role management, transitioning from service-level (IRSA) to cluster-level access can introduce challenges. Some potential issues to watch for include:

  • Misconfigured trust policies: Ensure that the IAM role trust policies allow EKS to assume the role.
  • Agent misconfiguration: Verify that the EKS Pod Identity Agent is running across all nodes in your cluster.

Important Considerations: Terraform Integration and EKS Pod Identity Restrictions

If you manage your infrastructure as code, you’ll want to integrate EKS Pod Identities with Terraform. By using Terraform, you can automate the creation of IAM roles, service accounts, and Kubernetes resources, reducing the potential for human error.

However, there are some restrictions to be aware of:

  • Role limits: EKS Pod Identities may limit the number of roles you can associate with pods in specific configurations.
  • Compatibility with older workloads: Ensure your existing workloads can be easily migrated to use EKS Pod Identities without disrupting their current IAM access.

Conclusion

EKS Pod Identities offers a new, streamlined way to manage IAM access for Kubernetes pods on AWS. By simplifying the process of attaching IAM roles to pods and enhancing security, it’s a welcome alternative to IRSA. With the step-by-step guide, you can explore this new approach to managing IAM access in your EKS clusters today.

References

A deep dive into simplified Amazon EKS access management controls

Amazon EKS Pod Identity: a new way for applications on EKS to obtain IAM credentials