[bitnami/cassandra] Make TLS secret configuration more versatile to allow interaction with cert-manager/trust-manager

[tbalzer]

Name and Version

bitnami/cassandra 11.3.12

What is the problem this feature will solve?

We are trying to use the bitnami/cassandra chart to deploy a cassandra cluster with TLS enabled, using certificates/keystores created via cert-manager and truststores created by trust-manager (part of the same project), which leads to issues due to the differing formats of the secrets created by cert-manager/trust-manager vs the secret expected by the chart.

The main differences are:

• chart expects a single secret for truststore and keystore, which doesn't allow usage of trust-manager which creates a separate secret for the truststore
• chart expects the keys keystore and truststore, but cert-manager and trust-manager create the keys keystore.jks/keystore.p12 and truststore.jks/truststore.p12 respectively (not configurable on either side)
• chart expects the keys keystore-password and truststore-password in the same secret, with non-configurable keys (this is configurable on cert-manager and trust-manager side though, so not a deal-breaker but still not flexible)

What is the feature you are proposing to solve the problem?

Introduce the following values:

• tls.secretKeys.truststorePassword with default truststore-password
• tls.secretKeys.keystorePassword with default keystore-password
• tls.secretKeys.keystore with default keystore
• tls.secretKeys.truststore with default truststore
• tls.existingTrustSecret with default of empty string (signaling "none", meaning to use tls.existingSecret for both)

Then instead of hardcoded values for the secret keys, the respective values could be used while ensuring backwards compatibility. Special care has to be taken in case of keystore and truststore which are also used as filenames in init-containers and environment variables as the tls secret is mounted to /certs which could be replaced with a projected volume built from just the expected/required files from one or multiple secrets as configured.

What alternatives have you considered?

Another alternative would be (at least for some users not requiring trust-manager) to request changes just in cert-manager to make those keys configurable. I personally think though that this is the more appropriate place.

Another alternative would be to build some kind of workaround that generates the expected secrets from the existing secrets generated by cert-manager before deploying the helm chart. This is however quite inconvenient.

[javsalgar]

Hi!

Thank you so much for the feature request! Indeed, we would like to improve our integrations with tools like cert-manager/trust-manager. Actually, I believe that in other charts we have values for the secret keys in order to avoid this issue. I will forward it to the team but as it is not a critical feature we cannot guarantee an ETA. If you want to speed up the process, would you like to submit a PR adding support for these values?

[tbalzer]

@javsalgar PR is attached

[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!

[github-actions]

This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback.

[github-actions]

Due to the lack of activity in the last 5 days since it was marked as "stale", we proceed to close this Issue. Do not hesitate to reopen it later if necessary.