Dashboard permission errors on upgrading to dashboard version 1.10.1

[vivgoyal]

I have a k8s 1.11.5 cluster which was running dashboard version 1.8.3. I upgraded the dashboard to version 1.10.1 but this gives me following error:

There are multiple pages/issues asking about the same thing and what I figured out is that all the solutions suggest giving admin privileges to dashboard's service account. But this is something we do not want to do since it could be a security issue. Some of the page links that suggest this are:
https://github.com/Azure/acs-engine/issues/3130
https://blogs.msdn.microsoft.com/kennethteo/2018/07/26/aks-with-aad/

We would like to know what exactly changed in the latest dashboard that is causing this? Is this expected?

[maciaszczykm]

Are you skipping auth?

[vivgoyal]

We have a proxy in front for authentication. This was working fine till dashboard 1.8.3.
I am confused here, why do we even need to grant admin privileges to dashboard's service account?
Dashboard should ideally be using user's privileges.

[floreks]

@vivgoyal You do not need and should never grant Dashbord SA more privileges than it already has. There are many things that changed compared to v1.8.3 which was released almost a year ago. You can read about some changes here.

[vivgoyal]

@floreks I just re-checked with v1.10.0 and things seem to just work fine. It probably has to do with something that changed in v1.10.1

[floreks]

Most probably it is related to this changes:

• Add new flag --enable-skip-login and disable Skip option on the login view by default
• CVE-2018-18264: Fix security issue related to using Dashboard's Service Account (Security fix (CVE-2018-18264) #3400 and Fix for unauthenticated secret access #3289)

You might have been using that without knowing. Try to see if adding --enable-skip-login=true to the dashboard container changes it. Keep in mind that adding this flag might be a security issue.

[kvpt]

I have the same issue in 1.10.1, 1.10.0 works fine.
I use a dedicated serviceaccount and clusterrolebinding to connect with a token to the cluster.
The warning popup indicate that kubernetes-dashboard serviceaccount doesn't have rights, but I doesn't use the token from this account to connect, am I missing something ?

[maciaszczykm]

Can you show us your YAML files?

[kvpt]

Which file ? I don't use any yaml file, I use a token to connect.

[vivgoyal]

We figured that we need to specify --enable-insecure-login flag in our yaml, this was not needed in past, even though the flag has been available since long.

Probably because of this particular change:
func (self *clientManager) isLoginEnabled(req *restful.Request) bool {
return req.Request.TLS != nil || args.Holder.GetEnableInsecureLogin()
}

[floreks]

It was added in 1.10.0 if I remember correctly. Basically, we do not recommend exposing Dashboard over HTTP, unless you are using some kind of reverse proxy for authentication and authorization. This was added for security reasons.

If you have solved the issue then I think we can close.

/close

[k8s-ci-robot]

@floreks: Closing this issue.

In response to this:

It was added in 1.10.0 if I remember correctly. Basically, we do not recommend exposing Dashboard over HTTP, unless you are using some kind of reverse proxy for authentication and authorization. This was added for security reasons.

If you have solved the issue then I think we can close.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[gsadhani]

It was added in 1.10.0 if I remember correctly. Basically, we do not recommend exposing Dashboard over HTTP, unless you are using some kind of reverse proxy for authentication and authorization. This was added for security reasons.

If you have solved the issue then I think we can close.

/close

@floreks We have a reverse proxy for authentication and authorization deployed in front of the dashboard, can you confirm the usage of --enable-insecure-login flag is appropriate in that case?

[floreks]

@gsadhani In this case you could actually use alternative deployment instead of a recommended one. This way Dashboard login view would not be shown at all and your proxy should handle passing the authorization header.