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

Fix EKS "You must be logged in to the server (Unauthorized)": run aws sts get-caller-identity, then add an access entry or aws-auth mapping. Covers lockouts.

hard fix·5 min read

By Vishvesh Patel·DevOps Engineer·Updated 21 September 2026

Run these in order. Each one tells you what its output means before you change anything.

• Confirm which IAM identity kubectl is presenting

EKS maps the IAM identity to a Kubernetes user. If get-caller-identity shows a different role than the one you mapped, nothing else matters until that matches.

• Check which authentication mode the cluster uses

API or API_AND_CONFIG_MAP means access entries are in play and are the supported way to grant access. CONFIG_MAP means the cluster still uses only the aws-auth ConfigMap.

• Grant yourself access with an access entry

The entry maps the IAM principal into the cluster. It grants nothing on its own until you associate an access policy or the principal is bound by RBAC, which is the second step.

EKS authenticates with IAM and authorises with Kubernetes RBAC. Unauthorized means the first step failed: your IAM identity is not mapped to any Kubernetes identity, so the API server does not know who you are.

That is different from Forbidden, which means it does know you and RBAC refused the action.

EKS matches on the role ARN, arn:aws:iam::123456789012:role/dev, not the assumed-role session ARN. Mapping the session form does not work.

Regenerate the kubeconfig if the context looks wrong:

Add --role-arn if you need to assume a role first:

Access entries are the newer mechanism and the supported one. They are an AWS API rather than a ConfigMap, which means they are auditable in CloudTrail and cannot be broken by a bad YAML edit.

The entry maps the principal. It grants nothing yet. Associate a policy:

The built-in policies:

Scope to namespaces where appropriate:

You can also map to Kubernetes groups and use your own RBAC instead:

Then bind dev-team with an ordinary RoleBinding.

On older clusters:

Editing it is genuinely risky. A malformed entry or a deleted node role mapping locks everyone out and stops nodes joining. Always back it up first:

Migrating to access entries is worth doing precisely because it removes this hazard:

That change is one-way: you cannot go back to CONFIG_MAP.

The identity that created the cluster gets implicit cluster-admin, if bootstrapClusterCreatorAdminPermissions was true. Assume that identity:

If that identity is gone and the cluster is in CONFIG_MAP mode, switch it to allow access entries, which does not require cluster access:

This is the main practical reason to enable access entries on every cluster: recovery no longer depends on already having access.

Authentication succeeded. This is ordinary Kubernetes RBAC, and the fix is a Role and RoleBinding or a broader access policy.

What is the difference between Unauthorized and Forbidden on EKS?

Unauthorized is an authentication failure: EKS could not map your IAM identity to any Kubernetes user, so it does not know who you are. Forbidden is an authorization failure: it knows exactly who you are and Kubernetes RBAC refused the action, and the message names the identity, verb and resource. The first is fixed with an access entry or an aws-auth mapping, and the second with a Role and RoleBinding.

Should I use access entries or the aws-auth ConfigMap?

Access entries, for anything new. They are a proper AWS API, so changes are audited in CloudTrail, controlled by IAM permissions, and cannot be broken by a malformed YAML edit. The aws-auth ConfigMap has the significant hazard that a bad entry can lock every user out and stop nodes joining simultaneously. Switch with update-cluster-config --access-config authenticationMode=API_AND_CONFIG_MAP, noting that the change cannot be reversed.

How do I recover from being locked out of an EKS cluster?

If the cluster was created with bootstrapClusterCreatorAdminPermissions, the creating identity has implicit cluster-admin; CloudTrail's CreateCluster event tells you who that was. If that identity no longer exists, switch the cluster to API_AND_CONFIG_MAP and create an access entry for a role you control. Both of those are AWS API calls that need only IAM permissions, not cluster access, which is precisely why enabling access entries everywhere is worth doing in advance.

Why does my role mapping not match?

Almost always because the assumed-role session ARN was used rather than the role ARN. aws sts get-caller-identity returns arn:aws:sts::123456789012:assumed-role/dev/session-name, and EKS matches on arn:aws:iam::123456789012:role/dev. Paths matter too: a role created under a path is arn:aws:iam::123456789012:role/team/dev, and omitting the path means no match. Copy the ARN from aws iam get-role rather than from the STS output.

Does an access entry grant permissions by itself?

No. Creating an access entry maps an IAM principal into the cluster so it can authenticate, and that is all. You then either associate a built-in access policy such as AmazonEKSViewPolicy, optionally scoped to specific namespaces, or map the principal into Kubernetes groups with --kubernetes-groups and bind those groups with your own RBAC. Skipping the second step produces the Forbidden error instead, which at least confirms the mapping worked.

Free, comprehensive DevOps tutorials and learning roadmaps. Master Docker, Kubernetes, CI/CD, and more.

Get notified about new tutorials and features.

• Roadmaps

• Interview Prep

• Certifications

• Company

© 2026 DevOpsLesson. All rights reserved.