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

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

TL;DR: your kubeconfig credentials are stale or point at the wrong place. First check kubectl config current-context — half the time you are aimed at the wrong cluster. Then re-fetch the kubeconfig from your provider: aws eks update-kubeconfig, az aks get-credentials, or gcloud container clusters get-credentials.

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

Steps

1. Check where you are pointed:

kubectl config get-contexts
kubectl config current-context

Expected: the context you actually intend. If not, switch:

kubectl config use-context [name]

1. Inspect the active user entry:

kubectl config view --minify

1. Re-fetch the kubeconfig from your provider. EKS:

aws eks update-kubeconfig --region [region] --name [cluster-name]

AKS: az aks get-credentials --resource-group [resource group] --name [cluster name]. GKE: gcloud container clusters get-credentials [cluster name] --region [region].

Expected: Added new context or Merged confirmation.

1. Confirm the cloud identity matches what the cluster expects:

aws sts get-caller-identity
kubectl cluster-info

Expected: cluster-info returns without the Unauthorized error.

1. EKS only: if the cluster was created by a different IAM principal, add yourself to the aws-auth ConfigMap in kube-system — the API server authorizes through it.

When this applies

• the exact error on all kubectl commands
• after IAM role changes, SSO re-login, or cluster recreation under the same name
• exec-plugin tokens expired (cloud providers mint short-lived ones)

When it doesnt

• The connection to the server was refused — the API is down or the endpoint is wrong, that is reachability not auth
• x509: certificate signed by unknown authority — CA mismatch; re-fetching the config also fixes it, but the cause differs
• forbidden on one specific resource — RBAC; the login is fine, ask the cluster admin for the role

Compatibility

kubectl 1.2x and up, EKS/AKS/GKE managed clusters, kubeadm.

Why it happens

kubectl sends whatever credential the kubeconfig holds: an exec-plugin token, an OIDC token, or a client cert. Cloud exec plugins mint short-lived tokens from your cloud identity; when that identity changes or the cached token expires, the API answers 401 and kubectl prints this generic line.

Edge cases

• in CI use a dedicated service account token instead of a human kubeconfig
• the KUBECONFIG env var can shadow ~/.kube/config — check it when the context looks right but auth still fails
• on EKS, aws sts get-caller-identity is the fastest way to prove which identity you are before blaming kubectl

Find this skill again

curl -s 'https://vectle.com/api/v1/search?q=kubectl+must+be+logged+in+server+unauthorized'