EKS kubectl Error "You Must Be Logged In to the Server": The Fix

The EKS kubectl error "You must be logged in to the server (Unauthorized)" almost never means you are logged out. Your AWS credentials worked. The token was minted, the cluster received it, and then the cluster looked up who you are and found nobody by that name. In plain words: AWS knows you, but the Kubernetes side of the cluster was never told about you. The fix is to add your IAM identity to the cluster's access list, which in 2026 means an EKS access entry on most clusters and an entry in the aws-auth ConfigMap on older ones. Here is the part that trips up careful people: the identity that created the cluster is the only one that gets in automatically, and since the Terraform EKS module version 20 even that stopped being true by default.

Ethan built his first production cluster last Thursday with Terraform, from his own laptop, with the company's SSO role. Terraform said the cluster was ready. He ran the kubeconfig command, then kubectl get nodes, and got this error on the cluster he had created ninety seconds earlier. Jake, who is learning Kubernetes on Ethan's cluster from his own IAM user, got the same error in a different way: his credentials were fine too, but nobody had added him. Two people, one message, two different fixes. This page is the order you check things in so you reach the right one in minutes instead of an afternoon.

One promise before the detail: you do not need working kubectl to fix broken kubectl. Every repair on this page runs through the AWS CLI or the EKS console, which is exactly why access entries were introduced. If you are locked out of a cluster that nobody can reach, skip to the locked-out section first.

What "You must be logged in to the server (Unauthorized)" actually means on EKS

Kubernetes has two gates. The first is authentication: who are you? The second is authorization: what may you do? On EKS the first gate is handled by AWS. When you run a kubectl command, kubectl calls aws eks get-token, which signs a request with your current AWS credentials and hands the result to the cluster as a bearer token. The cluster forwards that token to AWS STS, which replies with the ARN of the identity that signed it. That part worked, or you would be reading a different error.

Then the cluster takes that ARN and looks for it in its own list of known identities. On a modern cluster that list is the set of access entries. On an older one it is the aws-auth ConfigMap in the kube-system namespace. If the ARN is not in the list, the authenticator cannot turn it into a Kubernetes username, and a request with no username is rejected at the door. Kubernetes words that rejection as "You must be logged in to the server (Unauthorized)", which is the generic phrase for "the request carried no identity I accept". The AWS login was fine. The Kubernetes login never happened.

That is why three other messages belong to the same family and get the same fix:

• could not get token: AccessDenied: Access denied, when your AWS identity cannot even call the EKS API for the cluster;
• error: the server doesn't have a resource type "svc", which is what older kubectl versions print when discovery fails because you are unauthenticated;
• error: You must be logged in to the server (the server has asked for the client to provide credentials), the longer form of the same rejection.

And it is why the usual instinct, running aws configure again or re-running the SSO login, does nothing. Your credentials are not the problem. The mapping is.

Before the step-by-step, here is the whole page as a lookup table. Find the situation that matches, and the section to jump to.

What you see	Most likely cause	Fix
Unauthorized on a cluster you created with Terraform or CDK	Creator admin access is off by default (module v20+), or the creator is the CI or Lambda role	Terraform section
Unauthorized for a teammate, works for you	Their ARN was never added	Create an access entry
Unauthorized after switching laptops, profiles or accounts	kubectl is using a different identity than you think	Steps 1 and 2
Unauthorized after lunch, worked this morning	Expired SSO session or rotated keys	Step 4
Nobody can get in; the creator's user is gone	ConfigMap-only cluster with no surviving mapped identity	Locked-out recovery
"no kind ExecCredential is registered for version v1alpha1"	Stale kubeconfig from an old CLI	Regenerate it
Nodes NotReady, kubelet says Unauthorized	Node role missing from aws-auth or access entries	Node section
Forbidden instead of Unauthorized	You are in; the entry has no policy or group	Attach a policy

The one identity that gets in for free, and when it does not

When a cluster is created, EKS can give the creating identity administrator access automatically. On clusters using access entries this is the bootstrapClusterCreatorAdminPermissions flag, and it defaults to true when you create a cluster with the CLI or the console. On older ConfigMap-only clusters the same thing happened invisibly: the creator was granted system:masters without appearing in aws-auth at all, which confused a generation of admins who opened the ConfigMap, saw it empty, and wondered how they were getting in.

So the first question is always: is the identity running kubectl the same one that created the cluster? "Same" is strict. An IAM user and a role that user assumes are different identities. Your SSO permission set in the console and the same permission set through the CLI are the same role, but a different AWS profile that points at another account or another role is not. A cluster created from CloudShell with your console identity and queried from a laptop with an access key for a different IAM user will fail exactly like this.

Here is the part that catches careful people. Some tools turn the automatic creator access off:

• The community Terraform EKS module, from version 20 onward, hard-sets bootstrap_cluster_creator_admin_permissions to false and gives you a separate variable, enable_cluster_creator_admin_permissions, which defaults to false. Create a cluster with that module and defaults, and the identity that created it has no access at all. Ethan's Thursday, exactly.
• Any pipeline that creates the cluster with a CI role means the creator is that role, not you. Your laptop identity was never the creator.
• Clusters created with bootstrapClusterCreatorAdminPermissions=false on purpose, which security-minded teams do so that no human has standing admin.

None of these are bugs. They are the cluster doing what it was told. The fix is the same in every case: add an access entry for the identity you actually use.

Access entries vs aws-auth: which list your cluster uses

Every EKS cluster has an authentication mode, and it decides which list the authenticator consults. You can read it with one command:

aws eks describe-cluster --name my-cluster --region us-east-1 \
  --query "cluster.accessConfig.authenticationMode" --output text

Mode	Which list is consulted	Who gets it by default	What to fix
API	Access entries only. The aws-auth ConfigMap is ignored.	Clusters you opt in; the recommended end state	Create an access entry
API_AND_CONFIG_MAP	Both. Access entries win when an identity appears in both.	New clusters made in the console	Create an access entry (preferred) or edit aws-auth
CONFIG_MAP	aws-auth ConfigMap only. Access entries do not exist.	New clusters made with the API, SDKs or CloudFormation, and everything created before 2024	Edit aws-auth, or switch the mode first (one way only)

Two facts matter in practice. First, the default depends on how the cluster was born: the console gives you both lists, the API gives you only the ConfigMap. Second, the mode can only move forward. You can go from CONFIG_MAP to API_AND_CONFIG_MAP, and from there to API, never back. Access entries need a platform version of at least eks.6 on Kubernetes 1.28, eks.1 on 1.29, eks.2 on 1.30, and every platform version on anything newer. The ConfigMap route is marked for deprecation, so when you have the choice, switch:

aws eks update-cluster-config --name my-cluster --region us-east-1 \
  --access-config authenticationMode=API_AND_CONFIG_MAP

The cluster goes to Updating for a few minutes and comes back Active with the access-entry API enabled. Existing ConfigMap entries keep working in the combined mode, and the original creator gets an access entry generated automatically. Anything else you had mapped in aws-auth stays in the ConfigMap only; it is not copied across. Keep that in mind before you ever move to pure API mode.

Diagnose it in five minutes, in this order

Do these in the same terminal you run kubectl from. Half of all cases are solved by step 1 alone.

Step 1: confirm who kubectl thinks you are

aws sts get-caller-identity

Read the Arn line slowly. Is it the account you expect? Is it a user or an assumed role? Does the role name match the one you used to create the cluster, or the one your teammate said they added? If you use named profiles, run it with --profile the same way kubectl will, because kubectl uses whatever credentials the aws command finds, which may be an environment variable you forgot about. AWS_PROFILE, AWS_ACCESS_KEY_ID in the shell, and a default profile in ~/.aws/credentials all compete, and the environment variables win.

Step 2: confirm which cluster and which identity the kubeconfig uses

kubectl config current-context
kubectl config view --minify

Look at the exec block under users. It should read command: aws, with args that include eks get-token --cluster-name my-cluster --region us-east-1, and apiVersion: client.authentication.k8s.io/v1beta1. Three things to catch here:

• A --role-arn argument. If present, kubectl assumes that role before minting the token, so the identity hitting the cluster is that role, not what step 1 printed. Either the role is the one mapped, or it is the reason you are unmapped.
• An env entry setting AWS_PROFILE. Same effect: it overrides the shell.
• apiVersion: client.authentication.k8s.io/v1alpha1. That is the stale-kubeconfig problem covered below, and it produces a different message, but people land here from both.

If anything looks off, regenerate the file rather than hand-editing it:

aws eks update-kubeconfig --region us-east-1 --name my-cluster
# or, to pin a role or profile explicitly:
aws eks update-kubeconfig --region us-east-1 --name my-cluster --role-arn arn:aws:iam::111122223333:role/eks-admin
aws eks update-kubeconfig --region us-east-1 --name my-cluster --profile prod

That command needs eks:DescribeCluster on your identity and AWS CLI version 2.12.3 or later (1.27.160 on the v1 line). If the command itself fails with AccessDenied, you have an IAM problem in front of the EKS problem; the AWS CLI AccessDenied decoder handles that one.

Step 3: check whether your ARN is on the cluster's list

For clusters in API or API_AND_CONFIG_MAP mode:

aws eks list-access-entries --cluster-name my-cluster --region us-east-1

Your ARN from step 1 should appear, with one difference: for an assumed role, the list shows the IAM role ARN (arn:aws:iam::111122223333:role/eks-admin), not the STS assumed-role ARN that get-caller-identity prints (arn:aws:sts::111122223333:assumed-role/eks-admin/your-session). Translate in your head: strip sts to iam, assumed-role to role, and drop the session name. If the role ARN is there, run the next command to see whether it actually has permissions attached, because an access entry with no policy and no groups authenticates you and then lets you do nothing:

aws eks list-associated-access-policies --cluster-name my-cluster --region us-east-1 \
  --principal-arn arn:aws:iam::111122223333:role/eks-admin

For clusters in CONFIG_MAP mode you cannot read the ConfigMap without kubectl access, which is the trap. If a colleague still has access, ask them to run:

eksctl get iamidentitymapping --cluster my-cluster --region us-east-1
# or
kubectl get configmap aws-auth -n kube-system -o yaml

If nobody has access, the cluster creator identity has vanished, and the mode is CONFIG_MAP, go to the locked-out section. You are not stuck; you just need the EKS API rather than the Kubernetes API.

Step 4: rule out expired or wrong credentials

If step 1 printed an error rather than an ARN, you were never authenticated, and the fix is on the AWS side. SSO sessions expire after the session length your administrator set, often 8 hours, and the message kubectl shows for an expired SSO token is still "Unauthorized" in some CLI versions. Run aws sso login --profile yourprofile and retry. Access keys that were rotated or deleted give the same symptom. The ExpiredToken guide covers the temporary-credential cases.

The fix: add your identity to the cluster

Pick the route that matches your cluster's mode from the table above. Both routes use only AWS permissions; neither requires a working kubectl.

Route A: create an access entry (API or API_AND_CONFIG_MAP mode)

Two commands. The first registers the identity; the second gives it permissions. Use the IAM role ARN (or user ARN), never the STS assumed-role ARN.

aws eks create-access-entry --cluster-name my-cluster --region us-east-1 \
  --principal-arn arn:aws:iam::111122223333:role/eks-admin --type STANDARD

aws eks associate-access-policy --cluster-name my-cluster --region us-east-1 \
  --principal-arn arn:aws:iam::111122223333:role/eks-admin \
  --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy \
  --access-scope type=cluster

Then retry kubectl. Access entries are eventually consistent, so give it ten seconds if the first attempt still fails. The four managed access policies map to the familiar Kubernetes roles: AmazonEKSClusterAdminPolicy is cluster-admin, AmazonEKSAdminPolicy is admin, AmazonEKSEditPolicy is edit, and AmazonEKSViewPolicy is view. For a developer who should only touch one namespace, scope it:

aws eks associate-access-policy --cluster-name my-cluster --region us-east-1 \
  --principal-arn arn:aws:iam::111122223333:user/jake \
  --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSEditPolicy \
  --access-scope type=namespace,namespaces=dev

That is how Jake got in: an entry for his IAM user, edit rights in dev, nothing else. He did not need Ethan's role, and Ethan did not need to open aws-auth.

Prefer the console? Open the cluster, choose the Access tab, then Create access entry, pick the IAM principal, leave the type as Standard, and on the next page add a policy with Cluster or Namespace scope. If the Access tab says the authentication mode is ConfigMap, you are on Route B, or you switch the mode first with the command in the modes section.

Route B: add the identity to aws-auth (CONFIG_MAP mode)

This needs an identity that already has access, or the creator identity. With eksctl installed:

eksctl create iamidentitymapping --cluster my-cluster --region us-east-1 \
  --arn arn:aws:iam::111122223333:role/eks-admin \
  --username eks-admin --group system:masters

Or edit the ConfigMap directly with kubectl edit configmap aws-auth -n kube-system and add a block under mapRoles (or mapUsers for an IAM user):

mapRoles: |
  - rolearn: arn:aws:iam::111122223333:role/eks-admin
    username: eks-admin
    groups:
      - system:masters

Three rules for the ConfigMap that are not obvious and cause most of the "I added it and it still fails" cases:

1. No paths in the ARN. If your role is arn:aws:iam::111122223333:role/teams/platform/eks-admin, write it as arn:aws:iam::111122223333:role/eks-admin. The ConfigMap matcher cannot handle the path. IAM Identity Center roles always carry one: strip /aws-reserved/sso.amazonaws.com/us-east-1/ from the ARN so it reads role/AWSReservedSSO_AdministratorAccess_abc123. Access entries, by contrast, accept the full ARN with the path, which is one more reason to move.
2. Role ARN, not instance profile ARN. For node roles, the ARN must be the IAM role. An instance profile ARN looks similar and silently fails.
3. Indentation is YAML. A tab or a misaligned dash makes the whole ConfigMap unreadable, and when the authenticator cannot parse aws-auth, everyone except the creator is locked out, including the nodes. If the cluster's nodes go NotReady right after you edited the ConfigMap, that is what happened. Fix the YAML; do not start deleting nodes.

Terraform, CDK and eksctl: the cluster you built but cannot use

Ethan's case deserves its own section because it is now the most common way to hit this error on a brand-new cluster, and the module's changelog is the only place it is explained.

Terraform EKS module version 20 and later

From v20, the community module stopped granting the creator admin access through the ConfigMap, moved to access entries, and defaulted the new switch to off. If you created the cluster with something like this:

module "eks" {
  source  = "terraform-aws-modules/eks/aws"
  version = "~> 20.0"
  cluster_name = "my-cluster"
  # ...
}

then nobody is mapped. Add one line and apply:

  enable_cluster_creator_admin_permissions = true

That gives the identity Terraform ran as (check it with aws sts get-caller-identity in the shell that runs Terraform; if a CI role applied the plan, it is that role, not you) a cluster-admin access entry. For anyone else, or for a cleaner setup where humans get explicit entries, use the access_entries map:

  access_entries = {
    ethan = {
      principal_arn = "arn:aws:iam::111122223333:role/AWSReservedSSO_AdministratorAccess_abc123"
      policy_associations = {
        admin = {
          policy_arn   = "arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy"
          access_scope = { type = "cluster" }
        }
      }
    }
  }

Two more module behaviors worth knowing. The module sets authentication_mode to API_AND_CONFIG_MAP by default from v20, and it refuses to create a new cluster in pure CONFIG_MAP mode. And if you upgrade an older cluster's module from v19 to v20, the plan may want to recreate the cluster because the bootstrap flag is now pinned false; read the module's v20 upgrade guide before you apply that plan, not after.

AWS CDK

CDK's eks.Cluster construct creates the cluster through a Lambda-backed custom resource, so the creator is that Lambda's role, never you. The construct gives you a mastersRole property for exactly this reason; pass the role you will use, or call cluster.grantAccess() (newer CDK versions, access-entry based) or cluster.awsAuth.addMastersRole() (ConfigMap based) for your identity. If you did neither, add it and deploy again. The CDK bootstrap errors guide covers the deploy-side failures that often come first.

eksctl

eksctl create cluster maps the identity that ran it, so you only hit the error if you query the cluster as someone else. Add people with eksctl create iamidentitymapping as shown above, or, on access-entry clusters, with eksctl create accessentry.

Locked out: nobody can run kubectl and the creator is gone

This is the scenario people fear, and the one access entries were designed to end. The old story went like this: the engineer who created the cluster left, their IAM user was deleted, the ConfigMap only mapped their user, and now there is no identity on earth that can edit the ConfigMap because editing it requires Kubernetes access. Support tickets about this used to end with "rebuild the cluster".

Today the order is:

1. Check the mode. aws eks describe-cluster as above. If it is API or API_AND_CONFIG_MAP, you need nothing but IAM permission to call eks:CreateAccessEntry and eks:AssociateAccessPolicy. Run Route A for your own ARN. Done.
2. If it is CONFIG_MAP, switch it with aws eks update-cluster-config ... --access-config authenticationMode=API_AND_CONFIG_MAP, wait for Active, then run Route A. The switch is an EKS API call, not a Kubernetes one, so the lockout does not block it. The platform version requirement applies; a cluster on a Kubernetes version that is still supported meets it.
3. If the creator identity still exists but you do not have it, for instance a role your account still contains, assuming that role and running Route B is the lightest touch. Check the trust policy; the AssumeRole AccessDenied guide explains why the assume itself may fail.
4. Only if the cluster is on a Kubernetes version too old for access entries is a rebuild on the table, and at that point the version itself is the bigger problem.

One subtlety about deleted-and-recreated identities. An access entry stores the principal's unique ID, not just the ARN. If you delete an IAM role and recreate it with the same name, the old access entry will not match the new role, even though the ARN is identical. Delete the stale entry and create a fresh one. The same trap exists in aws-auth for IAM users that were recreated, which is why a "but the ARN is right there" argument can be true and still wrong.

The stale kubeconfig variant: "no kind ExecCredential is registered for version v1alpha1"

If your error reads error: exec plugin: invalid apiVersion "client.authentication.k8s.io/v1alpha1" or no kind "ExecCredential" is registered for version "client.authentication.k8s.io/v1alpha1", you have a different problem with the same cure. The v1alpha1 exec credential API was removed in kubectl 1.24. Kubeconfig files written by old AWS CLI or eksctl versions used it. Newer kubectl refuses the file before it ever talks to the cluster.

Regenerate the file with a current AWS CLI, which writes v1beta1:

aws --version
aws eks update-kubeconfig --region us-east-1 --name my-cluster

If you cannot update the CLI right now, open ~/.kube/config, find the users entry for the cluster, and change the one line to apiVersion: client.authentication.k8s.io/v1beta1. Nothing else in the block changes. Kubeconfigs that still invoke aws-iam-authenticator token -i my-cluster instead of aws eks get-token work too, as long as the authenticator binary is recent; the AWS CLI route is simpler because you already have the CLI.

While you are there, keep kubectl within one minor version of the cluster. A 1.31 kubectl against a 1.34 control plane produces odd discovery errors that read like authentication failures and are not.

When it is the nodes, not you: Unauthorized in kubelet logs

Sometimes you can run kubectl fine, and the error shows up elsewhere: nodes stuck NotReady, kubelet logs full of Unable to register node ... with API server: Unauthorized, a managed node group reporting AccessDenied health issues. Same mechanism, different identity. The node's IAM role has to be on the list too, and for managed node groups EKS adds it for you when the group is created. It disappears when someone replaces the aws-auth ConfigMap wholesale, which is a common side effect of applying a hand-written ConfigMap from a tutorial over the one EKS maintains.

For self-managed nodes on an access-entry cluster:

aws eks create-access-entry --cluster-name my-cluster --region us-east-1 \
  --principal-arn arn:aws:iam::111122223333:role/myAmazonEKSNodeRole --type EC2_LINUX

For the ConfigMap route:

eksctl create iamidentitymapping --cluster my-cluster --region us-east-1 \
  --arn arn:aws:iam::111122223333:role/myAmazonEKSNodeRole \
  --group system:bootstrappers,system:nodes \
  --username system:node:{{EC2PrivateDNSName}}

Use the node IAM role ARN, not the instance profile ARN, and for Windows nodes the type is EC2_WINDOWS. Managed node groups and Fargate profiles never need a manual entry; if theirs went missing, the fastest repair is to let EKS recreate it by updating the node group, or to restore the exact block from a backup of the ConfigMap.

After you are in: the things that still fail, and why they are a different error

Once the mapping exists, two new messages can appear, and both are good news because they mean authentication now works:

• Error from server (Forbidden): pods is forbidden: User "arn:aws:sts::...:assumed-role/..." cannot list resource "pods". You are authenticated and authorized for nothing. Attach an access policy to the entry, or bind the entry's group to a Role or ClusterRole. Note the username in the message: that is the identity Kubernetes sees, and it is the string your RBAC bindings must reference.
• kubectl cluster-info works but kubectl get nodes is Forbidden. Same thing, scoped: a namespace-scoped policy does not cover cluster-level resources like nodes. Either widen the scope or stop expecting node access from a developer entry.

And one that looks related but is not: ImagePullBackOff on your first deployment is the node failing to pull from ECR, which is the node role's permissions and the image URI, not your kubectl identity. The ECR primer is the right next page for that one.

Stop it happening to the next person

• Create clusters with a role, not a person. A dedicated eks-admin role, assumable by the platform team, means the creator never "leaves the company".
• Put every human in Terraform or the console as an access entry on day one, scoped to what they need. The access_entries map in the module is self-documenting; a hand-edited ConfigMap is not.
• Move to API mode once everything is migrated. It removes the YAML-indentation lockout risk entirely, and CloudTrail records every access change.
• Write the kubeconfig command into the README with the exact --profile or --role-arn people should use. Most "it works for you but not me" cases are two people using two different identities without realizing it.
• Check aws sts get-caller-identity before you check anything else. It takes two seconds and it is the question the cluster is asking.

Ethan's fix was one line in Terraform and a thirty-second apply. Jake's was a single access entry scoped to his namespace, which Ethan now thinks is the better pattern anyway. Neither of them was logged out, and neither of them had done anything wrong; the cluster was simply never told who they were. If you have spent the afternoon re-running SSO logins and reinstalling kubectl, stop, run the identity command, and look for your ARN on the cluster's list. That is the whole investigation, and it is the part the error message does not say.

Revision note. Written October 2, 2026, for the version of EKS that uses access entries. If you built the cluster this week and it will not let you in, the fix is shorter than the search that brought you here.