|
|
|
|
|
by danielmartins
3568 days ago
|
|
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... |
|
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