Web UI for multiple clusters with OIDC

[gadzillos]

Hi guys, the best lamp for k8s there is

I've deployed InCluster headlamp via ingress with keycloack OIDC
Headlamp uses its own service account and users can login into UI via OIDC woth correct permission
for example: admin can do anything, developer has view/edit only on itheir namespace (via RBAC and OIDC groups)

But when I want to manage multiple cluster with singe ingress so I can access clusters and create projects - there is a problem
I provide volumemount for kubeconfig with service accounts for multiple clusters
And... OIDC simply dissapears - I can access clusters as if I am the service account without any login
the purpose of OIDC groups and RBAC dissapers

# -- Headlamp containers volume mounts
volumeMounts:
    - name: certificate
      mountPath: /etc/ssl/certs/ca.crt
      subPath: ca.crt
    - name: kubeconfig
      mountPath: /home/headlamp/.config/Headlamp/kubeconfigs/config
      subPath: kubeconfig

# -- Headlamp pod's volumes
volumes:
    - name: certificate
      secret:
        secretName: sso-tls-ca
        defaultMode: 420
    - name: kubeconfig
      secret:
        secretName: kubeconfig
        defaultMode: 0444 # need init container to set 0600 properly and get kubeconfig from vault instead

I understand correctly that Headlamp itself can't use OIDC login for a remote cluster and uses ServiceAccount (although I've tried ungodly setup by adding kubectl and oidc-login to the dockerfile and rebuilding image)
I guess I could provide admin ServiceAccount for clusters (which is against audit policies - oidc is forced) but such setup still doesnt function as OIDC for users

When you provide a kubeconfig with a hardcoded ServiceAccount token for remote clusters, Headlamp uses those credentials directly from the backend. Since the backend already has valid credentials (the ServiceAccount token), it doesn't trigger a "Sign In" flow for those clusters. Consequently, the user is effectively "logged in" as that ServiceAccount, bypassing individual RBAC.

Maybe I need Service Account with a permission impersonate-user impersonate-group?

I'm sure someone was able to keep OIDC groups permissions for users with multiple clusters UI

[gadzillos]

Found similar issue

#4077

[achalcipher]

Hi @gadzillos, your assessment of the identity bypass is correct. When Headlamp uses a static ServiceAccount token for remote clusters, the API server sees the ServiceAccount, not the OIDC user.

Technical Feasibility of Impersonation: Your proposal to use impersonate-user and impersonate-group headers is the standard Kubernetes architectural solution for this. However, for this to work in Headlamp, the backend proxy must be explicitly configured to extract the OIDC user identity and inject these headers into the proxied request.

Current Implementation Gaps:

Identity Propagation: We need to verify if the Headlamp backend proxy logic currently supports dynamic impersonation header injection based on the authenticated OIDC session.

Security Scoping: Granting impersonate permissions to the Headlamp ServiceAccount on remote clusters is powerful (effectively making it a proxy for any user). It is recommended to scope the ClusterRole to specific groups or users to maintain a least-privilege stance.

Next Steps: I am currently contributing to the plugin and OIDC areas of the project. I'll investigate the backend proxy code to see if we can implement a 'User Impersonation Toggle' for multi-cluster configurations that automatically handles this header delegation

[tevaum]

@achalcipher, do you have any ETA or plans we can follow to track the implementation progress?

[achalcipher]

Yes Sir, I do have my plans and ETA to do all these things and align them smoothly

[tevaum]

🙌 glad to hear that! Let me know if you need help. I'm willing to put some hands on to get this working 🙈

[minimalmattt]

I understand correctly that Headlamp itself can't use OIDC login for a remote cluster and uses ServiceAccount (although I've tried ungodly setup by adding kubectl and oidc-login to the dockerfile and rebuilding image)

@gadzillos This is not completely correct, headlamp can use OIDC for remote clusters, you just need to adjust the kubeconfig you provide.

This is an example of how I use it in my clusters:

apiVersion: v1
clusters:
- cluster:
    server: https://apiserver-url.example.com:6443
  name: oidc-demo
contexts:
- context:
    cluster: oidc-demo
    user: oidc-user
  name: default-context
current-context: default-context
kind: Config
preferences: {}
users:
- name: oidc-user
  user:
    auth-provider:
      name: oidc
      config:
        idp-issuer-url: "https://your-idp-url.example.com"
        client-id: "your-client-id"
        client-secret: "your-client-secret"

I omitted the certificate data for the cluster, but everything else should work when adapting an existing kubeconfig.

If you need help feel free to drop me a message

[gadzillos]

Hi, thanks for the tip

Are you using headlmap desktop app or headlamp web (helm chart in k8s)?
Because OIDC is not supposed to work for web version and multiple clusters - OIDC prompts user browser interactively

so for single in-cluster oidc - it works (single ingress - single cluster)
one web ui with multiple cluster (single helm and ingress - 20+ clusters via oidc) - doesn't work even with kubeconfig adjusted to oidc - it renders in ui but doesn't follow SSO process to access remote clusters

You was able to overcome this specific case I would be gratefull for clarification

For now my solution is Dashy web dashboard with entire k8s cluster fleet - one ingress/url per cluster with SSO (oidc)

[minimalmattt]

It's the helm deployment, and I can confirm everything works correctly.

I think that by setting auth-provider in the kubeconfig headlamp acts as the oidc client, like kubectl-oidc would in the CLI.

So when I select the remote cluster I get the standard headlamp OIDC login prompt then my token is sent to the API server of the remote cluster and I can access it no problem.

[gadzillos]

Thank you - I will retest it comprehensively
maybe Headlamp implemented that - initially same config didn't work

[harse]

I would like to confirm @minimalmattt 's latest comment regarding the multi-cluster setup.

My setup:

• Headlamp: inCluster: false configuration
• Kubeconfig: mounting a kubeconfig file from a K8s secret that contains 10+ clusters
• Authentication: all clusters use OIDC login
• Secret injection: the K8s secret is dynamically synchronized from HashiCorp Vault using the External Secrets Operator (ESO)

This approach works seamlessly for managing multiple remote clusters through a single Headlamp instance when inCluster is disabled, and it confirms that Headlamp handles a multi-context kubeconfig provided via a mounted volume correctly.

[Naga15]

Following up on this discussion — I've been running into the exact pain @gadzillos described (single ingress, mounted multi-cluster kubeconfig, OIDC re-login per cluster) and I want to propose a concrete design before opening a PR.

There are two viable approaches; I'd like maintainer input on which you'd accept.

Approach A — OIDC token broadcast (what I've prototyped)

Idea: After a successful OIDC login on cluster X, if other kubeconfig contexts use OIDC with the same idp-issuer-url + client-id, set the auth cookie for those clusters too. One login → all clusters that trust the same IdP app.

Why: Most real deployments register one OIDC app for "the platform" and have every kube-apiserver trust it. The token a user receives is valid against every cluster — Headlamp just needs to know it should cache it per-cluster instead of forcing re-login.

Precondition (validated at runtime, not at config time): IdpIssuerURL and ClientID must match across contexts. If they don't, skip silently and log at info. (The aud claim defaults to client_id under standard OIDC, so matching those two is sufficient unless an operator has configured --oidc-extra-audience on the apiserver — that caveat goes in the PR description.)

Opt-in flag: --oidc-use-token-broadcast (default false) — follows the same naming pattern as --oidc-use-cookie from #4487.

Scope of change: ~50 lines in backend/cmd/headlamp.go, plus 9 unit tests covering matching/mismatched issuer, mismatched client-id, non-OIDC targets, source-without-OIDC, mixed contexts, and self-exclusion. Touches only the post-login path; refresh broadcast is a follow-up PR.

Trade-offs:

• ✅ No additional RBAC required on remote clusters
• ✅ Preserves per-user identity (each user still authenticates as themselves)
• ✅ Matches the architecture most teams already deploy
• ⚠️ Requires matching IdP config across clusters — explicit precondition
• ⚠️ Refresh-token state per cluster handled lazily as a follow-up

Approach B — Impersonation headers

Idea: Headlamp's SA on each remote cluster gets impersonate permissions on users/groups. Backend extracts OIDC identity from the user's session and injects Impersonate-User / Impersonate-Group headers into proxied requests.

Trade-offs:

• ✅ Works even when remote clusters don't trust the IdP directly
• ❌ Requires granting impersonate (powerful — effectively user-spoofing capability) to Headlamp SA on every cluster
• ❌ Larger surface change (every proxied request, not just login)
• ❌ Audit trails on the apiserver show the SA as the actor unless extra headers are set

My recommendation

Approach A is the right default for the common deployment shape; Approach B is the right escape hatch for orgs that can't (or won't) configure IdP trust on every cluster. They're not mutually exclusive — A should land first because it's smaller and unblocks the majority case.

Open questions for maintainers

1. Do you agree A is acceptable as a first PR (behind a flag, default off)?
2. Refresh-token divergence: when the source cluster refreshes, only the initial broadcast cookie was set — the per-cluster refresh state isn't touched. Plan is to scope this PR to initial login only and submit refresh broadcast as a follow-up. Any objection?
3. Naming: --oidc-use-token-broadcast — better name?
4. Testing approach — I have unit tests modeled on headlamp_test.go style; for E2E I'm running a local kind × 2 + Keycloak setup. Happy to mirror an existing test pattern if there's a preferred one.

I have a working prototype already (in my fork) that I can clean up and PR within a week if A sounds right. Happy to iterate on the design here first.

[Naga15]

Opened #5929 as a draft implementing Approach A (opt-in --oidc-use-token-broadcast flag, default false). Not asking for merge yet — wanted to give maintainers something concrete to react to rather than the abstract design questions above. Happy to convert this to a reference and pivot to Approach B (impersonation) if that is the preferred direction.