kubernetes: kubeconfig config set-context fails with mix of writable & non-writable entries in KUBECONFIG
Is this a BUG REPORT or FEATURE REQUEST?:
Uncomment only one, leave it on its own line:
/kind bug
/kind feature
What happened:
with KUBECONFIG=/home/pdbogen/.kube/config:/etc/kube/config
, kubeconfig config set current-context sandbox
returns error: open /etc/kube/config.lock: permission denied
What you expected to happen:
kubeconfig should lock only /home/pdbogen/.kube/config
and set the indicated setting there
How to reproduce it (as minimally and precisely as possible):
$ mkdir readonly writable
$ chmod -w readonly
$ KUBECONFIG=$PWD/writable/config:$PWD/readonly/config kubectl config set current-context example
error: open /home/pdbogen/readonly/config.lock: permission denied
Anything else we need to know?:
I want to be able to provide my users a system-managed kubernetes config that describes various clusters. I would like them to be able to specify things like current-context easily, via kubectl config
.
Even when ~/.kube/config
exists and contains a current-context
setting, kubectl config set current-context
still tries to lock /etc/kube/config.
Environment:
- Kubernetes version (use
kubectl version
):Client Version: version.Info{Major:"1", Minor:"10+", GitVersion:"v1.10.5-16", GitCommit:"32ac1c9073b132b8ba18aa830f46b77dcceb0723", GitTreeState:"clean", BuildDate:"2018-06-27T17:46:30Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"}
(we build our own, currently can’t use 1.11) - Cloud provider or hardware configuration: n/a; but, Amazon EKS
- OS (e.g. from /etc/os-release): Ubuntu Xenial 16.04.5
- Kernel (e.g.
uname -a
): 4.4.0-1063-aws - Install tools: na
- Others: na
About this issue
- Original URL
- State: open
- Created 6 years ago
- Comments: 23 (9 by maintainers)
I had the same issue. Please make sure that
$HOME/.kube/
directory has the same permission as$HOME/.kube/config
.I got this error when running
kubectl config use-context "clustercontextname2
whiting a devcontainer. if the same command is executed outside the devcontainer no error is reported. Notice thatconfig.lock
is created with000
ownership so it’s unaccessible to kubectl. No chance to use the command within the devcontainer.vscode@docker-desktop
is the devcontainer/home/user/.kube/
is the home user and .kube dir in the hostUpdate: Uncheck
Enable VirtioFS accelerated directory sharing
then no moreconfig.lock
problemI have in fact discovered a usable workaround for this.
If the system-level config files are symlinked into a directory the user can write to, then
kubectl
will lock the symlinks instead of the actual config files. kubectl can’t write to these files, so some config change operations may fail; but as long as a writable config precedes the non-writable config inKUBECONFIG
, it can work at least for setting the context. Here’s an example:Still, I think that
kubectl
should only try to lock a file just before writing to it, which would make this workaround unnecessary. Or, perhaps, it should actively recognize when files are not writable, so not candidates for writing a config. This would be even better, because then a KUBECONFIG like$HOME/.kube/config:/etc/kube/config
could automatically create the.kube/config
when needed.We just ran into the exact same scenario as above, and had the developer uncheck
Enable VirtioFS accelerated directory sharing
and it worked immediately. We could not explain the issue otherwiseThis is ridiculous. The
use-context
subcommand at the VERY LEAST should NOT care if the filesystem in which the config is on is writable. All of these workarounds are ridiculous.