RFD / Deprecation of Gangway / finding a Replacement

[eyenx]

Gangway is no longer mantained by VMWARE:

VMware has ended active development of this project, this repository will no longer be updated.

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.

[eyenx]

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.

[tongpu]

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

[hairmare]

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.

[hairmare]

maybe this fork of jetstack/kube-oidc-proxy is something to keep an eye on

[eyenx]

dex-k8s-authenticator is looking for new owners

https://github.com/mintel/dex-k8s-authenticator/issues/194

[hairmare]

another option to look into is https://www.paralus.io/ (a CNCF sandbox project)

[cfi2017]

I'd like to pick up this discussion again, following the deprecation of Gangway ( #1366 ).

I like the idea of kubelogin, but it's a slightly different concept:

• We need higher level access to install it as we need to be able to change API server flags
• I don't know if it would support multiple OIDC providers (we may be able to get something to work using dex as the IDP for the API and then adding multiple IDPs to dex, but that has the drawback that we're building a chicken-egg solution).

[hairmare]

Ah int128/kubelogin, i've stopped counting the amounts of time where we installed that instead of https://github.com/Azure/kubelogin by mistake.

if we end up putting standardizing affected env on it, i'll try to ensure that we only install it using krew where it's called oidc-login 😁