windows: absolute paths do not work properly in config files

[neolit123]

on Windows there is a problem with the go standard library where the filepath.Abs() function
https://golang.org/pkg/path/filepath/#IsAbs

would return false for a path /foo/bar. this is by-design and is in a way correct, since absolute paths on Windows would normally need a drive letter - e.g. c:/foo/bar. (note: \ vs / are interchangeable)
yet, a path without a drive letter can still be considered absolute to the current drive.

this is hardcoded in client-go, kubelet and the rest of k8s where if you pass a path to a certificate in a kubeconfig file without a drive letter on windows it would assume a relative path and covert something like /foo/bar/ca.crt to /localpath/foo/bar/ca.crt, causing errors.

the problem was observed in KubeletConfiguration that kubeadm generates and shares between nodes, and the fix was in the lines of this:
https://gist.github.com/neolit123/1b7375c8a956155a2ca1cdd901336bce
but this has to be double checked.

a couple of more problems where this can happen are:

• the kubeadm API validation of absolute path for socket.
• the kubelet.conf file which kubeadm mutates after init to point to rotatable client cert/key.

what kubeadm must do to properly support Windows paths without too much user interaction is to convert them by determining the local drive /foo/bar/ca.crt -> c:/foo/bar/ca.crt (example in the above gist)

[neolit123]

/area windows
/priority important-longterm

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

[neolit123]

/remove-lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[yongxiu]

I'm also hitting this issue, you diff (https://gist.github.com/neolit123/1b7375c8a956155a2ca1cdd901336bce) looks good to me, can you help send it as a pull request?

[yongxiu]

/remove-lifecycle stale

[neolit123]

I'm also hitting this issue, you diff (https://gist.github.com/neolit123/1b7375c8a956155a2ca1cdd901336bce) looks good to me, can you help send it as a pull request?

have you tried the patch in your setup?
i'm busy with other work items ATM, but happy to review a PR if you send it.

[hwdef]

I can pick up this.

[hwdef]

I tried this patch, and I met a error.

I think this error is caused by the GO's filepath.join function. I want to do some special customization for Windows, I don't know if it is right.

[neolit123]

thanks for having a look.

why is mutatePathsOnWindows panicing exactly?
is it because Authentication.X509 is nil?

i recall this patch used to work for me and someone else who tested it, so i wonder what changed.

I think this error is caused by the GO's filepath.join function. I want to do some special customization for Windows, I don't know if it is right.

we should avoid adding OS specifics (GOOS checks) in the Default function. so perhaps there is another way to solve this.

[neolit123]

also might be best to send a PR for this (even if its failing in CI) and we can continue the discussion there, so that we have a better view of the DIFF.

[neolit123]

fixed in kubernetes/kubernetes#105992
thanks to @hwdef

[hwdef]

fixed in kubernetes/kubernetes#105992 thanks to @hwdef

Thanks for your help!