Postgresql Secret Issues with Cyberark Conjur

[ChristianRaoulis]

Name and Version

bitnami/postgresql 15.2.9

What architecture are you using?

None

What steps will reproduce the bug?

1. Create a Cyberark Conjur Secret with replication and admin user credentials
2. Use that Secret as source for the global.postgresql.auth.existingSecret value
3. Add the Cyberark Conjur Sidecar to the helm values
4. Try to deploy

What is the expected behavior?

The helm chart gets deployed with the Cyberark Conjur Sidecar which then reads and updates the Secret in global.postgresql.auth.existingSecret to contain the correct values. Postgres then uses those values to start up

What do you see instead?

The helm chart deployment fails due to this error:

error: execution error at (postgresql/templates/secrets.yaml:15:27): 
PASSWORDS ERROR: The secret "postgresql-app-secret" does not contain the key "postgres-password"

Additional information

The Secret postgresql-app-secret initially only contains information for conjur. Those information are then used by the Cyberark Conjur Sidecar to update the k8s secret with the real values. So initially the postgres-password key doesn't exist in the k8s Secret but conjur will insert it as soon as it starts.

[carrodher]

The issue may not be directly related to the Bitnami container image or Helm chart, but rather to how the application is being utilized or configured in your specific environment.

Having said that, if you think that's not the case and are interested in contributing a solution, we welcome you to create a pull request. The Bitnami team is excited to review your submission and offer feedback. You can find the contributing guidelines here.

Your contribution will greatly benefit the community. Feel free to reach out if you have any questions or need assistance.

If you have any questions about the application itself, customizing its content, or questions about technology and infrastructure usage, we highly recommend that you refer to the forums and user guides provided by the project responsible for the application or technology.

With that said, we'll keep this ticket open until the stale bot automatically closes it, in case someone from the community contributes valuable insights.

[ChristianRaoulis]

The issue may not be directly related to the Bitnami container image or Helm chart, but rather to how the application is being utilized or configured in your specific environment.

Having said that, if you think that's not the case and are interested in contributing a solution, we welcome you to create a pull request. The Bitnami team is excited to review your submission and offer feedback. You can find the contributing guidelines here.

Your contribution will greatly benefit the community. Feel free to reach out if you have any questions or need assistance.

If you have any questions about the application itself, customizing its content, or questions about technology and infrastructure usage, we highly recommend that you refer to the forums and user guides provided by the project responsible for the application or technology.

With that said, we'll keep this ticket open until the stale bot automatically closes it, in case someone from the community contributes valuable insights.

The source of my issue is basically that the chart reads my existing secret instead of using the information from the chart values to create secretRefs.

It would be really nice if that behavior could be changed. I have never created a helm chart myself otherwise i would've opened a PR for this 😅

[carrodher]

Thank you for opening this issue and submitting the associated Pull Request. Our team will review and provide feedback. Once the PR is merged, the issue will automatically close.

Your contribution is greatly appreciated!

[ChristianRaoulis]

I opened a PR which should fix my issue by preventing the chart from accessing the secret before the conjur init container / sidecar adds the values to the k8s secret.

It would be nice if someone could take a look on that PR or open another one that fixes the problem in a better way.