Attaching a keystore and truststore at the JVM level is required for certain types of integrations, for example JMS. Currently we configure the JVM keystore and truststore by using certificatesSecrets to mount the jks into the pod and using the javaOpts parameter, e.g.:
The main issue we have with this solution is that it requires our jks passwords to be in plain text in the values file. Although jks passwords provide little real security this is generally disallowed by infosec policies. A few other downsides are that the end user needs to know the path on the pod filesystem where the certificates end up which is an undocumented implementation detail, and that this would replace the default cacerts instead of adding to it.
Describe the solution you'd like
Add dedicated parameters for JVM keystore and truststore, and allow (or perhaps require) passwords to be set in a secret.
replicas: 1
javaOpts: ""
# To configure a JVM truststore or keystore, add the jks files to global.certificatesSecrets, then enter the jks names below.
# JKS passwords should be in keys JVM_TRUSTSTORE_PASSWORD and JVM_KEYSTORE_PASSWORD of the external secret
jvmTruststore: ""
jvmKeystore: ""
external_secret_name: ""
This would require adding some support in the docker image entrypoint script as well to construct the consolidated JVM arguments.
Describe alternatives you've considered
For the keystore, there's already a feature in the docker entrypoint script that attempts to load anything from certificatesSecrets and certificates into the OOTB cacerts. Currently it attempts to import any files with extension cer|pem|crt|der|cert|jks|p7b|p7c|key, but JKS files result in an error message. Possibly there's some approach to making this code work for JKS files. However there's no corresponding option for the truststore.
I'm also wondering if it would be nice to have the option to provide a list of keystores and truststores, which would get consolidated in the entrypoint script. For example if there are several integrations to different systems that have provided keystore files, it would be convenient to not have to manually build a single keystore (similar to the already-present functionality above).
Attaching a keystore and truststore at the JVM level is required for certain types of integrations, for example JMS. Currently we configure the JVM keystore and truststore by using certificatesSecrets to mount the jks into the pod and using the javaOpts parameter, e.g.:
The main issue we have with this solution is that it requires our jks passwords to be in plain text in the values file. Although jks passwords provide little real security this is generally disallowed by infosec policies. A few other downsides are that the end user needs to know the path on the pod filesystem where the certificates end up which is an undocumented implementation detail, and that this would replace the default cacerts instead of adding to it.
Describe the solution you'd like Add dedicated parameters for JVM keystore and truststore, and allow (or perhaps require) passwords to be set in a secret.
This would require adding some support in the docker image entrypoint script as well to construct the consolidated JVM arguments.
Describe alternatives you've considered For the keystore, there's already a feature in the docker entrypoint script that attempts to load anything from certificatesSecrets and certificates into the OOTB cacerts. Currently it attempts to import any files with extension cer|pem|crt|der|cert|jks|p7b|p7c|key, but JKS files result in an error message. Possibly there's some approach to making this code work for JKS files. However there's no corresponding option for the truststore.
I'm also wondering if it would be nice to have the option to provide a list of keystores and truststores, which would get consolidated in the entrypoint script. For example if there are several integrations to different systems that have provided keystore files, it would be convenient to not have to manually build a single keystore (similar to the already-present functionality above).