Introduction

Keycloak has long been a popular choice for identity and access management in containerized environments. With Red Hat's latest operator, Red Hat Build of Keycloak (RHBK), many expected a polished operator experience that would bring declarative persistence and enterprise reliability. Unfortunately, the reality today is that RHBK is not yet ready for persistent production use.

The Promise of Operators

Operators in OpenShift and Kubernetes are meant to:

  • Automate lifecycle management (install, upgrade, reconcile).
  • Provide declarative persistence through Custom Resources (CRs).
  • Eliminate manual drift by continuously enforcing desired state.

For Keycloak, this should mean that realms, clients, users, and LDAP federation settings are defined in CRs and reliably persisted in the database across pod restarts.

The Reality of RHBK

After extensive testing, here's what actually happens:

  • Limited CRD support: The current RHBK operator only ships Keycloak and KeycloakRealmImport CRDs under k8s.keycloak.org/v2alpha1. Crucial CRDs like KeycloakRealm, KeycloakClient, and KeycloakUser are missing.
None
$ oc get crd | grep keycloak
keycloaks.k8s.keycloak.org                                           2025-11-19T13:16:34Z
keycloakrealmimports.k8s.keycloak.org                                2025-11-19T13:16:34Z
  • One-shot imports: KeycloakRealmImport loads realm data once, but does not reconcile it. Settings applied this way can vanish after a pod restart or operator reconciliation.
  • Temp-admin resets: Every time the Keycloak pod restarts, the operator reinitializes the master realm and recreates the temporary admin user. This is a clear sign that persistence is not being enforced.
  • External DB doesn't save you: Even with PostgreSQL configured, realm, client, and LDAP settings are not persistent. The operator only preserves the raw database, but without declarative CRs it resets Keycloak on restart, re‑creating the master realm and temp‑admin, and discarding your custom configuration.

Why This Matters

For enterprise environments, reproducibility and persistence are non-negotiable. Teams expect:

  • Stable admin accounts.
  • Realms and clients that survive restarts.
  • LDAP federation that doesn't need to be reapplied daily.

RHBK, in its current form, fails to deliver on these expectations.

Conclusion

The Red Hat Build of Keycloak Operator is not yet ready for persistent, declarative use. It remains a work in progress, suitable for testing or ephemeral environments, but not for production scenarios where persistence and reliability are critical.

Until Red Hat ships the full suite of k8s.keycloak.org/v2alpha1 CRDs (realms, clients, users), teams should treat RHBK as experimental. For now, persistence requires either:

  • Waiting for the operator to mature into a truly declarative controller, or
  • back to use Red Hat Single Sign-On Operator (RHSSO).

Reference

This document walks through the steps to set up RHBK, but it doesn't know the fact that the settings are not persistent.

https://www.freekb.net/Article?id=6155

2025-10-31 01:06:30,795 INFO  [org.keycloak.services] (main) KC-SERVICES0050: Initializing master realm
2025-10-31 01:06:31,564 INFO  [org.keycloak.services] (main) KC-SERVICES0077: Created temporary admin user with username temp-admin