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.

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