[keycloak-dev] [Keycloak Operator] Keycloak and KeycloakRealm CRDs

[Sebastian Laskawiec]

Yes, I'm very sorry... Gmail seems to ignore my pasted diagram. I'm not
exactly sure why.

On Mon, Oct 7, 2019 at 12:52 PM Bruno Oliveira <bruno at abstractj.org> wrote:

> Sebastian made a nice diagram, which may be helpful:
>
>
> https://docs.google.com/document/d/18w9ZSOVN0C0KEqBICpvsKWFPzobQ9KUEcB18QE6eos0/edit?usp=sharing
>
>
> On Mon, Oct 7, 2019 at 4:48 AM Sebastian Laskawiec <slaskawi at redhat.com>
> wrote:
> >
> > Hey,
> >
> > Keycloak Operator in its initial approach will handle two types of
> > resources - Keycloak and KeycloakRealm CRDs. The first one is responsible
> > for spinning up a Keycloak instance, whereas the second one contains a
> > Realm definition. There are many ways of combining all things together,
> so
> > we’d like to bring everyone on the same page with our latest proposal:
> >
> >
> > The idea is for theKeycloak Operator to watch a single namespace for
> > Keycloak CRs and multiple namespaces for KeycloakRealm CRs. Once a
> Keycloak
> > CR is created in the same namespace as the Operator, the Operator will
> > create a Keycloak installation. At the same time, we’d like to let users
> in
> > different namespaces create Realms. This means, that a KeycloakRealm CRs
> > need to point to a specific Keycloak CR. This mapping will be achieved by
> > using Label Selectors: the Keycloak CR specifies one or more set based
> > selectors  that allow to express which labels have to be present on a
> > KeycloakRealm in order to be selected by the Operator. A simple example
> > could look like this:
> >
> > *Keycloak CR:*
> > realmLabelSelector:
> >   matchLabels:
> >     app: keycloak
> >
> > The Operator would then only import Keycloak Realms that have a label app
> > with the value keycloak.
> >
> > This approach enables the following use cases:
> > - Keycloak cluster administrators can be easily separated by Realm
> > administrators using Namespaces. In our example, User 1 and 2 don’t have
> > access to the Keycloak installation itself. The Operator creates Realms
> on
> > their behalf.
> > - Users won’t be able to break other’s Realms. In our example, User 1
> and 2
> > don’t have access to Namespace “test2”, and therefore, can not break
> Realm
> > “test2”.
> > - It is perfectly fine to put everything in a single namespace (Keycloak
> > and KeycloakRealm CRs). This type of installation might be used by
> smaller
> > organizations.
> > - We will allow only 1 Keycloak installation per Namespace. It is
> possible
> > to use multiple installations per Namespace but we couldn’t come up with
> a
> > logical use case for that. We decided to discourage users from this type
> of
> > installations and they might complicate things in the future.
> > - Multiple keycloak operators could be running in a cluster. The
> selectors
> > on the KeycloakRealm determine which Keycloak instance the realm is
> created
> > in.
> >
> > Please do not hesitate to ask any questions and if you have any thoughts
> in
> > your mind, please let us know.
> >
> > Thanks,
> > David, Peter, Bruno and Sebastian
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> --
> - abstractj
>