Securing EKS Pods with IAM Roles for Service Accounts (IRSA)

Historically, providing AWS credentials to applications running inside a Kubernetes cluster meant attaching a broad IAM role to the underlying EC2 worker nodes. This violated the principle of least privilege, as any pod on that node could access resources meant for other applications.

IAM Roles for Service Accounts (IRSA) completely resolves this security flaw. By utilizing OpenID Connect (OIDC), IRSA allows you to map specific AWS IAM roles directly to Kubernetes Service Accounts. This ensures that a pod running a FinTech microservice can access its specific S3 bucket, while a neighboring pod cannot.

To implement IRSA, you first establish an OIDC provider for your EKS cluster in AWS IAM. Then, you create an IAM role with a trust policy allowing the specific Kubernetes namespace and service account to assume it. Finally, you annotate the Kubernetes Service Account with the Role ARN.

resource "kubernetes_service_account" "app_sa" {
  metadata {
    name      = "my-app-sa"
    namespace = "production"
    annotations = {
      "eks.amazonaws.com/role-arn" = aws_iam_role.app_role.arn
    }
  }
}

# The IAM Trust Policy mapped to the OIDC provider
data "aws_iam_policy_document" "irsa_trust" {
  statement {
    actions = ["sts:AssumeRoleWithWebIdentity"]
    principals {
      type        = "Federated"
      identifiers = [aws_iam_openid_connect_provider.eks.arn]
    }
    condition {
      test     = "StringEquals"
      variable = "${replace(aws_iam_openid_connect_provider.eks.url, "https://", "")}:sub"
      values   = ["system:serviceaccount:production:my-app-sa"]
    }
  }
}