Skip to content
Latchkey

EKS "aws-auth" ConfigMap - Fix Unauthorized IAM Mapping in CI

On EKS, an IAM identity only becomes a Kubernetes subject if it is mapped - historically via the aws-auth ConfigMap in kube-system, now also via EKS access entries. A CI role that authenticates to AWS but is not mapped is treated as anonymous and denied.

What this error means

kubectl against an EKS cluster fails with error: You must be logged in to the server (Unauthorized) even though aws sts get-caller-identity succeeds. The IAM role is valid; it is just not mapped to any Kubernetes group/user.

kubectl output
$ aws sts get-caller-identity   # works
$ kubectl get pods
error: You must be logged in to the server (the server has asked for the client to
provide credentials)

Common causes

CI role missing from aws-auth / access entries

The IAM role CI assumes is not listed in the aws-auth ConfigMap’s mapRoles (or as an EKS access entry), so EKS cannot resolve it to a Kubernetes identity.

Mapped to a group with no RBAC

The role is mapped but to a Kubernetes group that has no Role/ClusterRole binding, so authentication succeeds and authorization still fails.

How to fix it

Map the IAM role (modern: access entries)

Prefer EKS access entries over hand-editing the ConfigMap.

Terminal
aws eks create-access-entry --cluster-name my-cluster \
  --principal-arn arn:aws:iam::123456789012:role/ci-deployer
aws eks associate-access-policy --cluster-name my-cluster \
  --principal-arn arn:aws:iam::123456789012:role/ci-deployer \
  --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSEditPolicy \
  --access-scope type=namespace,namespaces=ci

Or add it to the aws-auth ConfigMap

On clusters still using aws-auth, add a mapRoles entry binding the role to Kubernetes groups.

aws-auth configmap
# kubectl edit -n kube-system configmap/aws-auth
mapRoles: |
  - rolearn: arn:aws:iam::123456789012:role/ci-deployer
    username: ci-deployer
    groups: [ "system:masters" ]   # scope down in practice

How to prevent it

  • Manage EKS access via access entries (or aws-auth) in Terraform, not ad hoc edits.
  • Map CI roles to least-privilege groups with explicit RBAC bindings.
  • Verify access with kubectl auth can-i after mapping a new role.

Related guides

Tired of flaky CI? Latchkey auto-heals failed jobs and retries them for you. Start free →