Guide to inspecting and managing kubeconfig files, switching contexts, setting a custom default, and diagnosing and fixing client certificate mismatches for kubectl authentication.
Use this file to discover all available pages before exploring further.
In this lesson you’ll learn how to inspect kubeconfig files, switch contexts, make a custom kubeconfig the default, and diagnose a common client-certificate mismatch that prevents kubectl from authenticating.
The value in current-context is the name of the context in use. The context lists which cluster and which user to use — the “user” entry is a reference name, not necessarily the actual system username.
Diagnose and fix an authentication error (client-certificate mismatch)
With the current context set to research, running a kubectl command may produce an error indicating kubectl cannot read the client certificate referenced in the kubeconfig:
root@controlplane ~ ➜ kubectl get nodeserror: unable to read client-cert /etc/kubernetes/pki/users/dev-user/developer-user.crt for dev-userdue to open /etc/kubernetes/pki/users/dev-user/developer-user.crt: no such file or directory
Investigate the actual files on disk:
root@controlplane ~ » ls /etc/kubernetes/pki/usersaws-user dev-user test-userroot@controlplane ~ » ls /etc/kubernetes/pki/users/dev-user/dev-user.crt dev-user.csr dev-user.key
Root cause: the kubeconfig references /etc/kubernetes/pki/users/dev-user/developer-user.crt and /etc/kubernetes/pki/users/dev-user/developer-user.key, but the files present are named dev-user.crt and dev-user.key. Update the kubeconfig to point to the correct certificate and key.
The kubectl config set-credentials command modifies the kubeconfig file kubectl is currently using (typically $HOME/.kube/config). Back up that file before making changes.
Recommended fix — update the dev-user credential entry to reference the correct certificate and key: