Contribution to Keycloak.X Operator

[Kevin Reis]

Hi everyone,

as I'm currently on a journey of Operators and Keycloak, I stumbled across the rework of Keycloak's official k8s operator.

At my company, we're working with an in-house made Keycloak operator which we planned to have the same functionalities in its core. However, as I have seen that you work on a new operator, we think about contributing to your operator project instead of continuing the development of our own solution due to their similiarities in functionality.

How can I start contributing to the new operator besides building from source? I can see your project board on GitHub with some issues set on "ToDo". Can I just start right away by picking an issue or can you suggest any issues to start with?

Cheers,

Kevin

[Václav Muzikář]

Hi Kevin,

thank you for your interest in the new Keycloak Operator, we'd very much appreciate your contribution!

Feel free to pick up any task from the Operator project [1] that is unassigned. Before starting with the implementation, I'd suggest discussing the details first in the comments under given issue. This would help us with alignment and with PR review process. Please also make yourself familiar with our Contributing Guide [2].

Are there any specific features you are currently missing in the Operator for your use case?

[1] https://github.com/orgs/keycloak/projects/3

[2] https://github.com/keycloak/keycloak/blob/main/CONTRIBUTING.md

--
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/8771cf81-383f-48b5-b167-616882ff9bf4n%40googlegroups.com.

--

Václav Muzikář
Senior Software Engineer
Keycloak / Red Hat Single Sign-On
Red Hat Czech s.r.o.

[Kevin Reis]

Hi Václav,

as far as I can see, your new Keycloak Operator currently supports a deployment of Keycloak and realms ("import") only. Our in-house solution hasn't implemented both of these as we just take care of the deployment ourselves for the time being. Instead, it can handle

• realms (with a minimal CRD, which takes a realm name and simple key-values properties via `additionalProperties`, but it's like the Keycloak Operator `KeycloakRealmImport`)
  
• roles (realm roles, client roles, composite roles)
• clients + mechanism for client secret rotations
  
• and user federations incl. mappers

All CRDs are based on your representation DTOs, but with some modifications for better update handling. In addition, the CRs and their corresponding Keycloak entities are kept in sync by the operator.

Regarding the project board, roles, clients and user federations as their own entities don't seem to be on the horizon. However, I'd gladly help with other tasks until we can consider to get to that point. :)

[Václav Muzikář]

Hello and sorry for a very late response.

Although we would very much welcome your contribution for adding more CRDs, I'm afraid it's a bit more complicated as we want to revisit our approach around the CRs and we plan to leverage the new store for it, see also our tracker for it. And without the necessary support for it in Keycloak, we can't proceed further with the CRs. Sorry about that.

Nevertheless I would be very interested if you could share any details about your Operator deployment and the use-cases for the custom CRs, so we could reflect on your real-life experience.

Thank you.

Regards,

Václav Muzikář

To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-dev/18006be3-1f79-4d6f-9012-d55d880c11a4n%40googlegroups.com.