Name and Version

bitnami/keycloak 24.5.1

What architecture are you using?

amd64

What steps will reproduce the bug?

Following the documentation for Keycloak at https://www.keycloak.org/server/all-config, Keycloak environment variables are always starting with KC_, the current Helm Chart references a lot of environment variables starting with KEYCLOAK_ instead. Possibly this was an old way to define environment variables for Keycloak some versions ago, but it does not seem to be the current way.

Additionally, I see a lot of environment variables in the ./templates/configmap-env-vars.yaml which may not exist in that form anymore, so this job is not done by just replacing KEYCLOAK_ with KC_, for example variables like KEYCLOAK_DATABASE_HOST, KEYCLOAK_DATABASE_PORT, KEYCLOAK_DATABASE_NAME, KEYCLOAK_DATABASE_USER which may have been replaced by something like KC_DB_USERNAME, KC_DB_PASSWORD and KC_DB_URL - looks to me like the whole way database connections are made has changed somehow. I'm surprised the variables you're defining in the chart do work, but also, I'm afraid sometime they won't anymore.

It looks a lot to me that a whole makeover and a sanity check for every environment variable would be appropriate here.

Are you using any custom parameters or values?

No response

What is the expected behavior?

No response

What do you see instead?

I'd like to rely on the Helm chart if I use it and see that environment variables are translated properly.

For my special case, I wanted to configure the Infinispan caching for Keycloak and stumbled over this, when I checked if the values for cache.stackName and cache.stackFile are translated into the proper environment variables. In fact, I don't even figured what stackFile actually should be, so I looked into the code and it translates to KEYCLOAK_CACHE_CONFIG_FILE which may be better defined as KC_CACHE_CONFIG_FILE.

(I configured a bunch of Keycloak installations in the past, but none of these using the Bitnami Helm Chart until now).

Actually I think the whole values section for cache could be left out and you could leave it up to the customer to define some additional extraEnvVars for his specific use case at all.

Additional information

No response