headlamp
headlamp copied to clipboard
Feature Request: Support auto load kubeconfig when deploy under In-Cluster mode.
RT.
Wonder to have auto-login feature when installed under In-Cluster mode, which means that we can add serviceAccountName: xxx
to led pod have sa to do things.
So with this method, cluster witch have multi users, can direct access into headlamp and start using it.
(Maybe we also need to spec some env to set default ns bound with sa).
Hi @zzjin , thanks for opening this issue. Just to be sure we understand correctly, you want to run Headlamp with a specific SA token, instead of having every user have to use their own SA token, is that correct?
Headlamp does not require any token to be run since it's the user who should have a role in the cluster, not the UI. I believe that if you run Headlamp as a service though and pass it a kubeconfig with a client certificate, then you'll be able to get anyone to access the cluster through Headlamp. In this case, you should make sure that you have secured the access to Headlamp itself, because Headlamp has no concept of authentication on its own.
No, exactly no for all user use one sa token.
Instead, every user can apply Headlamp(deploy+svc+ingress) under there own namespace(will surely consume more resources at cluster level, but not the feature quest discussion here), so each Headlamp instance at specific namespace can mount(read) namespace user's sa token.
Another way to archive this goal is, cluster admin deploy one Headlamp instance(without any privileges), and when namespace user open the Headlamp ingress route, wrap ingress route and do some api(or post auth?) call to inject user's sa token into Headlamp, to prevent user needs to copy and paste token manually.
cc/ @knrt10 in case you understand better than me what's being requested here (I'm still confused).
Any update needed here?
Let me explain more:
With our service, we provide one scaleable cluster, witch multiple users shares same gateways/ volume resources/prometheus
, and each user have limited access any other resources to their given namespace.
We also provide a simple frontend page, with one click method, user can apply some template yaml(including ingress with random sub-domain host we provided), and can simply delete this applied yaml(s) with just another click.
In this case, each of our user can apply "1 headlamp deploy + 1 svc + 1 ingress(random host, with or without basic auth)"
template yaml at our frontend with one click, and then use headlamp's beautiful web ui to manage their namespace's resources, and can delete these 3 deploys when they are done.
So the risk leaks can be little to none since the access from web url is random-ed and not persist, and we also provide timeout method to auto delete these yaml(s).
With the above explanation,headlamp can be deployed under user's namespace, and user get one random host ingress to access their headlamp, and users just need to copy&paste their kubeconfig token to auth into headlamp.
The feature requested here is, if we want the user experience better, we can mount user's kubeconfig into the headlamp pod(already supported by setting serviceAccountName
in headlamp deloyment yaml template), k8s will automatic put sa's config file into default location: ~/.kube/config
and then we need to config headlamp to read and parse this default config file to auto-login into it.