brand new 1.7.4 cluster w/o legacy auth : Unknown user \"system:serviceaccount:kube-system:default\""

[ldemailly]

Steps to reproduce

1. create brand new alpha cluster 1.7.4
2. wait a long time for green checkmark/cluster to appear ready
3. click connect to cluster
4. do gcloud container clusters get-credentials ... successfully
5. kubectl proxy &
6. visit localhost UI
7. end up on http://localhost:8001/api/v1/namespaces/kube-system/services/kubernetes-dashboard/proxy/#!/workload?namespace=default

Environment

Installation method: UI
Kubernetes version: 1.7.4
Dashboard version: @@BUILD_DASHBOARD_VERSION
Commit: @@BUILD_GIT_COMMIT

Observed result

Dashboard reported Forbidden (403):

User "system:serviceaccount:kube-system:default" cannot list replicationcontrollers in the namespace "default".: "Unknown user \"system:serviceaccount:kube-system:default\"" (get replicationcontrollers)

Comments

[floreks]

Forbidden Access. GCE cluster deploys dashboard with minimal privileges of default SA. You have to grant permissions yourself. Also you are using outdated version of dashboard. Deploy instructions are in our README.

[ldemailly]

I am using the dashboard the cluster creation created, if it's the wrong one maybe we need to fix the gke setup ?

any pointer on how to grant whatever is missing / and is it expected it doesn't work out of the box with no instructions on how to fix it?

[floreks]

You can remove it and deploy one using instructions from our README. It will have admin privileges.

[ldemailly]

k thx, will try that in the morning (still think gke setup is wrong that it leads to a non functional dashboard but maybe that's why it's "alpha")

[floreks]

It's not that. Deploying dashboard by default with full admin privileges is a security risk. People without proper knowledge about kubernetes can easily expose their cluster to breaches. User has to grant privileges on his own and be aware of what he is doing.

[ldemailly]

same happens without alpha, it's an rbac issue

a (bad?) workaround that makes it work is :

kubectl create clusterrolebinding --user system:serviceaccount:kube-system:default kube-system-cluster-admin --clusterrole cluster-admin

my issue (filled into gke separately, 65286402) is why isn't the install of the dashboard creating a dashboard service account and the dashboard service account not having the right privileges out of the box (or use the client/user's privileges)

also is there another role, smaller scope than cluster-admin that would work ?

[floreks]

my issue (filled into gke separately, 65286402) is why isn't the install of the dashboard creating a dashboard service account and the dashboard service account not having the right privileges out of the box (or use the client/user's privileges)

There is no way to make it use by default user privileges. Dashboard would need some data about user to impersonate him. In 1.6.3 only way to do that is to create some reverse proxy that will send request header Authorization: Bearer <token> and this will make dashboard use this token for all requests to apiserver.

Also there is no way to just set "right privileges" by default as there are not any. Every user will have custom set of privileges that will be default for him. Some people might want to expose dashboard with pure read only privileges and others will grant it full admin privileges. There are just too many combinations to do it for you. That is why GKE by default grants only minimal privileges needed to actually start dashboard and user has to take care of the rest.

Read about RBAC and prepare your own SA with correct set of privileges that will work for you.

Next release will introduce log in option to dashboard. You will be able to log in using token or basic credentials (if enabled in the cluster).

[dukelyuu]

add this role for dashboard as follow:
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
name: kubernetes-dashboard
labels:
k8s-app: kubernetes-dashboard
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:

kind: ServiceAccount
name: kubernetes-dashboard
namespace: kube-system

[ldemailly]

cc @andraxylia btw this is the issue that hit us