Robert, could you please clarify what the implications of swapping out the no-restrictions ServiceAccount associated with the Dashboard would be on the GKE side?
Specifically, if we replaced the existing ServiceAccount with one having less privileges, would the next GKE upgrade maintain this customization or revert it? Or, even worse, could it break the overall upgrade procedure? As Ingo said, having a wide-open Dashboard without any ability for restriction seems like a fairly big security concern. We couldn't even block ingress access to the kube-system namespace via Network Policies because those aren't supported in GKE yet (to my knowledge). Thanks. On Tuesday, June 20, 2017 at 12:21:14 AM UTC+2, Robert Bailey wrote: > > > > On Mon, Jun 19, 2017 at 12:52 AM, Ingo Gottwald <in.go...@gmail.com > <javascript:>> wrote: > >> We would like to change some things on the default GKE setup and the docs >> don't clarify whether it is safe to do so or if the next GKE update will >> fail after that or revert everything. >> >> We're thinking about changing two things specifically: >> >> 1) The fluentd config map in order to parse a little more and use >> structured logging in our own containers. (while still letting them use >> stdout/stderr) >> 2) Change the dashboard and give it a read only scope with no access to >> secrets. >> >> The 2nd is by far the most important: >> Currently with k8s 1.6 via GKE we can restrict our users nicely with >> RBAC, but this does not limit the ability for users to use "kubectl proxy". >> With "kubectl proxy" everybody gets access to the kubernetes-dashboard >> which by GKE default has the kube-system default token mounted, that can >> basically do anything. >> The dashboard itself has no authn/authz. Therefore anybody can escalate >> their own privileges to "root" in the cluster and leave any RBAC >> restrictions behind. >> This is nothing that we would be willing to launch in production. >> >> Our solution to this would be to use a token with limited abilities >> mounted into the dashboard container, or if everything else fails, drop the >> UI for now. >> But in those cases we would need to modify the deployment object created >> by GKE. >> >> Will changes like these make our cluster go up in flames on the next GKE >> Master upgrade? >> > > To ensure that your changes aren't overwritten, it'd be best to delete the > GKE-managed addons (e.g. disable logging on your cluster) and install them > yourself (e.g. create your own fluentd daemonset). > > I don't think it is currently possible to disable the dashboard. > > >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Kubernetes user discussion and Q&A" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to kubernetes-use...@googlegroups.com <javascript:>. >> To post to this group, send email to kubernet...@googlegroups.com >> <javascript:>. >> Visit this group at https://groups.google.com/group/kubernetes-users. >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "Kubernetes user discussion and Q&A" group. To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-users+unsubscr...@googlegroups.com. To post to this group, send email to kubernetes-users@googlegroups.com. Visit this group at https://groups.google.com/group/kubernetes-users. For more options, visit https://groups.google.com/d/optout.
