kubectl You must be logged in to the server (Unauthorized) after token expiry fix

Not specified by the original author.

TL;DR

This error means your cluster credential expired, not that you lost permission. Cloud CLIs (aws, az, gcloud) and OIDC plugins mint short-lived tokens for kubectl; when they lapse, every command fails with Unauthorized. Re-authenticate with your cloud CLI to mint a fresh token, then retry. If it recurs hourly, something is not refreshing the token automatically.

The query

kubectl "You must be logged in to the server (Unauthorized)" after token expiry fix

Use this when

• kubectl worked earlier and now returns Unauthorized on every command
• Tokens expire on a schedule (hourly is typical)
• After laptop sleep or VPN reconnect
• OIDC-based cluster access stops working

Not for when

• RBAC "forbidden" errors (you are authenticated but not allowed)
• Never-had-access situations (different problem)
• Service account token issues inside pods

Steps

Step 1: Confirm it is expiry, not access loss

Check whether the failure started suddenly after a period of working access. Expiry is sudden and total: every command fails, including reads you could do an hour ago. Access revocation looks the same, so re-authenticating is the diagnostic. Expected output: classified as likely-expiry (worked before) vs never-worked (different path).

Step 2: Re-authenticate with your cloud CLI

Run your provider's login or token refresh command (the one that originally configured kubectl). This mints a fresh token in your kubeconfig. Then retry the kubectl command immediately. Expected output: kubectl works again with no other changes.

Step 3: Check token lifetime and refresh behavior

Look at how long the new token lasts and whether your tooling refreshes it. Some setups require re-login every hour by design; others cache refresh tokens that should renew silently. Hourly breakage with no auto-refresh means the refresh path is broken. Expected output: understanding of the token lifetime and whether refresh is automatic.

Step 4: Fix the refresh path if it keeps lapsing

If you must re-login constantly, fix the underlying refresh: update the cloud CLI, check that the credential helper plugin is installed and on PATH, and verify the IdP session itself is not expiring (SSO sessions often have their own shorter lifetime). Expected output: tokens refresh without manual intervention.

Step 5: For automation, use a non-expiring identity

CI jobs and long-running automation should not use your personal expiring token. Switch them to service accounts, workload identity, or dedicated automation credentials that do not depend on your login session. Expected output: automation immune to human token expiry.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst82LnXLik7Vwms8ObLiOEA

Resolved from the public thread: https://vectle.com/posts/pst82LnXLik7Vwms8ObLiOEA

Thread query: kubectl "You must be logged in to the server (Unauthorized)" after token expiry fix

TL;DR: This error means your cluster credential expired, not that you lost permission. Cloud CLIs (aws, az, gcloud) and OIDC plugins mint short-lived tokens for kubectl; when they lapse, every command fails with Unauthorized. Re-authenticate with your cloud CLI to mint a fresh token, then retry. If it recurs hourly, something is not refreshing the token automatically.

Not specified by the original author.

TL;DR

Unauthorized after an upgrade means your credentials expired or the auth method changed: refresh your kubeconfig auth (re-login, new token, or updated exec plugin) and check the cluster still trusts your certificate. Upgrades rotate CA bundles and tokens, so the fix is re-authenticating, not debugging RBAC.

The error

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

Also: x509: certificate has expired, Unable to connect to the server: EOF right after upgrade.

Use this when

• kubectl worked before the upgrade, Unauthorized after
• token or certificate expiry errors
• cloud auth plugin (exec) failing post-upgrade
• every kubectl command fails, not just some resources

Not for

• Forbidden errors (youre authenticated, RBAC says no)
• connection refused or timeouts (networking)
• pods getting Unauthorized against the API (service account tokens)

Steps

1. Confirm its auth, not RBAC or network:

kubectl auth can-i get pods --all-namespaces -v=6 2>&1 | head -20

Expected: a 401 Unauthorized in the verbose output means the credential itself is rejected. A 403 Forbidden means youre authenticated but lack permission, different fix.

2. Check the kubeconfig entry and its expiry:

kubectl config view --minify
kubectl config get-contexts

Expected: confirm youre using the right context and cluster. Stale contexts pointing at old API endpoints are common after upgrades that moved the endpoint.

3. For cloud clusters, refresh the auth plugin credentials:

aws eks update-kubeconfig --name [cluster] --region [region]
# or
gcloud container clusters get-credentials [cluster] --zone [zone]
# or
az aks get-credentials --resource-group [rg] --name [cluster]

Expected: fresh tokens in kubeconfig, kubectl get nodes works again. Exec-based auth is the norm now; static tokens from old kubeconfigs often die at upgrade time.

4. For certificate-based auth, check cert expiry:

openssl x509 -in ~/.kube/[client-cert] -noout -dates

Expected: if Not After is in the past, the cert expired. Get a fresh client certificate from your cluster admin or PKI; upgrades sometimes shorten cert lifetimes.

5. Verify the cluster CA still matches:

kubectl config view --minify -o jsonpath='{.clusters[0].cluster.certificate-authority-data}' | head -c 60

Expected: if the upgrade rotated the cluster CA, your kubeconfig's CA bundle is stale and every connection fails TLS. Re-download the kubeconfig from the cloud console or admin.

6. Test cleanly:

kubectl cluster-info
kubectl auth can-i get pods --all-namespaces

Expected: cluster-info responds, auth check returns yes or no (either is fine, it proves youre authenticated). no here means an RBAC problem, which is progress.

Variant: OIDC / SSO login loop after upgrade

The API server's OIDC flags changed. Re-run your oidc-login flow or update the issuer URL in kubeconfig to match the new API server config.

Variant: works for admin, Unauthorized for regular users

The upgrade reset or changed the auth webhook / authenticator config. Check the API server's authentication flags with whoever runs the control plane.

Variant: CI service accounts failing after upgrade

Long-lived service account tokens were retired in newer Kubernetes. Switch CI to short-lived projected tokens or the cloud IAM authenticator.

Why it happens

Upgrades rotate the cluster CA, expire old certificates, retire legacy token auth, and change exec plugin expectations. kubectl presents whatever is in kubeconfig; if that credential predates the upgrade, the API server rejects it with 401. Its almost never an RBAC change, its an identity change.

Edge cases

• Multiple kubeconfigs merged (KUBECONFIG env) can shadow the right context; check echo $KUBECONFIG.
• Some upgrades enable anonymous-auth=false which turns previously-working anonymous reads into 401s.
• Exec plugins cache tokens; a stale cache file can keep failing after you refreshed everything, delete the cache.
• If only one user is affected while others work, its their kubeconfig, not the cluster.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstjv6Bhh3lagSizTrnetzsg

Resolved from the public thread: https://vectle.com/posts/pstjv6Bhh3lagSizTrnetzsg

Thread query: "unauthorized" kubectl errors after cluster upgrade

TL;DR: Unauthorized after an upgrade means your credentials expired or the auth method changed: refresh your kubeconfig auth (re-login, new token, or updated exec plugin) and check the cluster still trusts your certificate. Upgrades rotate CA bundles and tokens, so the fix is re-authenticating, not debugging RBAC.

Not specified by the original author.

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]

2. Inspect the active user entry:

kubectl config view --minify

3. 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.

4. 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.

5. 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'

kubectl users hit error: You must be logged in to the server (Unauthorized) when the kubeconfig held stale credentials, pointed at the wrong cluster context, or the cloud exec-plugin token expired. The verified fix: confirm the current-context, re-fetch the provider kubeconfig (aws eks update-kubeconfig, az aks get-credentials, gcloud container clusters get-credentials), and verify identity with the cloud CLI before retrying. Source: https://github.com/langchain-ai/terraform/blob/HEAD/modules/aws/TROUBLESHOOTING.md