kubectl 'error: You must be logged in to the server (Unauthorized)' on EKS or GKE after credentials expired or a kubeconfig/auth plugin change. How do I fix it?

Cause: the API server rejected the credential kubectl presented (HTTP 401). On EKS and GKE kubeconfigs do not hold a long-lived password; they call an exec plugin (aws eks get-token, or gke-gcloud-auth-plugin) that turns your cloud identity into a short-lived token. The error appears when your cloud login has expired, you are using a different cloud identity or profile than the one that created/was granted access to the cluster, the plugin is missing or outdated, or the kubeconfig points at a deleted or recreated cluster. Fix (best first): 1. Check which identity you are using. EKS: aws sts get-caller-identity. GKE: gcloud auth list. If the session expired, log in again (for example aws sso login --profile PROFILE, or gcloud auth login). 2. Make sure the profile in use is the one that has cluster access. For EKS, set AWS_PROFILE or pass --profile, and remember the IAM principal must be mapped to the cluster (cluster access entries or the aws-auth mapping, depending on the cluster's authentication mode); the identity that created the cluster has access by default, others need to be granted it by an admin. 3. Regenerate the kubeconfig entry. EKS: aws eks update-kubeconfig --region REGION --name CLUSTER_NAME (optionally --role-arn ROLE_ARN). GKE: gcloud container clusters get-credentials CLUSTER_NAME --location=LOCATION. 4. GKE: install the plugin if it is missing: gcloud components install gke-gcloud-auth-plugin (or the google-cloud-cli-gke-gcloud-auth-plugin package), and check gke-gcloud-auth-plugin --version. EKS: use a reasonably current AWS CLI v2. 5. Confirm the active context: kubectl config current-context. A stale context from an old cluster gives the same error. 6. For clusters using static client certificates or tokens, check they have not expired and get a fresh one from the cluster admin. Do not work around this by enabling anonymous or unauthenticated access. Verify: kubectl get namespaces (or kubectl get svc) returns results, and kubectl auth whoami (where available) or kubectl auth can-i get pods shows the identity you expect. Sources: https://docs.aws.amazon.com/eks/latest/userguide/create-kubeconfig.html https://docs.cloud.google.com/kubernetes-engine/docs/how-to/cluster-access-for-kubectl https://kubernetes.io/docs/reference/access-authn-authz/authentication/