🚨 GCP Error: 'You must be logged in to the server (Unauthorized)' — Cause, Fix, and Troubleshooting Guide

Overview

kubectl prints this when the GKE API server rejects your request because it could not authenticate the caller — the token was missing, expired, or minted for the wrong identity:

$ kubectl get pods
error: You must be logged in to the server (Unauthorized)

On GKE the token comes from gcloud via the auth plugin. This is a 401 at the Kubernetes layer: the API server doesn’t know who you are. It is distinct from Forbidden (RBAC — it knows you but denies you).

Symptoms

• kubectl commands fail with error: You must be logged in to the server (Unauthorized).
• It appears after a token would have expired (often ~1 hour of idle), or right after switching gcloud accounts.
• Works for one teammate but not another against the same cluster.
• CI jobs authenticate as a service account that was never granted cluster RBAC.

Common Root Causes

1. Expired / stale gcloud access token in the kubeconfig

The cached credential expired and the auth plugin failed to refresh (often paired with a reauth or wrong-account issue).

2. Active gcloud account differs from the one that has access

kubectl uses whatever identity gcloud currently returns; if you switched accounts, the token is for the wrong user.

3. Kubeconfig points at the wrong cluster or is stale

An old context, a deleted+recreated cluster, or a rotated cluster CA.

4. The identity has no RBAC / IAM binding on the cluster

A service account with no roles/container.developer (or no RBAC RoleBinding) is unknown to the cluster.

How to Diagnose

All read-only.

# Who does gcloud think you are right now?
gcloud config get-value account
gcloud auth list

# Which cluster/context is kubectl using?
kubectl config current-context
kubectl config view --minify --output 'jsonpath={..cluster.server}'

# Can gcloud mint a token at all? (catches reauth/expired issues)
gcloud auth print-access-token >/dev/null && echo "token OK" || echo "token FAILED"

# Does the identity have GKE IAM access?
gcloud projects get-iam-policy acme-prod-platform \
  --flatten="bindings[].members" \
  --filter="bindings.members:$(gcloud config get-value account)" \
  --format="table(bindings.role)"

If token FAILED, fix authentication first (reauth/login). If the token is fine but IAM shows no container role, it’s an access grant problem surfacing as Unauthorized.

Fixes

Refresh the cluster credentials (regenerates the kubeconfig entry with a working token source):

gcloud container clusters get-credentials prod \
  --region=us-central1 --project=acme-prod-platform

Make sure the right account is active:

gcloud config set account james@example.com
gcloud auth login   # if the token could not be refreshed

Grant the identity access (IAM gives baseline access; add RBAC for fine-grained control):

gcloud projects add-iam-policy-binding acme-prod-platform \
  --member="serviceAccount:ci-deployer@acme-prod-platform.iam.gserviceaccount.com" \
  --role="roles/container.developer"

Re-point a stale context with kubectl config use-context or re-run get-credentials after a cluster rebuild.

What to Watch Out For

• Unauthorized = no valid identity (401); Forbidden = known but denied (RBAC 403). They need different fixes — don’t edit RBAC for a 401.
• GKE tokens are short-lived; long idle sessions expire — a quick get-credentials usually clears it.
• If gcloud auth print-access-token itself fails, this is really a gcloud auth/reauth problem, not a Kubernetes one.
• After deleting and recreating a cluster with the same name, always re-run get-credentials — the old CA in your kubeconfig will 401.

Related

• GCP Error: ‘gke-gcloud-auth-plugin not found’
• GCP Error: ‘Reauthentication required’
• GCP Error: ‘Your cluster’s nodes are unhealthy’
• More in the GCP error guides.