This is one of the most pressing issues I tend to evaluate on infrastructures. I'm curious to see a few months down the line your opinion on how the dev teams embraced Kubernetes' setups independently or if they kept depending on a dev-ops team to do so.
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...
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 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 :)