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

Bruno Oliveira bruno at abstractj.org
Fri Oct 25 13:45:28 EDT 2019


HI Yannis,

If you would like to propose a new feature to Gatekeeper, the
recommended way is to start a design proposal
https://github.com/keycloak/keycloak-community/tree/master/design.
Reading the whole use case you described, it seems very specific to
your scenario, but I could be wrong.
I'm not familiar with Kubeflow, so maybe if you break it into smaller
features and add more details, that would help others to understand
what you would like to implement.

On Tue, Oct 8, 2019 at 6:51 PM Yannis Zarkadas <yanniszark at arrikto.com> wrote:
>
> 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
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user



-- 
- abstractj


More information about the keycloak-user mailing list