I believe the reason why people tend to restrict the cluster access to just a handful of people is because - at least for now - these tools lack proper ways to control access to specific resources by specific groups of people. I mean, there are ways to do that in Kubernetes today[1], but the setup is kept as an exercise to cluster operators.

I don't know for sure, but this is less of a problem in some distributions, such as OpenShift[2].

Once this problem is solved, there's no reason to "shield" the cluster from devs.

[1] http://kubernetes.io/docs/admin/authorization/

[2] https://docs.openshift.com/enterprise/3.0/admin_guide/config...

Disclaimer - I work at CoreOS and on the Kubernetes auth sub systems

Today, most of the auth-N plugins[0] (the upstream equivalent to the OpenShift doc you linked to) are relatively minimal. Most of these are aimed at providing pluggability for other apps that focus on ease of use. Google uses the webhook implementation for its GKE auth-N and we (CoreOS) continue to try to make our OpenID Connect server federate to more backends (LDAP, GitHub, etc.).[1]

With these kind of tooling, it's completely possible to map auth-Z policies to, say a group of LDAP users. But yes, there's a lack of canonical documentation on how to go about this. We're always trying to negotiate how much of this should live in core Kubernetes and how much should be provided by third party services (and what the upstream docs should endorse).

But today I'd still (perhaps because I'm biased) recommend giving your CEO different credentials for your prod cluster :)

[0] http://kubernetes.io/docs/admin/authentication/ [1] https://github.com/coreos/dex

I like dex a lot. Very cool project. Was gonna use it + k8s for a side project until I realized for the scale I had (1 user) Auth0 + Heroku is still just fine, but dex lets you run Auth0 on your own and completely in your control which is awesome. No more setting up authentication!

To add to Eric's point - the goal over the long term is to flesh this stuff out and have both flexibility and multi-tenancy in Kube. OpenShift could be opinionated about security (no compromise) while for Kube we wanted to make sure we built first a system that was flexible enough to be used in many ways.

I think that was the correct choice, because most Kube deployments are still single ops team focused, and it was possible for CoreOS to build and integrate Dex without having to face a high bar.

It'll get more opinionated eventually :)