kubernetes: Kubernetes should not mount default service account credentials by default
/kind bug
What happened:
Kube automounts default service account credentials, which allows any compromised pod to run API commands against the cluster. This seems like a very odd choice from a security standpoint - I only just discovered this was the case after a couple years of running a Kube cluster in production.
What you expected to happen:
Pods not having cluster-modifying power by default.
How to reproduce it (as minimally and precisely as possible):
Run a default Kube cluster and pod.
Anything else we need to know?:
n/a
Environment:
- Kubernetes version (use
kubectl version
): Client Version: version.Info{Major:“1”, Minor:“8”, GitVersion:“v1.8.4”, GitCommit:“9befc2b8928a9426501d3bf62f72849d5cbcd5a3”, GitTreeState:“clean”, BuildDate:“2017-11-20T05:28:34Z”, GoVersion:“go1.8.3”, Compiler:“gc”, Platform:“darwin/amd64”} Server Version: version.Info{Major:“1”, Minor:“8+”, GitVersion:“v1.8.4-gke.1”, GitCommit:“04502ae78d522a3d410de3710e1550cfb16dad4a”, GitTreeState:“clean”, BuildDate:“2017-12-08T17:24:53Z”, GoVersion:“go1.8.3b4”, Compiler:“gc”, Platform:“linux/amd64”} - Cloud provider or hardware configuration: GKE
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Reactions: 18
- Comments: 41 (19 by maintainers)
Implementing this would be a significant compatibility break. I don’t see a reasonable way to roll out this requested change as default Kubernetes behavior.
/close
Instead of changing the default for everyone, can we at least get a configuration option for that?
I’m not super-familiar with Kubernetes internals, but maybe it would belong to Kubernetes API server, which could be configured to autoset
automountServiceAccountToken: false
ifautomountServiceAccountToken
is not explicitly defined.For now with the default options (k8s-v1.9.3), running pods have all permissions to call K8s APIs, it is dangerous! I think
automountServiceAccountToken: false
should be the default setting, which will prevent that./reopen
@Nowaker: 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.
This is a valid security concern, shouldn’t be closed.
/reopen
Note: my coworker just found https://github.com/karydia/karydia.
While I’m happy with the workaround, the idea that one has to use a third party service to revert some insecure default settings is still pretty mind boggling.
I’m not saying that it’s unreasonable, just that it’s going to be a hard pill to swallow for GA distributions of Kubernetes. I could see this happening in the v2 pod API.
Looks like you need to create an entirely new cluster to avoid this and it was ‘fixed’ sometime in Dec 2017.