joaquimrocha
commented
1 month ago Hi @mlbiam , while I'd like to understand what this implies for the project (what dependencies it brings, what we have to maintain, does UX change at all?), in principle we agree with having ways of deploying Headlamp that improve security or validate different use-cases. So I am happy to work with you to land this.
I'd like to integrate HeadLamp into OpenUnison (https://openunison.github.io), but I'm running into a few issues:
OIDC doesn't support self signed CA - Going through the instructions for OIDC ignores trusting a certificate. This makes OIDC mostly useless for identity prociders that aren't publicly hosted, like OpenUnison, in an enterprise environment which usually has its own internal CA.
OIDC uses a client secret - Kubernetes will require the audience to be the same for kubectl and your cluster, but that means that using client secret means all kubectl users also need a client secret (this is technically not true with 1.30+, but additional token types will take quite some time to be available, if ever, to commercial distributions and managed clusters). Distributing a client secret is an anti pattern for kubectl use because it's now a shared password and will need to be treated as such by more enterprise security policies.
OIDC doesn't support impersonation - There's no way to integrate incluster headlamp with a managed cluster.
For these reasons, I'd like to propose a reverse proxy approach for in-cluster, similar to how the Kubernetes Dashboard, Kiali (Istio Dashboard), and the Tekton Dashboard all work. A revesrse proxy architecture allows a revese proxy, such as OpenUnison or OAuth2 proxy, to inject a token, and potentially impersonation headers, into each request. It then becomes the responsibility of the reverse proxy to keep the authentication token (and impersonation headers) up to date.
I'm happy to contribute code to make this work, but I want to make sure the project is willing to integrate this feature before I dive into doing the work.