keycloak-operator contribution reconcile updates and more

110 views
Skip to first unread message

Raffael Sahli

unread,
Sep 29, 2021, 11:28:34 AM9/29/21
to Keycloak Dev

Hi

I am currently implementing update reconciliation for KeycloakRealm as well as other stuff which we require to manage multiple keycloaks. Question is are you interested in this, if so I will structure a couple of prs as well as tests.
I've read some things about Keycloak x operator here so not sure thats why I'm asking first before adding more things.

preview here: https://github.com/keycloak/keycloak-operator/compare/master...DoodleScheduling:identity-provider?expand=1

The following things are done:

* Remove the unmanaged condition, there is no need for this as it works perfectly with external keycloaks. The only place where the unmanaged field is required is in the Keycloak instance to not roll it out. There is no need to prevent a realm to be reconciled.
* Adding many missing fields to KeycloakRealm
* Adding suspend reconciliation to all Keycloak* resources
* The realm now gets updated if the realm field applyUpdates is set to true to be backwards compatible though from a k8s perspective there should be no such field and should be removed in a newer api version.
* I've implemented top level realm updates as well clientScopes, will add other sub level resources too.
* A new KeycloakIdentityProvider crd is introduced. Its actually the only one which makes sense. It would be unreasonable to create crds for each sub level resource of a Realm. In the case of KeycloakIdentityProvider it can refer to a k8s secret to load in secret information including especially the clientSecret. That way secrets can be kept as secrets from a k8s point of view. Everything else will be part of the realm reconciliation.

Cheers
Raffael

Václav Muzikář

unread,
Oct 14, 2021, 6:20:13 AM10/14/21
to Raffael Sahli, Keycloak Dev
Hello,
thank you for your proposal! It sounds interesting, but as you mentioned – we'd like to take a bit different approach around managing resources via the new operator in Keycloak.X. More on that soon.

Please see my responses inline below.

On Wed, 29 Sept 2021 at 17:28, 'Raffael Sahli' via Keycloak Dev <keyclo...@googlegroups.com> wrote:

Hi

I am currently implementing update reconciliation for KeycloakRealm as well as other stuff which we require to manage multiple keycloaks. Question is are you interested in this, if so I will structure a couple of prs as well as tests.
I've read some things about Keycloak x operator here so not sure thats why I'm asking first before adding more things.

preview here: https://github.com/keycloak/keycloak-operator/compare/master...DoodleScheduling:identity-provider?expand=1

The following things are done:

* Remove the unmanaged condition, there is no need for this as it works perfectly with external keycloaks. The only place where the unmanaged field is required is in the Keycloak instance to not roll it out. There is no need to prevent a realm to be reconciled.
It was decided in the past that we won't support managing realms in external Keycloaks and I don't think we want to change it at the moment.
* Adding many missing fields to KeycloakRealm
+1 
* Adding suspend reconciliation to all Keycloak* resources
 Could you please elaborate on this? You mean that some CRs would be used only for initial creation of a resource but would not be reconciled any more, similarly to how Realm CRs now behave?
* The realm now gets updated if the realm field applyUpdates is set to true to be backwards compatible though from a k8s perspective there should be no such field and should be removed in a newer api version.
We do not want to reconcile the realm after it was created, if that is the suggested change. It'd be really fragile and hard to implement this correctly, introducing a lot of complexity to the operator.
* I've implemented top level realm updates as well clientScopes, will add other sub level resources too.
 Could you please elaborate? We already support client scopes in Realm CRD.
* A new KeycloakIdentityProvider crd is introduced. Its actually the only one which makes sense. It would be unreasonable to create crds for each sub level resource of a Realm. In the case of KeycloakIdentityProvider it can refer to a k8s secret to load in secret information including especially the clientSecret. That way secrets can be kept as secrets from a k8s point of view. Everything else will be part of the realm reconciliation.
We currently do not want to add any new CRDs. IdPs can be added through the Realm CRD. 

Cheers
Raffael

--
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/5dbfff7d-64dd-4883-9501-7c9269875e27n%40googlegroups.com.


--
Václav Muzikář
Senior Software Engineer
Keycloak / Red Hat Single Sign-On
Red Hat Czech s.r.o.
Reply all
Reply to author
Forward
0 new messages