Charts: [incubator/keycloak] Provide means to provide certificates for `truststore.jks`

[briantopping]

Is this a request for help?: No

---

Is this a BUG REPORT or FEATURE REQUEST? (choose one): FEATURE REQUEST

https://www.keycloak.org/docs/3.3/server_installation/topics/network/outgoing.html#_truststore describes the process to generate a truststore for outgoing TLS connections from Keycloak. Assuming that the image is ephemeral, the keystore could be better managed through the API.

Version of Helm and Kubernetes:
Brians-MBP:~ brian$ kubectl version
Client Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.2", GitCommit:"81753b10df112992bf51bbc2c2f85208aad78335", GitTreeState:"clean", BuildDate:"2018-05-12T04:12:12Z", GoVersion:"go1.9.6", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.2", GitCommit:"81753b10df112992bf51bbc2c2f85208aad78335", GitTreeState:"clean", BuildDate:"2018-04-27T09:10:24Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}
Brians-MBP:~ brian$ helm version
Client: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.9.0", GitCommit:"f6025bb9ee7daf9fee0026541c90a6f557a3e0bc", GitTreeState:"clean"}

Which chart:

What happened:

What you expected to happen:

How to reproduce it (as minimally and precisely as possible):

Anything else we need to know:

[briantopping]

I guess with #5372 it would be possible to create a keystore, encode it with base64, take the string into a shell script that generated the file and finally inserted the <spi/> element to the standalone.xml.

Alas, my shell wizard level is 0.

[triqster]

What I did as a workaround is the following:

• Inject the CA into a truststore (I added my ca to a copy of the default java truststore)
• Added the truststore to kubernetes as a secret
• Added the deployment to use the secret as a volume (file, using the subpath option)
• Patched the start script of jboss (docker-entrypoint.sh) to include the following java startup parameters:
  i.e.
  -Djavax.net.ssl.trustStore=/opt/catruststore -Djavax.net.ssl.trustStorePassword=changeit

[unguiculus]

See #5887 and #5950

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Any further update will cause the issue/pull request to no longer be considered stale. Thank you for your contributions.

[Hokwang]

@triqster Can you explain more detaily for beginner like me?

[markns]

I've been trying to get the Keycloak server to use a custom truststore for some time now, without any success.

I've added the cacerts to the container using a configmap mount.

[jboss@keycloak2-0 ~]$ ll /opt/cacerts 
-rw-r--r-- 1 root root 155884 Mar  5 14:30 /opt/cacerts

I've specified the args to pass to the startup script

extraArgs: "-Djavax.net.ssl.trustStore=/opt/cacerts -Djavax.net.ssl.trustStorePassword=changeit"

The startup script receives the args:

/bin/sh /opt/jboss/keycloak/bin/standalone.sh -Djboss.bind.address=192.168.158.135 -Djboss.bind.address.private=192.168.158.135 -b 0.0.0.0 -Djavax.net.ssl.trustStore=/opt/cacerts -Djavax.net.ssl.trustStorePassword=changeit -c standalone.xml

But when I try to make a LDAPS connection to our internal AD, I get an error:

14:31:56,923 INFO  [org.keycloak.truststore.SSLSocketFactory] (default task-3) No truststore provider found - using default SSLSocketFactory
14:31:57,178 ERROR [org.keycloak.services] (default task-3) KC-SERVICES0055: Error when authenticating to LDAP: simple bind failed: myaddomain:636: javax.naming.CommunicationException: simple bind failed: myaddomain:636 [Root exception is javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target]

Notice the INFO line saying that no truststore provider has been found.

@unguiculus @triqster Could you suggest something to check perhaps?

[triqster]

Atm I'm using the example below in my helm chart:

extraArgs: -Dkeycloak.import=/realm/realm.json -Djavax.net.ssl.trustStore=/opt/jboss/keycloak/standalone/configuration/cacerts -Djavax.net.ssl.trustStorePassword=**CHANGEMEDUMMY**

  ## Additional init containers, e. g. for providing custom themes
  extraInitContainers: |
    - name: test-ca
      image: hub.docker.com/private/test_cacerts:latest
      imagePullPolicy: Always
      imagePullSecrets: secret
      command:
        - sh
      args:
        - -c
        - |
          echo "Copying test cacerts..."
          cp -R /test/cacerts /test/
      volumeMounts:
        - name: cacerts
          mountPath: /test

  ## Add additional volumes and mounts, e. g. for custom themes
  extraVolumes: |
    - name: cacerts
      emptyDir: {}
  extraVolumeMounts: |
    - mountPath: /opt/jboss/keycloak/standalone/configuration/cacerts
      subPath: cacerts
      name: cacerts

TLDR;
I've created a container with the ca jks and uploaded it to a private repo. Then the init container with the cacert starts to copy the cacert jks to an emptydir and gets mounted by the keycloak pod.

This allows me to update the init container and allows me to use the new ca cert on the next pod restart.

[vishalreddy277]

@markns Did you get a solution to this issue? can you let me know ? @triqster we are not using helm charts is there any other way to do it ?

[joostcoelingh]

@markns Did you get a solution to this issue? can you let me know ? @triqster we are not using helm charts is there any other way to do it ?

Yes there is, exactly what the helm chart does above. In your case that would be:

• Create or modify a JKS with the CA
• Start keycloak with the correct flags:
  -Djavax.net.ssl.trustStore=/PATHTOYOURCA/ca.jks -Djavax.net.ssl.trustStorePassword=**CHANGEMEDUMMY**

[zvaraondrej]

Hopefully this might be helpfull.