Open eyenx opened 2 years ago
From my point of view:
The Dex <> Gangway way was mainly introduced in this charts due to SUSE CaaSP relying on it, as we knew it was working well there.
I used dex-k8s-authenticator on a different customer's cluster. They are still using it now and it works well. It also works without adding additional SESSIONKEY's as secrets which makes it easier to deploy / mantain.
Probably we should approach this problem from two sides. For me as someone who has access to multiple clusters it would be beneficial to have a configuration that is compatible with kubelogin/oidc-login, because it would allow me to switch between clusters without having to open a web ui and integrate the shown configuration into my local kubeconfig.
But for other users (e.g. our customers) that only visit a single cluster a web UI might be beneficial. Dex would allow us to configure both OIDC clients at the same time allowing for both use cases.
If we decide to go down the route of kubelogin we should probably review the Dex documentation with regards to public clients
But for other users (e.g. our customers) that only visit a single cluster a web UI might be beneficial.
our customers rarely visit one single env, usually they have multiple envs like (dev, test, prod) as well.
maybe this fork of jetstack/kube-oidc-proxy is something to keep an eye on
dex-k8s-authenticator is looking for new owners
another option to look into is https://www.paralus.io/ (a CNCF sandbox project)
Gangway is no longer mantained by VMWARE:
We should find a replacement for it.
in #445 dex-k8s-authenticator was added to our security-apps chart.
This issue is for us to discuss a possible replacement by dex-k8s-authenticator or even finding a new candidate.