The first release of the Red Hat build of Keycloak will include the new Operator for Kubernetes. In a 2022 blog post, the Keycloak community described the issues and future of the Operator. The new Operator has been written from scratch using the Java Operator SDK; it brings more flexibility and a better architecture to support our customers' daily operations.
For those new to Operators, it encodes operational expertise into software, allowing reliable management of Kubernetes applications. Historically, such knowledge was limited to operations staff or external scripts and tools like Ansible. Operators automate routine Day-1 (setup, configuration) and Day-2 (updates, backups, failovers) tasks directly within the Kubernetes environment, creating Kubernetes-native applications, meaning managing applications as a singular entity rather than disparate elements like Pods or ConfigMaps.
Operators have different capabilities and levels. The Keycloak operator is a level-4 Operator, meaning that it can do the basic installation and seamless upgrades, manage the lifecycle of the Keycloak server, and provide monitoring and metrics integrations in this case, e.g., with Red Hat OpenShift Container Platform monitoring.
Red Hat build of Keycloak now includes the following Operator enhancements:
- A new Operator with CRDs for OpenShift.
- Improved importing of realms through a custom resource.
- Support for all databases that the Red Hat build of Keycloak server supports.
- Close alignment with the configuration of bare metal installations.
We recommend installing the Keycloak Operator via the Operator lifecycle manager (OLM). It's simple and can be done via the OpenShift console and OperatorHub for a particular namespace.
Custom Keycloak image
With the latest Operator, it's now possible to provide a custom image for the Keycloak server. Now that the Keycloak server is based on the Quarkus framework, it also brings in certain things to consider that are different from the single sign-on version based on Red Hat JBoss Enterprise Application Platform (JBoss EAP).
When using the default Keycloak image, the server will perform a re-augmentation every time a Pod starts to ensure all the custom config, code, libs, etc., are applied to that pod. This is by design to include changes made by the end user.
However, one might want to optimize it. Developers can now provide a custom image with the augmentation built-in from the build time of the image. For example, a pre-built image can now provide build-time configurations and extensions:
apiVersion: k8s.keycloak.org/v2alpha1
kind: Keycloak
metadata:
name: example-kc
spec:
instances: 1
image: quay.io/my-company/my-keycloak:latest
http:
tlsSecret: example-tls-secret
hostname:
hostname: test.keycloak.org
More configuration options
The Keycloak CR includes most commonly used options and is represented similarly to the Keycloak configuration structure. However, there are cases where advanced configuration needs to be provided. Keycloak CR accepts Key,Value pairs for any of the Keycloak configurations under additionalOptions parameter. The values can be expressed as a string or a Kubernetes secret:
apiVersion: k8s.keycloak.org/v2alpha1
kind: Keycloak
metadata:
name: example-kc
spec:
...
additionalOptions:
- name: spi-connections-http-client-default-connection-pool-size
secret: # Secret reference
name: http-client-secret # name of the Secret
key: poolSize # name of the Key in the Secret
- name: spi-email-template-mycustomprovider-enabled
value: true # plain text value
The custom resource (CR) now also supports experimental features under the unsupported tag and the ability to disable certain security features for development usage.
Read the following documentation for more in-depth details on using Operators and creating the different CRs and features.
Getting support for Keycloak
Support for Keycloak is available to Red Hat customers through a subscription. Contact a local Red Hat representative or Red Hat Sales for details on how to enjoy world-class support offered by Red Hat and its worldwide partner network. Customers can expect support for Red Hat build of Keycloak and other runtimes according to the Red Hat Product Update and Support Lifecycle.
Get started
Ready to get started with Red Hat build of Keycloak? Here are more useful links to get you started:
- Zip distributions are available through the Customer portal.
- Container distributions and Operators are available in the Red Hat Container Catalog (RHCC).
- Product documentation is available on the Red Hat customer portal, including a migration guide to help you migrate your existing Red Hat single sign-on deployments to Red Hat build of Keycloak.
To find out more about Red Hat build of Keycloak, visit the product page.
