Dashboard: Dashboard with ABAC policy failed to prompt login

[nancykyo]

Issue details

User "system:anonymous" cannot get services/proxy in the namespace "kube-system".: "No policy matched."

Environment

Dashboard version: 1.5.1
Kubernetes version: 1.5.1
Operating system: centos 7.2
Node.js version: v5.0.0

I'm using the yaml to deploy dashboard as a service in k8s.

Steps to reproduce

Using --basic-auth-file is fine, that Chrome can promote login dialog.
But when set those args to apiserver:
--authorization-policy-file=/etc/kubernetes/security/abac.policy --authorization-mode=ABAC

Observed result

visiting https://kubemaster:6443/api/v1/namespaces/kube-system/services/kubernetes-dashboard/proxy/#/node?namespace=default
It says:
User "system:anonymous" cannot get services/proxy in the namespace "kube-system".: "No policy matched."
No login prompt, so no way to get login..

Expected result

Expected that different user can obey the policy and login normally.
And the policy "read-only", for me, I think this is not a good option, we use ENV a lot. but readonly give the access to reach those ENV variables.

[nancykyo]

@maciaszczykm
hey, I saw you tag it as P1, any plan on this?

[maciaszczykm]

@nancykyo Authentication is one of our priorities, but it's very large topic and we are planning it for a long time now (#964). Unfortunately, I cannot let you know, about any specific time frame.

[discostur]

I just saw exactly the same problem if you upgrade your cluster to v1.6 and use RBAC as authentication method. Running a k8s cluster via google container engine and one on premise.

If i try to login to my k8s dashboard running on GCE (v1.6) i get the following error:

User "system:anonymous" cannot proxy services in the namespace "kube-system".: "No policy matched.\nUnknown user \"system:anonymous\""

That means i am not able to login to my dashboard. Since k8s v1.6, anonymous authentication is enabled by default. After enabling, the apiserver thinks we didn't provide any login information so we should be anonymous (which is wrong; instead he should provide us a login mask).
I tried to work around with my on premise cluster (where i have access to the apiserver manifest) and started it with the flag

--anonymous-auth=false

Then i'm able to authenticate via basic auth (dashboard provides me a login mask) but after 1:20 minutes the apiserver restarts, because healthz-checks are failing (because healthz-checks are done via anonymous-requests) ... So this is no solution.

This is really bad because (as i wrote) the errors appears not only on premise, but also if you host directly on google container engine...

[nambrot]

I just ran into the same issue where I upgraded my cluster to 1.6 and now can no longer access the dashboard

[maciaszczykm]

Please use https://github.com/kubernetes/dashboard#deployment to setup Dashboard, because since 1.6 you need to have service accounts.

[discostur]

@maciaszczykm i think this one is not yet fixed, because if i want to connect to my dashboard via api-server proxy request i still get:

https://IP:6443/api/v1/proxy/namespaces/kube-system/services/kubernetes-dashboard/

User "system:anonymous" cannot proxy services in the namespace "kube-system".

Is the only way to access the Dasboard via NodePort? (since 1.6)

[floreks]

As you can see in the log api server rejects request. It is not dashboard issue but rather cluster config. You need to grant anonymous user access to the cluster.

[nambrot]

@floreks I'm a little unclear what the solution here is. I have upgraded 1.6 cluster on GKE. Am I supposed to grant user system:anonymous universal access to the cluster? I assume that doesn't mean that anyone can access my cluster?

[toby5box]

@nambrot Per the hint given by @maciaszczykm, assuming you have installed the Google Cloud CLI tools and are authenticated to your cluster, you can run kubectl proxy on a local machine and then browse via the localhost port it advertises. This worked perfectly for me.

[nambrot]

Using kubectl proxy works indeed for me, but I used to be able to just access the dashboard by hitting the master directly with HTTP Basic Auth with the credentials given in GKE console. I'd prefer that method over having to run kubectl proxy myself.

[floreks]

I don't have much time but this is a recurring issue. Kubernetes starting from 1.6 has restricted more tightly access policies. You can read their documentation. Basically by default cluster is more secure and you now need to know how to configure it and grant access to apps. There are many similar issues regarding that both here and on k8s repo.

[ensonic]

It is sad that this is a recurring issue and there are no clear docs on this. I am in the same situation as the original poster. Upgraded cluster on GKE and was using the dashboard via https://<kubernetes-master>/ui. Using kubectl proxy works, but is annoying to have a terminal blocked. This link does not help:
https://github.com/kubernetes/dashboard#deployment since it only mentions that user name and pasword is required (which is set). Most other bugs point to https://github.com/kubernetes/kubernetes/issues/39722.

[floreks]

I can't provide any generic solution for that because it depends on the cluster configuration. Normally browser uses certificates to confirm page authenticity and additionally api server may require user certificate/credentials to be presented on access.

Using kubectl proxy as a gateway is similar to exposing insecure port and accessing it this way. Only difference is that kubectl proxy can be configured to allow requests from certain hosts and request has to be authorized first so user might not have full access to the cluster when he is using kubectl proxy.

One option is to configure proxy before apiserver and make it responsible for altering the request header so that apiserver has required information about who wants to access it (authn) and what does this user want to do(authz).

Unfortunately we can't fix this on our side as this is not related to dashboard. Every user has to configure it on their side depending on their environment and requirements.