Change:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: [kubeconfig] Using existing kubeconfig file: "" panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0x116df4b] What you expected to happen: should pass OK, or return an message describing what's wrong. How to reproduce it (as minimally and precisely as possible): run Anything else we need to know?: My cluster failed due to expired certs, I followed to recover it, but /etc/kubernetes/bootstrap- got MIA - so I copied it from another node. also got missing, so I copied that from after that I tried which panics. Environment: Kubernetes version (use ): kubectl version Client Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.3", GitCommit:"", GitTreeState:"clean", BuildDate:"2019-06-06T01:44:30Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"linux/amd64"} error: You must be logged in to the server (the server has asked for the client to provide credentials) Cloud provider or hardware configuration: bare-metal OS (e.g: ): cat /etc/os-release NAME="Ubuntu" VERSION="18.04.2 LTS (Bionic Beaver)" ID=ubuntu IDLIKE=debian PRETTYNAME="Ubuntu 18.04.2 LTS" VERSIONID="18.04" HOMEURL="" SUPPORTURL="" BUGREPORTURL="" PRIVACYPOLICYURL="" VERSIONCODENAME=bionic UBUNTUCODENAME=bionic Kernel (e.g. ): uname -a Linux 4.15.0-51-generic -Ubuntu SMP Wed May 15 14:27:21 UTC 2019 x8664 x8664 x8664 GNU/Linux Install tools: kubeadm Network plugin and version (if this is a network-related bug): calico Others:
It seem dereferencing clientcmdapi.Config caused the panic in validateKubeConfig
Under branch origin/release-1.4, I don't seem to find
/remove-sig node /sig cluster-lifecycle Just updating your sigs, which I think will help get the proper eyes on this the fastest :)
Relates to
i don't think it's related to: it was about a feature/documentation that is already in 1.15. ideally we should not panic in these lines: or panicing on line 242 suggests that your kubeconfig is lacking the proper information for the current cluster context. but this means that you have a corrupted kubeconfig file, that kubeadm expects to be machine generated. try adding to see which file is the problem one and share it.
/assign
/remove-kind bug /triage support
/kind feature for not panicing on machine generated kubeconfig.
Sorry - can't provoke this any longer as I had to get my cluster on it's feet. What I did was to delete the config files and let kubeadm regenerate them, which made the panic go away.

Discussion:
expectedCtx := config.CurrentContext expectedCluster := config.Contexts[expectedCtx].Cluster currentCtx := currentConfig.CurrentContext <ins> if currentConfig.Contexts[currentCtx] == nil { return errors.Errorf("failed to find CurrentContext in Contexts of the kubeconfig file %s", kubeConfigFilePath) } </ins> currentCluster := currentConfig.Contexts[currentCtx].Cluster <ins> if currentConfig.Clusters[currentCluster] == nil { return errors.Errorf("failed to find the given CurrentContext Cluster in Clusters of the kubeconfig file %s", kubeConfigFilePath) } </ins> // If the current CA cert on disk doesn't match the expected CA cert, error out because we have a file, but it's stale if !bytes.Equal(currentConfig.Clusters[currentCluster].CertificateAuthorityData, config.Clusters[expectedCluster].CertificateAuthorityData) {