Keycloak-Operator introducing more sync options

[Sebastian Łaskawiec]

Dear all,

Keycloak Operator uses a one-way sync for Realms, Clients and Users. The one way sync has been implemented on purpose. Without this approach, any change made manually in the Admin UI would be overridden.

We recently received an interesting Pull Request [1] that introduced a new field into the Keycloak CR called `unmanaged`. If the field was changed to `managed` with a type of string, this could open the door for implementing other syncing mechanisms, such as `create-only` or `always-update`. Leaving this set to `create-only` for Realms, Clients and Users would make it behavioral backwards compatible.

More information might be found here [2].

What do you think about this?

Thanks,

Sebastian

[1] https://github.com/keycloak/keycloak-operator/pull/247/files

[2] https://issues.redhat.com/browse/KEYCLOAK-15142

[Stian Thorgersen]

-1 Any additional syncing logic needs to be provided/supported by KC itself, not by the Operator. We want the Operator to be a thin orchestration/wiring layer.

--
You received this message because you are subscribed to the Google Groups "Keycloak Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to keycloak-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-dev/175ea633-ec03-4b45-8cd5-87560f86fbfbn%40googlegroups.com.

[Sebastian Łaskawiec]

Hey Stian,

I believe there's some misunderstanding here. When you create a KeycloakRealm CR for example, the Operator picks it up and creates it in Keycloak. Once it's done, it never touches it again. The proposal here is to introduce an option to change this behavior and invoke the update once in a while. Such an update will override whatever you set manually in via the Admin UI and that's essentially a goal here.

Thanks,

Sebastian

--

Sebastian Łaskawiec

[Stian Thorgersen]

That's a problem as it's just a strange hack, rather than a proper story, and doesn't really have any real practical use in that form.

I'm not against the idea of syncing between KC and CRs in general, but rather against doing it as a half-baked solution.

[Sebastian Łaskawiec]

+1 for providing us user story behind this before accepting the JIRA for development.

--

Sebastian Łaskawiec

[Sebastian Łaskawiec]

I went ahead and added additional syncing options for KeycloakRealm, KeycloakClient and KeycloakUser in my Service Accounts PR: https://github.com/keycloak/keycloak-operator/pull/244

It's worth to mention that I renamed the "unmanaged" field to "managed" and changed its type to string. My PR introduces the support for "auto-generated", "false" and anything else (which is assumed to be managed). In the future we can add more options.

[Jens Reimann]

Looks like I just ran into the same issue: https://issues.redhat.com/browse/KEYCLOAK-17094

I want to do gitops style deployments. This means I only edit the YAML files, and don't care (don't want) to persist any changes coming from the server.

I also don't think it would work to "kubectl delete" the realm, as that would delete all the users.

I would be fine having some kind of "spec" field, or annotation, which opts-out of the current limitation. So maybe ".spec.overwriteServerConfig: true" …

[Trevor Loranger]

Sebastian,

Do you mind providing more details on the current "one-way sync" approach? I've only seen this briefly mentioned in the docs. We are observing behavior from the Keycloak Operator that contradicts your earlier statement "Without this approach, any change made manually in the Admin UI would be overridden." whereby manual edits to a client in the Admin UI, which is tied to a KeycloakClient CRD, are eventually overwritten. We think there might be a regression if your statement is still the intended behavior.

Specifically, we've been adding AuthZ settings manually to our client in the Admin UI, since my pull request isn't merged yet, and is eventually erased by the Operator (v. 12.0.4). Also, we are pretty confident no updates are being applied to the client CRD.

Thank you,

Trevor Loranger

[DEShown]

Getting a Realm that uses a KeycloakRealm object as configuration source of truth is highly valuable for anyone doing a GitOps approach that implements configuration as code. There's an open JIRA ticket about this, too: https://issues.redhat.com/browse/KEYCLOAK-15142

Trevor, currently KeycloakRealms are the only object that the operator does not do any sync on. KeycloakClients and KeycloakUsers are both synced.