-
Notifications
You must be signed in to change notification settings - Fork 921
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unexpected consequences of using untrusted kubeconfig files #697
Comments
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
Stale issues rot after 30d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
Rotten issues close after 30d of inactivity. Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
@fejta-bot: Closing this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/reopen |
@techdragon: You can't reopen an issue/PR unless you authored it or you are a collaborator. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
once a kubeconfig is downloaded from the internet it's responsibility of the administrator to verify the validity of the kubeconfig before using the kubeconfig. similar goes for bash scripts:
^ this is a bad practice. |
@neolit123 Bad practice or not: if we can prevent people from footgunning themselves, we should consider doing so. @orymate could you reopen the issue, please? |
We reached out the Kubernetes security team with the following report, and the only response within a week was from Brandon Philips, an advice to open a public issue here.
We recently realized an issue about the security of Kubeconfig files, especially when used for the exchange of credentials and for accessing Kubernetes API servers. It is common practice to make Kubeconfig files available for download.
The issue is that most users are not aware that Kubeconfig files can lead to the execution of malicious shell commands or to the exposure of arbitrary files. Of course security-aware interactive users, or the developers of automated systems take care of inspecting the contents of the Kubeconfig file before use, but it is not something that you trivially identify as a vulnerable interface.
There are two broad set of issues:
The first one affects
kubectl
users primarily, but we haven’t found any public discussions about this topic so far, neither a single warning in the documentation.Our suggestion would be to start a discussion now and to consider some of the following solutions. Some of these are specific to kubectl, while others could be implemented in the Go client:
exec()
-ing from Kubernetes just like the/etc/shells
of Unix systems. Installed packages, like the gcloud tool, could add themselves to the list.exec()
-ed from Kubernetes to be in ~/.kube/bin or another folder used for this single purpose, require commands to be basenames (no slashes), and use this folder as the only item of PATH. Administrators or package installers may create the needed symlinks.Create a “base” kubeconfig that is not replaced easily, and unlike the normal kubeconfig, can set sensitive values like the list of allowed commands. This might be controlled by a new env var and a default value.
~/.kube/cluster.d
orcontext.d
. This might make it possible to keep the above-mentioned sensitive flags in the kubeconfig, which is not supposed to be replaced with another configuration as an everyday practice.Find below a few examples for illustration of the problem (use
env KUBECONFIG=file kubectl version
to try them):The text was updated successfully, but these errors were encountered: