Whilst Kubernetes is really cool and has a lot of nice features I think, at the moment, it's lacking in some areas that are likely to be important for Enterprise customers who are likely to be interested in this Docker EE setup.
Specifically things like best practice guides for securing Kubernetes are currently thin on the ground compared to Docker which has a fair amount of information covering that sort of thing.
Also the Kubernetes security model is still being developed with things like locking down the kubelet API still to come in 1.6. Whilst that's less likely to be important for some companies, enterprises tend towards solutions with that sort of thing sorted out.
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.
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.
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" :)
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.)
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.
Interestingly we had many "hard" problems with Docker itself (race conditions, stuck Docker daemon) so my confidence in Docker getting the Enterprise thing right is not very high.
Specifically things like best practice guides for securing Kubernetes are currently thin on the ground compared to Docker which has a fair amount of information covering that sort of thing.
Also the Kubernetes security model is still being developed with things like locking down the kubelet API still to come in 1.6. Whilst that's less likely to be important for some companies, enterprises tend towards solutions with that sort of thing sorted out.