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

[Sebastian Laskawiec]

Yes, you can interpret it this way. Our proposal seems very flexible in
this matter.

On Mon, Oct 7, 2019 at 2:48 PM Pedro Igor Silva <psilva at redhat.com> wrote:

> This approach makes a lot of sense to me.
>
> Just one comment about:
>
> "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."
>
> Isn't this related to SaaS/namespace-based multi-tenancy in Kubernetes use
> cases where each namespace is a tenant and may have its own Keycloak and
> set of CRDs?
>
> On Mon, Oct 7, 2019 at 8:10 AM Sebastian Laskawiec <slaskawi at redhat.com>
> wrote:
>
>> 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
>> >
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>