You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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?
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.
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.
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.
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:
keystore
andtruststore
, but cert-manager and trust-manager create the keyskeystore.jks
/keystore.p12
andtruststore.jks
/truststore.p12
respectively (not configurable on either side)keystore-password
andtruststore-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 defaulttruststore-password
tls.secretKeys.keystorePassword
with defaultkeystore-password
tls.secretKeys.keystore
with defaultkeystore
tls.secretKeys.truststore
with defaulttruststore
tls.existingTrustSecret
with default of empty string (signaling "none", meaning to usetls.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
andtruststore
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.
The text was updated successfully, but these errors were encountered: