Leveraging EKS Pod Identity on AWS EKS (Part 2 of 3): Cluster Management

In Part 1 of this series, “Securing Application Access”, we established EKS Pod Identity as the modern standard for granting your Kubernetes applications secure, fine-grained access to AWS services. We covered how it moves beyond legacy methods to deliver a true least-privilege permissions model.

Now, let’s extend that best practice to the operational software that runs in your EKS cluster. This post will explore how you can simplify EKS cluster administration by using Amazon EKS Add-Ons and securing them with the same streamlined permissions model of EKS Pod Identity, creating a single, unified security strategy for your entire cluster.

What Are EKS Add-Ons and Why Use Them?

EKS Add-Ons are curated software packages provided by AWS that provide essential operational capabilities for your EKS cluster. Think of components like the AWS EBS CSI Driver for storage, CoreDNS for service discovery, or kube-proxy for network routing.

The core problem they solve is lifecycle management. Instead of you manually installing, configuring, and updating this critical software—a process prone to errors and version mismatches—AWS manages it for you. EKS Add-Ons ensure that you are running versions that are validated by AWS, complete with the latest security patches and bug fixes, which brings stability and security to your clusters.

AWS provides a centralized dashboard for visibility into the health and status of your Add-Ons. Within the AWS Management Console, you can navigate to your EKS cluster and select the “Add-ons” tab. Here, you’ll find a list of all installed add-ons, their current versions, and their health status. This integrated view is invaluable for operators, offering a quick and easy way to confirm that critical cluster components are running as expected without needing to connect to the cluster and run multiple kubectl commands.

The Evolution of Permissions: From OIDC to Pod Identity

Many EKS add-ons need to interact with AWS services. For example, the AWS EBS CSI Driver needs permissions to create and delete EBS volumes on your behalf. Traditionally, this was handled using IAM Roles for Service Accounts (IRSA), which relies on an OIDC connect provider.

While effective, the OIDC method has several administrative hurdles:

• You must first create an IAM OIDC provider for your EKS cluster.
• The IAM role’s trust policy is complex. It requires referencing the OIDC provider’s ARN and stipulating the specific service account in a federated trust relationship.

This process adds extra steps and resources to manage, increasing the overall complexity of your deployment.

A Better Way: EKS Pod Identity for Add-Ons

As we detailed in Part 1, EKS Pod Identity is a superior approach that associates IAM roles directly with Kubernetes service accounts. The great news is that this same simplified, secure method can and should be used to give EKS Add-Ons permissions to AWS services.

Using Pod Identity is easier to manage for two key reasons:

1. No OIDC Provider Needed: You can skip the entire process of creating and managing an IAM OIDC Provider for your cluster.
2. Dramatically Simpler Trust Policies: The trust policy on the IAM role becomes incredibly straightforward. Instead of a complicated federated policy, you simply trust the EKS Pod Identity service principal: pods.eks.amazonaws.com.

Using EKS Pod Identity to enable access to AWS services for both EKS Add-Ons and the application workloads from Part 1 creates a single, unified permissions model, making your security posture consistent and easier to audit.

Terraform in Action: Deploying the EBS CSI Driver with Pod Identity

Let’s walk through a complete Terraform example of deploying the aws-ebs-csi-driver add-on and securing it with EKS Pod Identity. The add-on’s controller runs in the kube-system namespace and uses the ebs-csi-controller-sa service account by default.

First, we’ll define the IAM role and attach the AWS-managed policy. Notice the simplified assume_role_policy that trusts the EKS Pod Identity service.

# IAM Role and Policy for the EBS CSI Driver Add-On
resource "aws_iam_role" "ebs_csi_driver_role" {
  name = "my-cluster-ebs-csi-driver-role"

  # Simplified trust policy for EKS Pod Identity
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect = "Allow"
        Principal = {
          Service = "pods.eks.amazonaws.com"
        }
        Action = "sts:AssumeRole"
      },
    ]
  })
}

# Attach the AWS-managed policy for the EBS CSI Driver
resource "aws_iam_role_policy_attachment" "ebs_csi_driver_attachment" {
  role       = aws_iam_role.ebs_csi_driver_role.name
  policy_arn = "arn:aws:iam::aws:policy/service-role/AmazonEBSCSIDriverPolicy"
}

Now, we deploy the EKS Add-On itself. You can configure the Pod Identity association directly within the aws_eks_addon resource. This makes the configuration much cleaner because you don’t need a separate association resource. For managed add-ons, the Terraform provider automatically infers the correct namespace (kube-system in this case).

# Assumes the eks-pod-identity-agent from Part 1 is already configured
# resource "aws_eks_addon" "pod_identity" { ... }

# Deploy the aws-ebs-csi-driver Add-On with Pod Identity Association
resource "aws_eks_addon" "ebs_csi" {
  cluster_name = aws_eks_cluster.main.name
  addon_name   = "aws-ebs-csi-driver"

  # Configure Pod Identity association directly in the add-on.
  # The namespace is inferred by the provider for this add-on.
  pod_identity_association {
    service_account = "ebs-csi-controller-sa"
    role_arn        = aws_iam_role.ebs_csi_driver_role.arn
  }

  # Ensure the Pod Identity agent add-on is running first
  depends_on = [aws_eks_addon.pod_identity]
}

Conclusion and Next Steps

We’ve now extended our secure foundation to cover the operational components of our cluster. By combining the lifecycle benefits of EKS Add-Ons with the streamlined security of EKS Pod Identity, you significantly reduce administrative overhead and harden your cluster’s security. This unified approach removes the need to manage OIDC providers and simplifies IAM role trusts.

But what happens when your applications need to reach beyond the boundaries of a single AWS account? In Part 3 of this series, “Simplifying Cross-Account Access,” we will tackle this advanced scenario, demonstrating how to use EKS Pod Identity to grant secure access to resources in other AWS accounts, completing our comprehensive guide to modern EKS IAM.