Dashboard: Provide Global admin settings for dashboard config

[FrenchBen]

Why is this needed

When a cluster is used by users with limited access, it is desirable to have a Dashboard view which limits similar resources for the user.

User Scenario:
As a user of a cluster, I am given access to 3 namespaces: dev, test, prod.
When I login to the Kube Dashboard, I should see only that which I can interact with.

In the above scenario, a user logged in with their credentials, and limited access (RBAC), would not be able to list all namespaces in the cluster (list all namespaces would fail). The user should be have matching settings, where an Admin could provide a pre-defined list of namespaces / resources that a user would have access to.

Comments

Discussion with @floreks in PR #5390

Global settings can be modified usually only by admins. They are available on the top of settings view. Settings are saved in a ConfigMap. I think we should have some kind of field (chip list?) that allows us to define multiple values (namespaces) and delete specific entries if needed. By default it would be a list of fallback namespaces that the user would see in case namespace list request fails. Then we could add a switch below that "list field" to control if defined list of namespaces should always override a list of namespaces available in namespace selector. This means that even if the user can list all namespaces, only the ones defined on the list would be available, other namespaces would have to be entered manually.

Further Improvements

Although the above would provide some settings that could come handy, there is a greater desire to see this implemented as a core RBAC feature of kubernetes/kubernetes, where a user doing a lookup on all resources would be given resources for which they have access to.

Using the above user scenario, a user should be able to list namespaces via the cli kubectl get namespaces, and for the APi server to return the only namespaces the user has access to: dev, test, prod

[floreks]

In the above scenario, a user logged in with their credentials, and limited access (RBAC), would not be able to list all namespaces in the cluster (list all namespaces would fail). The user should be have matching settings, where an Admin could provide a pre-defined list of namespaces / resources that a user would have access to.

Important thing here is that there is no concept of user in Kubernetes API and it will not be possible to define per-user list of namespaces. This list would be global for all users.

Although the above would provide some settings that could come handy, there is a greater desire to see this implemented as a core RBAC feature of kubernetes/kubernetes, where a user doing a lookup on all resources would be given resources for which they have access to.

I've seen requests for such feature in the core already. It would be best if API could actually do this work for us.

I'd also add 1 more thing here. Add option to select default namespace that should be used instead of currently hardcoded default. This actually could be saved in cookies and every user could define it.

[FrenchBen]

Important thing here is that there is no concept of user in Kubernetes API and it will not be possible to define per-user list of namespaces. This list would be global for all users.

For my use case, it would be ok, since all users would be part of the same team (they share the namespaces & good 1st step). For a proper multi-tenant cluster, it wouldn't.

It would be best if API could actually do this work for us.

Agreed. Having this concept as a 1st class citizen in API would simplify things in the dashboard.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[floreks]

/lifecycle frozen

[FrenchBen]

it's on my list to create a POC associated with this - The big challenge is the RBAC tie-in being available via the API