Repository navigation
Keycloak Realm Configuration Management Tools #30643
Replies: 12 comments 16 replies
|
Thanks for bringing this up. Here are some requirements I envision for such a configuration tool:
Export
|
|
I'm pretty sure that there's no one-size-fits-all solution. The project's ecosystems for example in terms of tooling and knowledge are just different. We also don't see a need for a ("the") new tool, but for proper maintenance of the existing ones. And some of them are already pretty awesome! |
I wouldn't make this a hard requirement though. For example, Terraform has its own DSL and it is one of industry standards for managing configuration as code. I wouldn't remove it from considerations just because the declaration format isn't YAML. |
|
Hello, Another way to configure Keycloak is to use Keycloak Admin CLI as explained by @MaikKingma during the DevoxxBe https://youtu.be/aZOoH0i4s-0?si=6dWLyZo0ynrLEofR |
|
I agree with all of these points except the YAML/Helm. Like @gim- mentioned, Terraform HCL is a human readable and declarative language too. Also, not everything runs on Kubernetes. So, Helm isn't a hard requirement. Many people still run software in other forms and don't/wouldn't use Helm to deploy their configuration. |
|
I would like to add two requirements:
|
|
Hey there, on our project we suffered quite long from documenting changes in Confluence which our Ops-Team had to apply to all our stages and also we were not able to keep the dev stages clean from manual changes or missed configurations. When we started the config as code approach we took our current realm export and wanted to make it work. We didn't use terraform or other providers as this would have required a lot of further implementation. Now it is possible to add a new flow, client or configuration at our dev stages which turns into the same output we use as input for the keycloak-config-cli and with some tiny adjustments we can adapt the same parts in our realm configuration, which is configured using environment variables. It definitely is a bunch of work when a new major comes in. But honestly the work is easy to manage, the more people participate in the task. The last majors we had several people giving ideas, approaches, the right links to bug descriptions and so on and therefore it was manageable to adjust the tool. As every project ends somewhere, a larger base of contributors always gives certainty that a tool survives 😉 |
|
And your tool is very much appreciated 😁 |
|
As we already had the general Terraform knowledge, that's exactly why we opted for the Terraform provider approach: all the benefits of a declarative, coded approach: easy to review, version-controllable, repeatable (e.g. for staging) and so on. |
|
We switched from tf to keycloak-config-cli and it's been an amazing experience. I genuinely hope this tool gets more attention from the community |
|
|
Improvements to the CNF7 Keycloak JSON Import / Export would be beneficial in my humble opinion:
Footnotes |
|
Correct me if I'm wrong here, but don't the Pulumi and Crossplane providers also rely on the terraform module created by @mrparkers? |
|
Yes, you are right. However, for this survey we want to learn what tools users use to configure Keycloak. |
|
Makes sense, thank you. |
|
I've just set up a simple Keycloak environment for the first time, using the two-stage Docker approach, as per the documentation. I only use it as an IDP broker between my application and external auth providers. I wish I'd also like sensitive stuff like client secrets to be symmetrically encrypted using some encryption key stored in the keystore. Similarly, I'd like This together would allow me to safel
10000
y version realm configs in a private git repo without any third-party tooling asides from It seems like The only currently available native import/export options for Docker-based deployments seem to be CFN1 and CFN7, all other require some external dependencies or tooling in one form or another, that's maintained separately, and has no guarantee to stay up to date. The CFN3 Terraform provider is looking like least complex option that would work for my simple use case that allows me to version realm configurations while storing the sensitive values somewhere secure. But it adds quite a bit of complexity that could feasibly be avoided, and I'd much rather have a simpler native option available similar to what is described above using the built-in |
|
I have created https://github.com/CycriLabs/keycloak-configurator (therfore fitting into CNF9) which I use for my personal projects and which we use in our company. It is based on Quarkus together with picocli and can be executed from the CLI or via docker. Internally, it uses keycloak admin client to configure keycloak based on separate JSON files for each entity type (e.g. realms, clients, users, groups, roles, etc.). Besides keycloak configuration, it supports exporting it again, exporting secrets / env files (using velocity templates), and secret rotation. Currently, we use it for the initial configuration of Keycloak in productions servers as well as for configuring short-living test servers or feature servers based on a common shared configuration repository. Whenever there is config change, we simply add the related JSON file and run the tool (i.e. partial updates/rolling updates, currently no sync is supported). In addition, we use it for integration testing as well. We do not need to maintain a large realm.json for startup import but instead use fine-grained single files for better overview and source management. Looking forward for feedback, feature requests, or anything else that can improve the tool. |
|
Interesting. How does it compare to keycloak-config-cli? (besides the config files layout, IIUC) |
|
I am not very familiar with keycloak-config-cli, but on first sight it looks very similar in regards to configuration. Keycloak-config-cli has for sure more config features and is more mature. Not sure though about other features like export, secret export/rotation, etc. Keycloak-configurator evolved out of our previous python-based solution. It was some years old and maintance was an issue. Therefore, we decided to migrate the features to a Java tech stack. |
|
keycloak-config-cli can Import, but doesn't Export, so I'll try yours asap :) |
|
For our project we use combination of both CNF1 Keycloak Admin CLI kcadm.sh Was also wondering if there is way to sync any new changes to keycloak instance to git using a pull request. |
|
Hi, in our project we are using IaC on K8s via ArgoCD. So for us improvement to CNF8 Keycloak Operator Realm Import via Custom Resources would be the best option. The improvement being that it is not just "Realm Import via CR", but full management via CR. |
|
Is there a timeframe in which this discussion and the survey are going to close out? My team is making use of both CNF2 Keycloak-Config-CLI and CNF3 Terraform Provider for Keycloak. I would prefer to use CNF3 Terraform Provider for Keycloak since Terraform is a common pattern for a lot of other infrastructure my team manages. It also gives us a free audit trail by running Terraform through GitOps. |
|
I know this thread is somewhat old, but I am to choose an solution for my company, so I'd be more than interested in a follow up, or at least the results of the initial survey. Given the severe limitations of CNF7 (JSON import) and CNF8 (K8s Operator) that can only import if the realm doesn't exist, or delete and recreate it (so no update, which is real bad for production environment), CNF2 (Keycloak-Config-CLIT) and CNF3 (Terraform Provider) seem like the best options, as both use a declarative approach and can scale even for complex projects and can manage updates of existing ressources. But neither is an "official" tool, implying at least some delay between a KC release and the corresponding update (for example : neither seem to be handling the recently added Organization concept, at least from documentation), and though both projects seem pretty active at the moment, one may worry about maintenance in the future. At least having the result of the survey could give some visibility into what the community is using, and bit of confidence about what tool should survive... |
|
Are aware that the terraform provider was adopted by Keycloak? https://github.com/keycloak/terraform-provider-keycloak |
|
I was not, thanks for the heads up ! That's settled then Terraform it is ! |
|
yeah, i'm building a simple bitnami keycloak instance using docker, so i setup docker file and docker compose and launch the compose. but i'm in trouble about to setup the realm that i'm importing as "current realm" on the bootstrap of the instance, so in the build time. Is there a way to do that? Thanks in advance |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Numerous options exist for managing Keycloak Realm configurations within the
Keycloak ecosystem. As the Keycloak team, we want to understand better what works
best for the community and how we can improve the support for Realm configuration
management.
The options that exist on our radar are as follows:
So that we in the Keycloak community have a representative picture of the configuration
options used, we would also like you to participate in the following following brief, anonymous survey.
Feel free to add additional comments or suggestions regarding realm configuration management tooling below!
Thank you for your help!
All reactions