This kubectl authentication error occurs when your client cannot successfully authenticate with the Kubernetes API server. Causes include expired tokens, invalid kubeconfig credentials, IAM role mismatches, or expired certificates.
The kubectl error 'You must be logged in to the server (Unauthorized)' indicates that your kubectl client failed to authenticate with the Kubernetes API server. The API server received your request but rejected your authentication credentials, preventing you from accessing any cluster resources. This is a 401 Unauthorized response, meaning the API server doesn't recognize or trust your credentials. The credentials in your kubeconfig file—whether a bearer token, client certificate, or cloud provider credentials—are either missing, expired, invalid, or don't match any authenticated user in the cluster. Unlike authorization errors (403 Forbidden), which occur after successful authentication when a user lacks permissions, this error means you haven't successfully proven your identity to the cluster at all.
Determine which credentials kubectl is using and which cluster you're connecting to:
kubectl config current-context
kubectl config view --minifyThen verify your cloud provider identity:
# For AWS
aws sts get-caller-identity
# For Azure
az account show
# For GCP
gcloud auth listConfirm the identity matches what you expect.
Update your kubeconfig with fresh credentials from your cloud provider:
For AWS EKS:
aws eks update-kubeconfig --name <cluster-name> --region <region>For Azure AKS:
az aks get-credentials --resource-group <resource-group> --name <cluster-name>For Google GKE:
gcloud container clusters get-credentials <cluster-name> --zone <zone>After running the appropriate command, test access:
kubectl get nodesIf you're using self-managed Kubernetes (kubeadm, K3s), check whether your client certificates have expired:
# Examine certificate expiration
openssl x509 -noout -dates -in /etc/kubernetes/pki/admin.crtIf the notAfter date is in the past, renew certificates:
# For kubeadm clusters
sudo kubeadm certs renew admin.conf
sudo cp /etc/kubernetes/admin.conf ~/.kube/config
# For K3s clusters
sudo k3s certificate rotateOn EKS, the cluster's aws-auth ConfigMap must contain an entry mapping your IAM user/role:
kubectl get configmap aws-auth -n kube-system -o yamlGet your IAM ARN:
aws sts get-caller-identity --query Arn --output textIf it's not in the ConfigMap, add it (you need initial access as cluster creator):
mapUsers: |
- userarn: arn:aws:iam::123456789012:user/your-username
username: your-username
groups:
- system:mastersIf you're running a pod or automation that uses a service account, verify the token is correctly mounted:
# Inside a pod, check if the token exists
cat /var/run/secrets/kubernetes.io/serviceaccount/tokenIf empty or missing, the service account token wasn't mounted. Check the pod's ServiceAccount:
kubectl get serviceaccount <sa-name> -n <namespace> -o yamlEnsure your pod spec includes:
serviceAccountName: <sa-name>Once authenticated, verify your user has permissions:
kubectl auth can-i get pods
kubectl auth can-i create deployments --namespace productionFor service accounts, check role bindings:
kubectl get rolebindings -n <namespace>
kubectl get clusterrolebindingsIf permissions are missing, create a role and binding:
kubectl create role pod-reader --verb=get,list --resource=pods -n <namespace>
kubectl create rolebinding read-pods --role=pod-reader --serviceaccount=<namespace>:<sa-name> -n <namespace>Authentication vs Authorization: The 'You must be logged in' error is strictly an authentication issue (401), not an authorization issue (403). Authentication verifies 'who you are' using credentials; authorization (RBAC) checks 'what you can do' after proving identity.
Kubernetes supports multiple authentication methods: X.509 client certificates, bearer tokens (static tokens, OIDC, service accounts), and cloud provider tokens (AWS IAM, Azure AD, GCP).
In Kubernetes 1.24+, service account tokens changed from static long-lived tokens to short-lived, auto-rotating tokens via the TokenRequest API. This requires different handling in automation.
For EKS specifically, the aws-auth ConfigMap acts as a bridge between AWS IAM (who can access) and Kubernetes RBAC (what they can do)—you must be in both to access resources.
Token refresh behavior varies by provider: OIDC automatically refreshes id_tokens using refresh_tokens; AWS credentials require re-running update-kubeconfig; Azure may need credential-helper-driven refresh.
Failed to connect to server: connection refused (HTTP/2)
How to fix "HTTP/2 connection refused" error in Kubernetes
missing request for cpu in container
How to fix "missing request for cpu in container" in Kubernetes HPA
error: invalid configuration
How to fix "error: invalid configuration" in Kubernetes
etcdserver: cluster ID mismatch
How to fix "etcdserver: cluster ID mismatch" in Kubernetes
running with swap on is not supported
How to fix "running with swap on is not supported" in kubeadm