Hi @andreaTP

the new operator does support secret injection in most of the relevant places, would mind checking if anything is missing from your perspective?

How would this actually work? There's no documentation about it. I'm referring to the feature in the legacy operator where, when you create a KeycloakClient CR, in addition to creating the client resource within Keycloak itself, it also creates a Kubernetes Secret object with the credentials for that client, consumable from various Kubernetes workloads. Per the documentation for the legacy operator:

After a client is created, the Operator creates a Secret containing the Client ID and the client’s secret using the following naming pattern: keycloak-client-secret-<custom resource name>

Does this functionality exist in the new operator? If so, I don't see that documented anywhere. With no KeycloakClient CR, how does it know what namespace to put the Secret object in? Does it just put it in the same namespace as the Keycloak installation itself?

Currently, the new operator supports only full Realm bulk import, I'm confident that you can migrate the client CRs to a realm CR (containing the clients). Please, try it out, and report if you face any technical limitations.

As stated by @jbpin in another thread, this isn't really a usable solution. I'm not looking to import a realm as a one-time operation, I'm looking to manage the realm using Kubernetes CRs (something you can do with the legacy operator). My question at this point is, if I start by using the legacy operator, will I eventually be able to migrate that configuration into the new operator and keep managing it the same way, or am I better off just not using Keycloak Operator at all until 20.0 is GA, to avoid dealing with a messy, painful migration down the line?