3 ms·

I would never deny that there's a lot of work to do, but let's be clear: Kubernetes' security model is evolving in concert with a large number of high-profile u

I would never deny that there's a lot of work to do, but let's be clear: Kubernetes' security model is evolving in concert with a large number of high-profile users' demands. Designing security in the absence of real customers would have been a mistake.

raesene6 10y ago
Of course, I don't think my comment implied anything else... do you? My point was around maturity of things that enterprises tend to focus on like hardening/security best practice guides. The kubelet API bit was just an example, although I do think the Kubernetes docs could be a bit clearer that this is a critical change to make after install to secure the cluster, given that all the install methods I've tried so far (kube-up, kubeadm etc) leave the kubelet API available unauthenticated by default.
- thockingoog 10y ago
  My point was that we have enterprises who are using it and helping to shape it. There are parts that are simply under-developed and there are parts that are downright embarrassing, no denial. I do expect that many of the docs/articles/blogs written about 1.6, 1.7, 1.8 are going to focus on hardening, security, etc. I just hope it isn't selinux style: "how do I turn it off" :)
  - raesene6 10y ago
    no indeed, I think it's important to provide a set of options and advice about when companies might want to use them. A setup that's appropriate to say a start-up environment may very much not be appropriate to a bank for example, so hopefully security docs will be able to lay out the pros and cons of each configuration choice. The CIS guide for Kubernetes has started up so that will hopefully see some of these things mentioned.
  - tmzt 10y ago
    The kublet API hardening looks very useful and there seems to a lot of good (security) stuff coming with each release. In many environments, however, other aspects of Kube's security prove inadequate. For instance, there is currently no way to protect secrets in an environment requiring an HSM for certain keys. In contrast, secrets are stored in an etcd server accessible to the entire cluster (please correct me if this is out of date.) One article discussing this: https://medium.com/on-docker/secrets-and-lie-abilities-the-state-of-modern-secret-management-2017-c82ec9136a3d#.od5x387qj https://medium.com/on-docker/secrets-and-lie-abilities-the-s...

raesene6 10y ago

Of course, I don't think my comment implied anything else... do you? My point was around maturity of things that enterprises tend to focus on like hardening/security best practice guides. The kubelet API bit was just an example, although I do think the Kubernetes docs could be a bit clearer that this is a critical change to make after install to secure the cluster, given that all the install methods I've tried so far (kube-up, kubeadm etc) leave the kubelet API available unauthenticated by default.

thockingoog 10y ago
My point was that we have enterprises who are using it and helping to shape it. There are parts that are simply under-developed and there are parts that are downright embarrassing, no denial. I do expect that many of the docs/articles/blogs written about 1.6, 1.7, 1.8 are going to focus on hardening, security, etc. I just hope it isn't selinux style: "how do I turn it off" :)
- raesene6 10y ago
  no indeed, I think it's important to provide a set of options and advice about when companies might want to use them. A setup that's appropriate to say a start-up environment may very much not be appropriate to a bank for example, so hopefully security docs will be able to lay out the pros and cons of each configuration choice. The CIS guide for Kubernetes has started up so that will hopefully see some of these things mentioned.
- tmzt 10y ago
  The kublet API hardening looks very useful and there seems to a lot of good (security) stuff coming with each release. In many environments, however, other aspects of Kube's security prove inadequate. For instance, there is currently no way to protect secrets in an environment requiring an HSM for certain keys. In contrast, secrets are stored in an etcd server accessible to the entire cluster (please correct me if this is out of date.) One article discussing this: https://medium.com/on-docker/secrets-and-lie-abilities-the-state-of-modern-secret-management-2017-c82ec9136a3d#.od5x387qj https://medium.com/on-docker/secrets-and-lie-abilities-the-s...