kubectl config set-cluster --certificate-authority forces relative path

[bliles]

What happened:
Assuming the kube config file is in the standard path %USERPROFILE%\.kube\config, using kubectl config set-cluster minikube --certificate-authority=C:\\Users\\username\\.minikube\\ca.crt will persist certificate-authority: ..\.minikube\ca.crt for the cluster in the kube config. I found an issue explaining that this was done intentionally kubernetes/kubernetes#75552, but it breaks some kubectl functionality, namely kubectl config view --flatten run in the user's home directory produces the output:

error: open C:\Users\.minikube\ca.crt: The system cannot find the path specified.

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:

kubectl config set-cluster minikube --certificate-authority=C:\\Users\\[username]\\.minikube\\ca.crt

Now the following command will fail because of the relative path for the certificate authority in the kube context.

kubectl config view --flatten

Environment:

• Kubernetes client and server versions (use kubectl version): 1.31.0
• OS (e.g: cat /etc/os-release): Windows 11 amd64

[mpuckett159]

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

[bliles]

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.

[mpuckett159]

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

[bliles]

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.