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

Allow TLS key pair to be sourced at runtime from a Kubernetes secret #700

Open
klasen opened this issue May 3, 2023 · 5 comments
Open

Comments

@klasen
Copy link
Contributor

klasen commented May 3, 2023

If intra-cluster communication needs to be encrypted, the pwm must provide https service with a certificate trusted by the ingress controller.

In order to achieve this I'd like to provide the TLS key/cert pair at pod runtime using a Secret of type "kubernetes.io/tls", coming a tls.crt and tls.key files, and ca.crt secret for intermediate and root certificates.

Unfortunately, because of the current way certs are configured in pwm, I can't mount this secret to any pod folder and get the pair picked up by the container at runtime.

See https://kubernetes.github.io/ingress-nginx/examples/auth/client-certs/#creating-certificate-secrets

@jrivard
Copy link
Contributor

jrivard commented May 5, 2023

Id like to see this added as well. In the meantime, just in case it's not clear, PWM will use the default Java truststore for certificate validation in cases where no certificate is configured in the corresponding setting.

So the approach to implement this would be to have the docker startup script:

  1. generate a Java keystore using keytool
  2. import any certs found in a defined path
  3. set JAVA_OPTIONS parameter to have the jvm use the above keystore

I don't think any changes to PWM Java code are required.

@klasen
Copy link
Contributor Author

klasen commented May 9, 2023

PWM will use the default Java truststore for certificate validation in cases where no certificate is configured in the corresponding setting.

@jrivard Does this also apply to the HTTPS Private Key & Certificate setting?
The comment on this setting is If this setting does not have a value, the SSPR HTTPS web server uses an auto-generated value based on Settings ⇨ Application ⇨ Application ⇨ Site URL and other current configuration data.

@jrivard
Copy link
Contributor

jrivard commented May 12, 2023

@jrivard Does this also apply to the HTTPS Private Key & Certificate setting? The comment on this setting is If this setting does not have a value, the SSPR HTTPS web server uses an auto-generated value based on Settings ⇨ Application ⇨ Application ⇨ Site URL and other current configuration data.

@klasen Nope, only for certificate trusts. Though we could probably have it try to use a well-known alias name for the private cert and only auto-generate one if it can't find such a cert..... I'll think about it a bit...

@klasen
Copy link
Contributor Author

klasen commented May 12, 2023

Could we set javax.net.ssl.keyStore to a keystore generated by the container startup script and have tomcat use the default SSLContext?

This default SSLContext is initialized with a default KeyManager and a default TrustManager. If a keystore is specified by the javax.net.ssl.keyStore system property and an appropriate javax.net.ssl.keyStorePassword system property (see How to Specify a java.lang.System Property), then the KeyManager created by the default SSLContext will be a KeyManager implementation for managing the specified keystore. (The actual implementation will be as specified in Customizing the Default Key Managers and Trust Managers.) If no such system property is specified, then the keystore managed by the KeyManager will be a new empty keystore.

From https://docs.oracle.com/en/java/javase/11/security/java-secure-socket-extension-jsse-reference-guide.html#GUID-7D9F43B8-AABF-4C5B-93E6-3AFB18B66150

@jrivard
Copy link
Contributor

jrivard commented May 12, 2023

Could we set javax.net.ssl.keyStore to a keystore generated by the container startup script and have tomcat use the default SSLContext?

I don't know. My guess is that if it worked it would probably break other things TLS. PWM doesn't change the default KeyManager as far as I know and just sets tomcat's keystore properties, so I don't know what magic happens inside tomcat. At that point your probably better off just making your own docker image with tomcat and the PWM war and configuring tomcat as desired... For reference this is the PWM code that does the embedded tomcat initialization:

https://github.com/pwm-project/pwm/blob/master/onejar/src/main/java/password/pwm/onejar/TomcatOnejarRunner.java

@klasen klasen changed the title Allow TLS certificate to be sourced at runtime from a Kubernetes secret Allow TLS key pair to be sourced at runtime from a Kubernetes secret Feb 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants