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)

Commits related to this issue

Most upvoted comments

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 if automountServiceAccountToken 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:

This is a valid security concern, shouldn’t be closed.

/reopen

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.

Karydia inverts the following insecure default settings:

  • Unmount service account token
  • Restrict system calls by adding a seccomp profile
  • Run with minimal privileges by adding a non-root user
  • Disallow privilege escalation
  • Restrict network communication by automatically adding one or multiple network policies to each namespace

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.