Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ServiceAccount access restrictions are ignored when skipping authentication #2668

Closed
onitake opened this issue Dec 12, 2017 · 8 comments

Comments

@onitake
Copy link
Contributor

commented Dec 12, 2017

Environment
Dashboard version: 1.8.0
Kubernetes version: 1.8.3
Heapster: 1.3.0-beta.1
Operating system: CentOS 7

kube-apiserver runs with --authorization-mode=ABAC,RBAC, ServiceAccount and Role for kubernetes-dashboard are deployed as in https://github.com/kubernetes/dashboard/blob/master/src/deploy/recommended/kubernetes-dashboard.yaml .

kubernetes-dashboard is configured to be only accessible via TLS.

Steps to reproduce
  1. Open the dashboard in a web browser
  2. Observe the login page
  3. Log in using a token and verify access rights
  4. Verify access rights without logging in
Observed result
  1. The login screen works as expected (using token or kube.config authentication), but also displays a 'SKIP' button
  2. When clicking the 'SKIP' button, full access to all resources is granted
Expected result

The Role bound to the ServiceAccount should prevent access to any resources that are not part of a user-supplied token. According to the kubernetes-dashboard-minimal Role, this should only include a handful of resources that dashboard requires to function.

Ideally, nothing should be granted at all and there shouldn't even be a way to skip authentication.

Comments

I am not sure if this behaviour is caused by ABAC being enabled in our cluster or an incorrect dashboard configuration. ABAC will be disabled in my cluster in the near future, but this is currently not possible and I am not sure if it will resolve the problem.

@floreks

This comment has been minimized.

Copy link
Member

commented Dec 12, 2017

This is not a Dashboard issue. Scenario you are describing is using service account specified in here: https://github.com/kubernetes/dashboard/blob/master/src/deploy/recommended/kubernetes-dashboard.yaml#L146

On our side all resource are created correctly. Authorization in Dashboard is managed fully by apiserver. Dashboard is only a proxy and can not escalate any privileges. You need to take a look at your cluster configuration or maybe ask for help on k8s core repository. If you have full access then it means that kubernetes-dashboard service account has full access and RBAC is not working properly.

@floreks floreks closed this Dec 12, 2017

@onitake

This comment has been minimized.

Copy link
Contributor Author

commented Dec 12, 2017

Thanks for this information - I assume this is related to ABAC still being in place. But it's completely unclear to me why it would happen. If a user logs in using a token, access control works as expected. Why would this not be the case when the ServiceAccount is used? Does dashboard use the default token instead? The default token has very low security compared to a proper RoleBinding, but why would dashboard use the default token at all?

Also, I think it should be possible to disable the "SKIP" mode completely and only allow access when a valid authentication token is presented.
This is very similar to the "employ no security measures at all if dashboard is not configured correctly" issue - dashboard should be able to be put into a "secure" mode where only authorization through authentication is allowed.

@floreks

This comment has been minimized.

Copy link
Member

commented Dec 13, 2017

Skip option relies on privileges granted to the pod. It is fully based on kubernetes mechanisms. Every pod has Service Account token mounted into the pod in /var/run/secrets/kubernetes.io/serviceaccount if I remember correctly. This token then is used to authorize pod's requests to API server and grant/deny access.

Skip option is secure by default if cluster is configured properly. User has pretty much no access to the cluster at all. He can only see empty pages. Our kubernetes-dashboard-minimal Role has very little permissions and does not compromise security.

"Authorization through authentication" is very misleading in kubernetes because without authorization every Pod by default has full access to the cluster and it is very easy to escalate privileges. It does not matter if it is done using Dashboard or any other app deployed in the cluster.

"Skip" option can be also very useful for people that want to grant some read permissions to limited resources for "anonymous" users, i.e. as a demo.

@onitake

This comment has been minimized.

Copy link
Contributor Author

commented Dec 13, 2017

I agree - SKIP is useful in many cases. But in others, it may be counter-productive, or simply useless.
A command-line option to disable it could be added.

As for the default permissions: I suspect that dashboard is using the default token (which has too many permissions in my case) instead of the ServiceAccount. I'll run a few tests and report back.

@floreks

This comment has been minimized.

Copy link
Member

commented Dec 13, 2017

We can add option to disable it but it is rather low on our priority list for now. You are welcome to contribute such feature if you want.

I have created issue: #2672

@onitake

This comment has been minimized.

Copy link
Contributor Author

commented Dec 14, 2017

I tested both the ServiceAccount token and the namespace default token - both had full access to all cluster resources.
My suspicion is that apiserver is not doing any access control at all for service tokens when ABAC is active, or something is misconfigured.

I'll report back once I've dropped all leftovers from my ABAC setup. This will likely resolve the issue.
Thanks for your time!

@floreks

This comment has been minimized.

Copy link
Member

commented Dec 14, 2017

If this is indeed the case and ABAC somehow blocks RBAC from correctly authorizing request then you should report that on core repo. It is quite an important bug if this is not only configuration problem.

@onitake

This comment has been minimized.

Copy link
Contributor Author

commented May 31, 2018

I can confirm that proper ServiceAccount restrictions solve the issue - access restrictions now work as expected. However: With a fully restricted default token, skipping authentication is essentially useless. Disabling unauthenticated access and removing the SKIP button would improve the user experience.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.