AKS kubectl unauthorized: expired Entra token or wrong kubeconfig context

TL;DR: You must be logged in to the server (Unauthorized). On Entra-integrated clusters the kubelogin token expired or the context points at a recreated cluster. Error text: error: You must be logged in to the server (Unauthorized). Verify: kubectl auth can-i get pods --namespace default returns yes/no cleanly instead of an auth error.

The error

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

The fix

1. Token expired. Non-admin credentials on Entra-integrated clusters use kubelogin with short-lived tokens. Re-run az aks get-credentials -g [rg] -n [cluster] --overwrite-existing to refresh. If this recurs hourly in automation, switch that automation to a managed identity or service account instead of a user token.
2. Wrong context. kubectl config current-context - is it the cluster you think? After a cluster recreate with the same name, the old context has the old API server address. --overwrite-existing fixes it.
3. kubelogin missing. "error: unknown flag" or exec plugin errors mean kubelogin is not installed or not on PATH. az aks install-cli installs kubectl and kubelogin together.
4. RBAC, not auth. If the error is forbidden: User ... cannot list resource, you ARE authenticated but lack Azure RBAC (or Kubernetes RBAC) rights. Different fix: Azure Kubernetes Service RBAC Reader/Writer role assignment.
5. Private cluster. If the API server is private, kubectl from outside the VNet fails at the network layer (timeout), not with Unauthorized. Unauthorized from a peered VNet box is still auth. Verify: kubectl auth can-i get pods --namespace default returns yes/no cleanly instead of an auth error.

When to use this

• You are seeing this exact error message; match the block above, not just part of it.
• The failing call matches the scenario in the title: AKS kubectl unauthorized.
• You want the fastest verified fix before digging through logs.

When not to use this

• Your error text differs from the block above; close cousins often have different causes.
• The stack trace points at a different component than the one in the title.
• You already applied this fix and the error persists; look for a second cause instead of reapplying.

Compatibility

• Not pinned to a specific version; follows current AKS behavior.

Also seen as

• forbidden: User ... cannot list resource

Proactive error-catalog skill. kubelogin and credential behavior verified against current AKS docs. Evidence: https://learn.microsoft.com/en-us/azure/aks/control-kubeconfig-access