keycloak-config-cli and keycloak-operator

[todeb]

Hi,

What do you think about keycloak operator? Seems that it is also capable at importing configuration. https://operatorhub.io/operator/keycloak-operator

Do you see any advantage of operator over config cli and vice versa on managing configurations?

[jkroepke]

HI,

as I cloud native fan, I would prefer the keycloak-operator over keycloak-config-cli.

But weeks ago I tried to setup the keycloak-operator including the OLM stack. Unlike operator like prometheus operator, the keycloak operator looks quite complex. I was not able to start it.

Do you see any advantage of operator

Speaking for all operators: Yes. You could use tools like helm or even kubectl apply to configure any type of application, in this example: keycloak. It might be extrem developer friends, if you company has something like a platform team which could manage such operator.

Thanks for asking this question. I will look into it how I could keycloak-config-cli wrap in an operator.

[jkroepke]

I'm going to close this issue. I tried something with the java operator sdk, but I'm not able to run config-cli with-in the operator loop.

[xRodney]

Hello again @jkroepke ,

I'd like to reopen this discussion about keycloak-config-cli operator.

I would like to provide a few arguments why I think this mode would absolutely fantastic to have:

1. It's still keyloak-config-cli with years of accumulated knowledge that we all love Yes, there is the keycloak-operator written in Go, and it is now being replaced with a new one written in Java. These two operators can install Keycloak for us and have rudimentary support for realm configuration, too, but that is very incomplete. Last time I checked, the import was only one-time, with no support for updates. Not to speak about missing features. Simply put, keycloak-config-cli is light years ahead.

2. Keycloak-config-cli in operator mode would allow new features For example, realm rename can now be possible.

3. Keycloak-config-cli realm can be broken down into sub-imports. In our company, Keycloak and keycloak realms are versioned in a git repo, containing among other things a helm chart. We also develop other OIDC-capable applications, each versioned in their own git repos, with their own helm charts. These applications require a client configured in the realm, and quite often also other entities: client roles, scopes and scope mappings, some even identity providers. This causes coupling - a developer must not only make changes to the component they are working on, but also to the realm. They also need to deploy two apps instead of one. Additionally, some things like redirect URIs are hard to maintain consistently. How better it would be it they could just add a new k8s resource, such as Client.keycloak-config-cli.adorsys.com/v1 to their helm charts, next to their Pods, Services and Ingresses and have it just work?

I realize that you already tried that and hit a roadblock. But since then, Redhat released a new major version of their java-operator-sdk, so I tried to pick up you branch, upgrade it and make it work. You can check out my changes here: https://github.com/xRodney/keycloak-config-cli/tree/operator .

It is just a very early PoC, barely working, missing features, untested, badly written and clearly not PR-ready at all. But, it can start in operator mode and it create and upgrade a realm (even rename).

How to test

./mvnw spring-boot:run -Dspring-boot.run.arguments=--spring.profiles.active=operator      # It will error out, but before that it will generate CRD yamls in the root folder
kubectl apply -f keycloakconfigs.keycloak-config-cli.adorsys.com-v1.yml                   # Let's apply the CRDS
./mvnw spring-boot:run -Dspring-boot.run.arguments=--spring.profiles.active=operator      # Now it will keep operating...

Now you need to create a realm to import. A good start is a file stored under k8s/realm.yaml. A the very least, you need to update the keycloakConnection section:

• url to point to your keycloak (for Wildfly versions, including the /auth suffix)
• credentialSecret: a secret containing password for user admin.
  • A sample secret can be created like this: kubectl create secret generic global-keycloak --from-literal=KEYCLOAK_PASSWORD=test1234

The whole realm subsection is (plus minus a few quirks) the complete import file in yaml format that keycloak-config-cli understands.

To create/update the realm, run a separate terminal window:

kubectl apply -f k8s/realm.yaml

We can even delete the realm, and it will be deleted from Keycloak:

kubectl delete keycloakconfig test-realm

With this in mind, I would like to ask if you could reconsider integrating the operator mode into keycloak-config-cli. If not, I could still imagine having this as a separate standalone project. Some changes would still be needed to keycloak-config-cli, for it to be includable as a library, but these would be relatively small.

What do you think?

[Bessonov]

TBH, I don't see any value which an operator can bring to the table for kcc.

Operators make total sense for workloads with a lifecycle. Like unattended load watching and scaling databases beside HPA. But kcc is one-shot-job¹. Using it as a kubernetes' Job allows composition and universal usage. It doesn't make any difference to deploy a Job, a ConfigMap or a CRD. But coupling to an operator slows down development of kcc and no body really want that.

And renaming of realm or sub-imports are unrelated to operator. See -> ¹.

¹ I'm aware that kcc is stateful and has own lifecycle, but well, it's unrelated to operator's lifecycle.

[jkroepke]

@Bessonov I agree with you in terms of Operators. kcc do not operate a realm, it's just an file to API proxy.

Going away from operations and looking to controllers or sidecars (like https://github.com/kiwigrid/k8s-sidecar), there is still a use case, the same way as grafana has implement a sidecar container to import dashboards.

But this increase complexity on code site has a greater weight than the benefits here.

But coupling to an operator slows down development of kcc and no body really want that. Yeah, and mention I still have no clue about software or java development. It might be go even worse.

I also agree for @xRodney, the feature to create a single client through as CRD has some benefits, for example if a create a client through CRD, the operation returns a kubernetes secrets which stores the client-id/client-secret. It avoids the manual credentials handling.

But this is already covered by https://github.com/keycloak/keycloak-operator

[xRodney]

I still believe that there are use cases that currently cannot be fulfilled using neither kcc, nor the official keycloak-operator.

But I understand that this is not what kcc wants to be and the maintenance costs would be too high. After all, stalling of development of such a useful tool is the last thing I would want.

Thanks for hearing me out.