Open bliles opened 3 weeks ago
Is this only a windows issue? I see the issue that you've linked that explains the logic but it doesn't seem like that issue is quite the same as what you're experiencing. Because this was done intentionally, if this is a problem in other OS's then we will not change this behavior, but if it is just a problem for Windows we likely have a Windows specific bug we need to investigate.
Alternatively you could store the cert itself directly in the config file if that is acceptable.
/triage needs-information
Thanks for looking at this @mpuckett159
It does just seem to be a problem on Windows, I haven't tested macOS, but I just tested Linux and the absolute path to the certificate was respected and not changed to a relative path when running:
kubectl config set-cluster minikube --certificate-authority=/home/[username]/.minikube/ca.crt
For my part, I don't think it would be a good idea to decide for the user that what they meant to do was put the cert data into the kube config when the user was trying to set the path to the certificate. Like I said originally, what makes the most sense to me is to respect the instruction the user provided.
No I mean it is possible to put the cert there explicitly today if you want instead of just using the file path.
Ok since this is a windows bug I'll accept and we can work on locating the issue and fixing it.
/triage accepted
I think this might be the issue: https://github.com/kubernetes/client-go/blob/53c7e93bf282a011512dee21bf4acb71b49aca1c/tools/clientcmd/loader.go#L632
The check to know if the path would require backsteps is not cross-platform compatible.
What happened: Assuming the kube config file is in the standard path
%USERPROFILE%\.kube\config
, usingkubectl config set-cluster minikube --certificate-authority=C:\\Users\\username\\.minikube\\ca.crt
will persistcertificate-authority: ..\.minikube\ca.crt
for the cluster in the kube config. I found an issue explaining that this was done intentionally https://github.com/kubernetes/kubernetes/issues/75552, but it breaks some kubectl functionality, namelykubectl config view --flatten
run in the user's home directory produces the output:Note that I am using minikube for simplicity with the example/repro, but this issue exists regardless of the cluster you are attempting to configure.
What you expected to happen:
kubectl config view --flatten
should work and not be broken with this relative path, since it is correct relative to the.kube/config
file. But in my opinion, kubectl should also not assume it knows better and change the path passed in by the user, the user may have a specific reason for supplying an absolute path and I think kubectl should just respect the input provided by the user.How to reproduce it (as minimally and precisely as possible): Have an existing kube cluster in your context named
minikube
and set as the current context. Have a minikube ca cert available in the standard path%USERPROFILE%\.minikube\ca.crt
Manually set the certificate authority for the cluster using an absolute path:Now the following command will fail because of the relative path for the certificate authority in the kube context.
Environment:
kubectl version
): 1.31.0cat /etc/os-release
): Windows 11 amd64