Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Direct support for configuring JVM keystore and truststore, with external passwords #771

Open
maracle6 opened this issue Jun 14, 2024 · 0 comments
Labels
enhancement New feature or request

Comments

@maracle6
Copy link
Contributor

maracle6 commented Jun 14, 2024

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.:

javaOpts: "-Djavax.net.ssl.trustStore=/opt/pega/certs/trust.jks -Djavax.net.trustStorePassword=PASS123 -Djavax.net.ssl.keyStore=/opt/pega/certs/keystore.jks -Djavax.net.keyStorePassword=PASS123"

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).

@maracle6 maracle6 added the enhancement New feature or request label Jun 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant