🚨 AWS Error: 'You must be logged in to the server (Unauthorized)' — Cause, Fix, and Troubleshooting Guide

Overview

EKS authenticates kubectl with your AWS identity (via a signed STS token) and then authorizes it against a Kubernetes RBAC mapping. If your IAM principal isn’t mapped to any Kubernetes user/group — through an EKS access entry or the legacy aws-auth ConfigMap — the API server accepts the token but rejects the request. kubectl reports it as an authentication failure even though the real problem is authorization.

You will see it from kubectl against an EKS cluster:

error: You must be logged in to the server (Unauthorized)

It occurs whenever the AWS identity resolving your kubeconfig is not the cluster creator and has no access entry / aws-auth mapping, or when kubeconfig is pointed at the wrong role, account, or cluster.

Symptoms

• Every kubectl command (get nodes, get pods) returns You must be logged in to the server (Unauthorized).
• The cluster creator can run kubectl fine, but teammates or a CI role cannot.
• It started after switching IAM roles, rotating credentials, or someone cleaned up the aws-auth ConfigMap.

kubectl get nodes

error: You must be logged in to the server (Unauthorized)

Common Root Causes

1. Your IAM identity isn’t mapped in the cluster

The principal has no EKS access entry and no aws-auth mapping, so it maps to no Kubernetes group.

2. kubeconfig assumes a different role than you expect

The aws eks get-token command in kubeconfig uses a --role-arn (or a profile) that isn’t the mapped identity.

3. Wrong account, region, or cluster

kubeconfig points at a cluster in another account/region; your token is valid but for the wrong control plane.

4. The cluster uses access entries, not aws-auth (or vice versa)

On API/API_AND_CONFIG_MAP authentication mode, edits to aws-auth are ignored; you must create an access entry.

5. Expired or misconfigured credentials

The base AWS credentials aws eks get-token relies on are expired or resolve to a different identity than intended.

How to diagnose

Step 1: Confirm which AWS identity kubectl is actually using

aws sts get-caller-identity --query Arn --output text

arn:aws:iam::111122223333:role/ci-deployer

This is the ARN that must be mapped in the cluster.

Step 2: Confirm kubeconfig points at the right cluster

aws eks describe-cluster --name prod --query 'cluster.[arn,status,accessConfig.authenticationMode]' --output text
kubectl config current-context

Step 3: Check the cluster’s mappings

For access entries (current approach):

aws eks list-access-entries --cluster-name prod --output table

For the legacy ConfigMap (requires an identity that is mapped):

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

If your Step 1 ARN appears in neither, that is the cause.

Fixes

Add an EKS access entry (recommended)

aws eks create-access-entry --cluster-name prod \
  --principal-arn arn:aws:iam::111122223333:role/ci-deployer

aws eks associate-access-policy --cluster-name prod \
  --principal-arn arn:aws:iam::111122223333:role/ci-deployer \
  --access-scope type=cluster \
  --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy

Or map it in the aws-auth ConfigMap (legacy clusters)

Add the ARN under mapRoles/mapUsers (run as an already-mapped identity), e.g. with eksctl:

eksctl create iamidentitymapping --cluster prod --region us-east-1 \
  --arn arn:aws:iam::111122223333:role/ci-deployer \
  --group system:masters --username ci-deployer

Refresh kubeconfig with the correct role

aws eks update-kubeconfig --name prod --region us-east-1 \
  --role-arn arn:aws:iam::111122223333:role/ci-deployer

What to watch out for

• Unauthorized here is an authorization (RBAC mapping) failure, not bad credentials — aws sts get-caller-identity will still succeed.
• The ARN must match exactly: an assumed-role session ARN maps via the underlying role ARN, and IAM paths/casing matter.
• On API_AND_CONFIG_MAP mode, prefer access entries; on API mode, aws-auth edits do nothing.
• Never leave system:masters on CI roles longer than needed — scope access policies to namespaces where possible.

Related

• AWS Error: EKS nodes stuck in ‘NotReady’ — the nodes join but never become schedulable.
• AWS Error: ‘is not authorized to perform: sts:AssumeRole’ — the role your kubeconfig assumes can’t be assumed.
• AWS Error: ‘ExpiredToken’ — expired STS credentials behind aws eks get-token.