dashboard
dashboard copied to clipboard
kubernetes
Set default namespace within request headers
What would you like to be added
To set the default header the same way as the Authorization Header (via a reverse proxy).
Why is this needed
I have multiple users which have no right to list namespaces so default namespace is automatically selected and can't be changed unless they know their default namespace and add a ?namespace=<name> to the URL.
So it would be really great to select their default namespace via a request header the same way as their auth token.
I don't think this is the way it should be done. That's what settings page is for. Global settings should be able to enforce default namespace. It will be much better way to achieve what you have described.
Does this setting already exists?
Well in my use-case users do not have rights to list namespaces so having the ability to set it for them would be nice.
If namespace that users have authority are written in context on kubeconfig like here and use it for logging in, we may be able to implement to specify namespace selector with it (also limit namespace selector and stop retrieving namespaces). Does it satisfy your use case? if so, I would consider to implement in #4522. @floreks HDYT?
Reading default context namespace from kubeconfig is ok, but it is a different feature IMHO.
I'd simply add defaultNamespace option to the global options. User could then change it to a different namespace and this namespace would be used for all users as default one then.
If namespace that users have authority are written in context on kubeconfig like here and use it for logging in, we may be able to implement to specify namespace selector with it (also limit namespace selector and stop retrieving namespaces). Does it satisfy your use case? if so, I would consider to implement in #4522.
Well I use Authorization header - so no kubeconfig. But this idea goes in the direction of a second header as described above.
I'd simply add
defaultNamespaceoption to the global options. User could then change it to a different namespace and this namespace would be used for all users as default one then.
This is definitely nice to have :+1:
But not 100% reflects my use-case as the accesstoken is generated for every user the same way as the namespace.
To make it more precise (very specific to my solution right now) I have the following URL <namespace-name>.dahsboard.example.com.
For this specific endpoint, an accesstoken is added giving access to (only) this namespace resources. If this URL is opened nothing happens (no rights to list namespaces) instead one has to copy the first part of the URL and add #?namespace=<ns-name>. To have the ability to just couple the accesstoken to a specific (default) namespace (e.g. headers) would solve this.
To make it more precise (very specific to my solution right now) I have the following URL
.dahsboard.example.com. For this specific endpoint, an accesstoken is added giving access to (only) this namespace resources. If this URL is opened nothing happens (no rights to list namespaces) instead one has to copy the first part of the URL and add #?namespace= . To have the ability to just couple the accesstoken to a specific (default) namespace (e.g. headers) would solve this.
This is a very specific use case indeed. Even if the user does not have privileges to list namespaces, it is still possible to change namespace directly from the Dashboard. You can click on the namespace selector and provide a custom namespace name and just hit enter. It will redirect the user to the namespace.
Choosing namespace based on header would only complicate logic and is not really needed. There is already query param that is responsible for selecting namespace. Configuring redirect rules to add path param to redirect link should be very similar to configuring it to add header instead.
I agree with @fentas this can be really useful feature. In my case I always need to provide creds to separated k8s dashboard which has limited to specific namespace. And when I do that for developer who's not familiar with k8s then I must explain why he gets errors after first login (without permission to default ns). From my experience it was confused a lot of people. I don't know may be we can add some extra args like defaultNamespace as global setting.
Thank you in advance.
I created a fork for now. And I understand why you don't want to move this to the backend - lots of work/change here. :feelsgood:
A reasonable solution would be to be able to set the default namespace via a cookie as this can be set as header (injected by proxy or anywhere else). Making this configurable by the user via setting would be a nice but optional addition then (for me at least).
This should be kind of a one-liner. :cake:
I don't know if I get the time (as we have a working solution right now) but I could try to bring this to a PR if wanted (the cookie part at least).
A cookie is only ok if the user would be the one who changes his own default namespace. If we want to enforce it for everyone, we need to move it to the global settings. Still, there is no way to enforce per-user namespace if the login view is enabled. The user would have to change it manually on his own.
If authorization header is used to omit the login view, enforcing different namespace is as simple as updating redirect URL and adding query param to the URL.
I don't know if we have to enforce it. I think it would be enough just to change the default namespace. I changed just the following line for that (for now)
https://github.com/kubernetes/dashboard/blob/master/src/app/frontend/index.config.ts#L33
we also need this feature in our organization. it will be helpful for users to directly land on their namespace rather than landing on default namespace.
After reading this I think I did not explain myself enough for the solution I imagine
I have a reverse proxy e.g. Istio I would do this
[browser] > mydashboard.example.com (virtual service) > dashboard
< ... header.add['set-cookie'] = namespace-X <
[browser] <(js)> loads the rights resources as namespace-X is set by VS
It would function the common pattern that you can set an authorization header per reverse proxy - here we would use it to set a default namespace per domain
header.add['set-cookie'] = namespace-X feels like a very hacky solution. I'd rather try to use existing options and simply redirect the user to dashboard.domain.com/#/overview?namespace=<namespace> instead of going to root path nad letting our router handle the redirect. This way you can open specific namespace directly on an overview page.
Feature would be cool... You have always to change the workspace :-(. I have almost none service in the default space, so this feature would be very handy...
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
There is a PR that will partially cover this. Next part will be added after.