Dashboard: RBAC failing on vanilla 1.6 install

[dewet22]

Issue details

Environment

Freshly installed 1.6 cluster.

Dashboard version: https://rawgit.com/kubernetes/dashboard/master/src/deploy/kubernetes-dashboard.yaml
Kubernetes version: Server Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.0", GitCommit:"fff5156092b56e6bd60fff75aad4dc9de6b6ef37", GitTreeState:"clean", BuildDate:"2017-03-28T16:24:30Z", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"}

Steps to reproduce

• kubectl apply -f https://rawgit.com/kubernetes/dashboard/master/src/deploy/kubernetes-dashboard.yaml
• kubectl proxy
• open http://localhost:8001/ui

Observed result

Forbidden 403: User "system:serviceaccount:kube-system:default" cannot list pods in the namespace "default". (get pods)

Expected result

Dashboard as freshly installed in a 1.5 cluster.

[floreks]

It's related to cluster upgrade not dashboard itself. We can't enforce any RBAC settings from the application. User has to take care of that and grant all necessary permissions.

From 1.6 Kubernetes release notes:

Security and Setup: Users concerned with security will find that RBAC, now beta adds a significant security benefit through more tightly scoped default roles for system components. The default RBAC policies in 1.6 grant scoped permissions to control-plane components, nodes, and controllers. RBAC allows cluster administrators to selectively grant particular users or service accounts fine-grained access to specific resources on a per-namespace basis. RBAC users upgrading from 1.5 to 1.6 should view the guidance here.

Here is a link to docs for RBAC migration from 1.5 to 1.6:
https://kubernetes.io//docs/admin/authorization/rbac/#upgrading-from-15

[jeroenjacobs79]

Temporary workaround I used based on the document mentioned above:

kubectl create clusterrolebinding add-on-cluster-admin \
--clusterrole=cluster-admin \
--serviceaccount=kube-system:default

Probably not suitable for production environments? Not sure, but works for now.

[floreks]

Normally for production you would want to define different service account specially for dashboard and grant it all necessary privileges. Service account that should be used instead of default one in given namespace can be defined in yaml file used to deploy dashboard.

Closing as this is configuration issue, not directly related to dashboard.

[dewet22]

@jeroenjacobs1205 That's exactly what I did too.

@floreks Agreed this is bad practice outside dev clusters, but it could be made more prominent in the docs that you do have to do a bit more than just kubectl create -f https://rawgit.com/kubernetes/dashboard/master/src/deploy/kubernetes-dashboard.yaml to get a working dashboard on 1.6+.

[floreks]

Good suggestion. We will update our documentation.

[liggitt]

Normally for production you would want to define different service account specially for dashboard and grant it all necessary privileges

Does that mean you are not expecting production deployments to use the src/deploy/kubernetes-dashboard.yaml file provided by the dashboard (since it does not define a dashboard service account)?

[floreks]

It all depends on the level of security you want to achieve. I can't say that yaml we provide will work for every use case because it won't. It will work fine on prod clusters but IMO it's more secure to define per app service account and per app roles, so every app is authorized to access only resources it actually needs.

With namespace level service account you have to define wider scope privileges that will work for all apps, that are using it. It's not as secure as it can be, but it's sufficient for most users.

It's always best to tweak dashboard (or any other app) according to you needs before deploying. For example on bigger clusters it's good to grant it more resource qutoas (cpu/ram) or define tightly scoped privileges.

[ggaaooppeenngg]

Self-implemented scheduler also needs config for rbac, I think a rbac yaml file example should be mentioned in the document