Hi all,
I am a contributor to the Kubeflow project, which is a machine learning
platform built on top of Kubernetes.
Recently, we (Arrikto) implemented a reference architecture for OIDC
Authentication in Kubeflow.
More details can be found in this article:
https://journal.arrikto.com/kubeflow-authentication-with-istio-dex-5eafdf...
After 3 months of testing this setup with users, we gathered feedback from
users operating in onprem, airgapped environments which lead to the
following use case:
We want to use an OIDC authenticating proxy for securing an on-prem,
airgapped Kubernetes Cluster.
For an OIDC Provider, we use Dex, which lives in the same cluster and
connects with LDAP.
Keycloak Gatekeeper is a great project that has caught our attention and we
would
love to use it to cover our use-case.
We have the following user requirements:
- Don't make any requests that exit and reenter the cluster. This means
that the OIDC Client should
talk to the OIDC Provider using its internal address.
- Work behind any origin URL. This lets users use kubernetes port-forward
to debug issues and work behind
a proxy.
To solve these requirements we came up with the following:
- Use the OIDC Provider's internal address for the {discovery, jwks, token,
userinfo}_endpoint.
This means the OIDC Client won't make a request to a public address that
would exit and
reenter the cluster.
- Use relative URLs for the authorization_endpoint and redirect_uri. We
know that our OIDC Client and
OIDC Provider live behind the same origin, so we can redirect from one to
the other using relative
URLs.
We haven't found a way to set up Gatekeeper to support this use-case.
I would greatly appreciate it if you could help me understand if this is a
valid use-case for
Gatekeeper to support.
If yes, I'd love to contribute to it and if not, I'd like to understand why.
Thanks in advance,
Yannis Zarkadas