[bitnami/postgresql] user-defined keys of an existing secret are not honoured when using password files

[pursultani]

Name and Version

bitnam/postgresql 12.5.2

What architecture are you using?

None

What steps will reproduce the bug?

Install any version of the PostgreSQL chart with the following values. The provided values are intended to use an existing Secret with user-defined keys for passwords and mount them as "password files".

Password file names are hard-coded and should be either password or postgres-password and auth.secretKeys.userPasswordKey and auth.secretKeys.adminPasswordKey values are not effective with password files. This means that users do not have other choices for naming the keys of the Secret.

Noting that this issue only occurs with password files. Using existing Secret with user-defined keys to pass passwords as environment variables is working as expected.

Are you using any custom parameters or values?

auth:
  usePasswordFiles: true
  existingSecret: my-postgresql-password
  secretKeys:
    adminPasswordKey: my-postgres-password
    userPasswordKey: my-user-password

What is the expected behavior?

In templates/primary/statefulset.yaml:

• The value for POSTGRES_POSTGRES_PASSWORD_FILE environment variable to be /opt/bitnami/postgresql/secrets/my-postgres-password
• The value for POSTGRES_PASSWORD_FILE environment variable to be /opt/bitnami/postgresql/secrets/my-password

What do you see instead?

In templates/primary/statefulset.yaml:

• The value for POSTGRES_POSTGRES_PASSWORD_FILE environment variable to be /opt/bitnami/postgresql/secrets/postgres-password
• The value for POSTGRES_PASSWORD_FILE environment variable to be /opt/bitnami/postgresql/secrets/password

Additional information

We encountered this GitLab Chart where we tried to upgrade Bitnami PostgreSQL dependency from 8.9.4 to 12.5.2. We worked around it by setting auth.usePasswordFiles=false and using environment variables as the default upgrade path and recommending renaming the Secret keys as an alternative upgrade path for users that do not want to store the password in environment variables.

Reference: https://gitlab.com/gitlab-org/charts/gitlab/-/issues/4118#note_1376504623

[WarheadsSE]

👋 @carrodher @migruiz4

We isolated this to the ternary calls used to populate the XYZ_FILE entries for the environment(s), when using usePasswordFiles: true. They hard-code the default strings, instead of calling to get the same keys that are used when usePasswordFiles: false.

[migruiz4]

Hi @pursultani @WarheadsSE,

Thank you for reporting this issue! I have submitted this PR #16729 fixing this.

I would appreciate if you could take a look and let us know if it works for you.