Keycloak.X - Helm Chart
A Helm chart for deploying the latest Quarkus based distribution of Keycloak (aka Keycloak.X or version 17+).
The chart supports using an external database, ingress, clustering and secret creation and exposes many of the Keycloak configuration variables in a more friendly and discoverable way.
Quick Start
Keycloak.X has been designed to be run from a customized image where kc.sh build has been run to tailor the configuration see the docs
See the examples folder for some example Dockerfiles. These are provided purely as reference only.
However it is possible to deploy the vanilla un-customized Keycloak image:
helm install kc ./keycloak --set 'keycloak.args=["start"]'
The admin user password will be autogenerated and placed into a secret (see Admin User below), get the password with the following command:
kubectl get secret kc-keycloak-admin -o jsonpath='{.data.password}' | base64 -d
Using port-forward to connect to Keycloak and login with the admin account:
kubectl port-forward kc-keycloak-0 8080:8080
Helm Repo
This repo on GitHub is also usable directly as a Helm public remote repo, to add this repo to helm, run the following:
helm repo add keycloak https://benc-uk.github.io/keycloak-helm
helm repo update keycloak
You can then use the chart by referencing it as keycloak/keycloak
helm install mykeycloak keycloak/keycloak ...
Chart Configuration Values
See the main chart readme for a full reference list of values that can be set. Many of these โwrapโ Keycloak environmental variables.
Admin User
The values keycloak.adminUser and keycloak.adminPasswordSecret control the creation of the admin user account. If adminPasswordSecret is NOT set, then a secret will be automatically created and a random password generated. Otherwise you can use keycloak.adminPasswordSecret.name and .key to reference an existing secret you want to use, in this case the creation of this secret is done outside of this Helm chart.
Ingress
Itโs generally expected that a Kubernetes ingress is put in front of Keycloak rather than exposing Keycloak directly, which is why the default proxy mode for the chart is edge this disables HTTPS and TLS on Keycloak, so that TLS can be terminated by the ingress.
See the Keycloak docs and the chart value keycloak.proxyMode setting.
The simplest configuration possible would be:
ingress:
enabled: true
host: keycloak.example.net
Should you wish to enable TLS, specify the secretName holding the cert (issuing of certs & TLS secrets is deemed outside the scope of this chart), e.g.
ingress:
enabled: true
host: keycloak.example.net
tls:
enabled: true
secretName: benco-io-cert
Database Configuration
If the Keycloak image has been configured/built with database support, the runtime options for the database can be passed by the values under keycloak.database, e.g. keycloak.database.host etc
The value keycloak.database.passwordSecret is expected to stored as a key in a secret, the creation and management of this secret is outside the scope of this chart.
๐ NOTE If the image has been built with database support, and database configuration is not provided, then Keycloak defaults to certain internal parameters e.g. localhost for the database, naturally this will fail.
NOTE Only MS-SQL Server has been tested at this current time
Clustering
If the Keycloak image has been configured/built with distributed caching in order to run in a cluster, then the deployment to Kubernetes can run across multiple pods.
To enable clustering and multiple pods:
- Set the
replicaCountto a value greater than 1 - Set
keycloak.clusteredto true
When keycloak.clustered is set to true two things are done by the chart:
- A additional headless service is created in front of the pods, allowing for DNS discovery.
- Extra parameter is passed to the Keycloak startup script, which is
-Djgroups.dns.query. This is set to point at the name of the headless service.
๐ NOTE 1 If clustering (i.e. a cache stack provider) has been enabled in the Keycloak image, then keycloak.clustered must be set to true, even if the replicaCount is 1. Keycloak will fall over if dns.query is not set
๐ NOTE 2 Only the Kubernetes cache stack provider has been tested, e.g. KC_CACHE_STACK=kubernetes when running kc.sh build
Extra environmental vars and secrets
The chart is designed to pass most of the Keycloak environmental variables based on the chart values passed in, as such you donโt need to set the KC_ variables directly. However not every variable is catered for, and you may want some additional flexibility.
For this extraEnv and extraEnvSecret can be used
Example of using extraEnv would look like:
keycloak:
extraEnv:
KC_SOME_SETTING: "Value here"
An example of extraEnvSecret might be as follows, say you have the database username stored as a secret, in which case you would not set keycloak.database.username and instead pass it in using extraEnvSecret, as follows:
keycloak:
extraEnvSecret:
KC_DB_USERNAME:
secretName: sql-database-creds
secretKey: sql-username
URL Path
Should you wish to serve Keycloak from a different URL path, this can only be done when building the Keycloak image, e.g. KC_HTTP_RELATIVE_PATH=/foo when running kc.sh build
If this has been done, then keycloak.healthCheckPath will need to be adjusted, e.g. /foo/realms/master