[keycloak-user] Keycloak Gatekeeper: Support Relative/Internal URLs for Airgapped Environments

Yannis Zarkadas yanniszark at arrikto.com
Tue Oct 8 13:33:23 EDT 2019


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-5eafdfac4782

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


More information about the keycloak-user mailing list