How does EKS IAM authentication work

Crisp answer: EKS uses AWS IAM for authentication and Kubernetes RBAC for authorisation. When you run kubectl, the AWS SDK signs the request with your IAM credentials to generate a token. EKS validates the token against IAM. Kubernetes then checks RBAC to authorise the action.

The authentication flow:

kubectl get pods
  ↓
aws-iam-authenticator generates a pre-signed STS GetCallerIdentity URL
  ↓
This URL is base64-encoded as the bearer token
  ↓
EKS API server receives the token
  ↓
EKS calls STS GetCallerIdentity to verify the IAM identity
  ↓
IAM identity is mapped to a Kubernetes user/group
  ↓
Kubernetes RBAC checks if the user/group can perform the action

Two ways to manage access:

1. aws-auth ConfigMap (legacy, still common):

kubectl get configmap aws-auth -n kube-system -o yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: aws-auth
  namespace: kube-system
data:
  mapRoles: |
    - rolearn: arn:aws:iam::123456789:role/NodeInstanceRole
      username: system:node:{{EC2PrivateDNSName}}
      groups:
        - system:bootstrappers
        - system:nodes
    - rolearn: arn:aws:iam::123456789:role/DevTeamRole
      username: dev-team
      groups:
        - dev-group
  mapUsers: |
    - userarn: arn:aws:iam::123456789:user/alice
      username: alice
      groups:
        - system:masters   # cluster-admin

Critical warning: Editing aws-auth incorrectly can lock everyone out of the cluster. Always have a backup and test with a non-admin user first. The cluster creator's IAM identity always retains cluster-admin access.

2. EKS Access Entries (new in EKS 1.29+, recommended):

# Grant an IAM role access to the cluster
aws eks create-access-entry \
  --cluster-name my-cluster \
  --principal-arn arn:aws:iam::123456789:role/DevTeamRole \
  --type STANDARD

# Attach a managed access policy
aws eks associate-access-policy \
  --cluster-name my-cluster \
  --principal-arn arn:aws:iam::123456789:role/DevTeamRole \
  --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy \
  --access-scope type=cluster

# Built-in access policies:
# AmazonEKSClusterAdminPolicy  — cluster-admin
# AmazonEKSAdminPolicy         — most admin actions
# AmazonEKSEditPolicy          — create/update/delete most resources
# AmazonEKSViewPolicy          — read-only

Why access entries are better:

• No risk of corrupting a ConfigMap and losing cluster access
• Managed via AWS IAM, not kubectl — consistent with AWS access control
• Supports AWS Organizations and permission boundaries
• Auditable via CloudTrail

Getting kubeconfig:

# Standard: uses your current AWS profile
aws eks update-kubeconfig --name my-cluster --region eu-west-2

# As a specific role:
aws eks update-kubeconfig \
  --name my-cluster \
  --region eu-west-2 \
  --role-arn arn:aws:iam::123456789:role/EKSAdminRole

# Check who you are authenticated as:
kubectl auth whoami
aws sts get-caller-identity

What to say in the interview:

"EKS authentication is two-stage: IAM for identity, RBAC for authorisation. kubectl generates a pre-signed STS token, EKS validates it with IAM to identify who you are, then Kubernetes RBAC determines what you can do. Historically access was managed via the aws-auth ConfigMap, but in newer clusters I prefer EKS Access Entries — they are managed via the AWS API, auditable via CloudTrail, and you cannot accidentally lock yourself out by editing a ConfigMap incorrectly."