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

KubernetesINTERMEDIATEHIGHUpdated Dec 5, 2025· 292 views

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.

Quick fix

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

kubectl config current-context
kubectl config view --minify
  1. Verify your current identity and cluster connection
  2. Re-authenticate with your cloud provider
  3. Check and verify certificate expiration
  4. For AWS EKS: Verify IAM role mapping in aws-auth ConfigMap
kubernetes — error
kubectl config current-context
kubectl config view --minify
error: You must be logged in to the server (Unauthorized)

What this error means

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.

Typical symptoms

  • All kubectl commands fail immediately with "Unauthorized" message, regardless of the command
  • Commands work for other cluster members but fail when you run them
  • Error appears after upgrading kubectl, changing kubeconfig, or switching environments
  • Commands suddenly fail after several days of working (suggests token or certificate expiration)
  • Service account automation (CI/CD, pods) fails with unauthorized errors when attempting cluster API calls
  • Switching to a different kubeconfig file resolves the issue temporarily

Common causes

  1. Expired bearer token in kubeconfig - tokens from cloud providers (AWS, Azure, GCP) or OIDC have expiration times
  2. Expired client certificates - self-managed clusters with kubeadm/K3s certificates that haven't been renewed
  3. Incorrect or missing AWS IAM role mapping - on EKS, your IAM user/role isn't configured in the aws-auth ConfigMap
  4. Wrong AWS credentials or expired AWS session token - using outdated AWS environment variables
  5. Service account token not properly mounted or decoded - in-cluster authentication issues
  6. Kubeconfig points to wrong cluster context or server URL
  7. RBAC denies all actions despite valid authentication (results in 403, but can appear as 401 in some contexts)

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

1Verify your current identity and cluster connection

Determine which credentials kubectl is using and which cluster you're connecting to:

bash
kubectl config current-context
kubectl config view --minify

Then verify your cloud provider identity:

bash
# For AWS
aws sts get-caller-identity

# For Azure
az account show

# For GCP
gcloud auth list

Confirm the identity matches what you expect.

2Re-authenticate with your cloud provider

Update your kubeconfig with fresh credentials from your cloud provider:

For AWS EKS:

bash
aws eks update-kubeconfig --name <cluster-name> --region <region>

For Azure AKS:

bash
az aks get-credentials --resource-group <resource-group> --name <cluster-name>

For Google GKE:

bash
gcloud container clusters get-credentials <cluster-name> --zone <zone>

After running the appropriate command, test access:

bash
kubectl get nodes
3Check and verify certificate expiration

If you're using self-managed Kubernetes (kubeadm, K3s), check whether your client certificates have expired:

bash
# Examine certificate expiration
openssl x509 -noout -dates -in /etc/kubernetes/pki/admin.crt

If the notAfter date is in the past, renew certificates:

bash
# For kubeadm clusters
sudo kubeadm certs renew admin.conf
sudo cp /etc/kubernetes/admin.conf ~/.kube/config

# For K3s clusters
sudo k3s certificate rotate
4For AWS EKS: Verify IAM role mapping in aws-auth ConfigMap

On EKS, the cluster's aws-auth ConfigMap must contain an entry mapping your IAM user/role:

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

Get your IAM ARN:

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

If it's not in the ConfigMap, add it (you need initial access as cluster creator):

yaml
mapUsers: |
  - userarn: arn:aws:iam::123456789012:user/your-username
    username: your-username
    groups:
      - system:masters
5Verify service account token (for in-cluster authentication)

If you're running a pod or automation that uses a service account, verify the token is correctly mounted:

bash
# Inside a pod, check if the token exists
cat /var/run/secrets/kubernetes.io/serviceaccount/token

If empty or missing, the service account token wasn't mounted. Check the pod's ServiceAccount:

bash
kubectl get serviceaccount <sa-name> -n <namespace> -o yaml

Ensure your pod spec includes:

yaml
serviceAccountName: <sa-name>
6Review RBAC permissions for your user/service account

Once authenticated, verify your user has permissions:

bash
kubectl auth can-i get pods
kubectl auth can-i create deployments --namespace production

For service accounts, check role bindings:

bash
kubectl get rolebindings -n <namespace>
kubectl get clusterrolebindings

If permissions are missing, create a role and binding:

bash
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>

Advanced notes

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.

Frequently asked questions

What does "error: You must be logged in to the server (Unauthorized)" mean?
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.
How do I fix "error: You must be logged in to the server (Unauthorized)"?
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.
What causes "error: You must be logged in to the server (Unauthorized)"?
Expired bearer token in kubeconfig - tokens from cloud providers (AWS, Azure, GCP) or OIDC have expiration times Expired client certificates - self-managed clusters with kubeadm/K3s certificates that haven't been renewed Incorrect or missing AWS IAM role mapping - on EKS, your IAM user/role isn't configured in the aws-auth ConfigMap
Is the "error: You must be logged in to the server (Unauthorized)" error serious?
Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading