Repository navigation
Replies: 1 comment 2 replies
|
@cfahrni you have identified the two ways in which this is currently possible. We are trying to limit or remove the usage of the pod template moving forward #40183 and #40184 already mentions env variables as needing explicit handling. If you don't want to rely on the unsupported pod template, the additional options are the only other way. Since we don't explicitly check for unused KC_ properties, as long as you choose a unique secondary prefix, there won't be a problem. We also don't document / guarentee that the additional options are specified via the env, but we are unlikely change that anytime soon. |
|
Thank you! I will use the additional options until there is an official solution for how to handle env vars. |
|
I forgot to mention you may also use a custom image to either hard-code additional environment variables or map from KC_ prefixes that are settable via the operator. Moving forward we'll have #41766 |
Uh oh!
There was an error while loading. Please reload this page.
Hi there
We are running some Keycloak instances using the Keycloak-Operator on Kubernetes.
We use Keycloakify-Themes and would like to make use of the theme customization by using environment variables.
The Keycloak CR provides a way to set env-variables for the containers by using
spec.unsupported.podTemplate.Another way would be to add a custom key/value-pair in
spec.additionalOptionswhich are translated to Env-Variables (e.g.xyz-theme-titleis accessible by usingKC_XYZ_THEME_TITLE). But we are unsure of potential side-effects becausexyz-theme-titleis obviously not an official configuration-option.What would be the best solution to provide custom environment-variables?
Thanks for you replies!
All reactions