Conversation
vmelikyan
approved these changes
May 2, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Overview
This PR unifies the database authentication configuration for Keycloak, providing a consistent approach for both internal databases (umbrella chart) and external instances. The focus is on enabling flexible use of external secrets and removing legacy workarounds previously required by the operator.
Changes
charts/lifecycle-keycloak/templates/keycloak-instance.yaml:db-usernameenvironment variable, allowing the database username to be passed consistently for both external and internal databases.existingSecretfield is now processed viatpl, enabling dynamic secret name generation.POSTGRES_USER_PASSWORDkey. The password key is now retrieved from.Values.keycloakPostgres.auth.secretKeys.userPasswordKey, allowing the use of custom keys in existing secrets.usernameSecretas the database username is non-sensitive information and is now handled via environment variables.charts/lifecycle-keycloak/templates/postgres-secret.yaml:POSTGRES_USERNAMEfromstringDataas this parameter should no longer be stored within a secret.Rationale
These changes make the chart more "cloud-native" and easier to integrate into complex infrastructures where database parameters may change dynamically or be provided by external secret management systems (e.g., External Secrets Operator).