Description

The keycloak cr should handle directly specifying truststores. A corresponding server feature will use those truststores for all scenarios - mTLS, LDAP, etc.

For users of keycloak via the operator this will simply management of truststores.

Points of discussion:

• This will largely by-pass the need for setting individual truststores under the assumption that there is no need to differentiate by usage. Is this ok for an MVP, or does the trust need to be limited to the purpose (https vs spi vs java).
• It does not seem necessary to offer the ability to opt of of trusting the kubernetes ca certs
• MVP support for storeType could be fixed as PEM, meaning the password field would not be needed.
• What changes, if any, should be made in the server to accomodate this?
  • If the server is responsible for creating the merged keystore, how does this relate to the optimization process?
• How does this relate to keys (symetric and asymetric) needed for mutual auth?
  • The initial thought is to treat them separately.

Issues anticipated in this epic:

• Add any desired new functionality in server
• Update the CR and operator to the MVP state
• Capture follow-up work, which can include supporting other truststore types.

Also relates to

• Use Java cacerts truststore together with additional truststore provided via spi-truststore-file-file parameter #16473 (should obviate)
• Add truststore options to Keycloak CR #9784 (should obviate)
• Dynamic Truststore for external TLS #13300

Discussion

keycloak/keycloak-community#345

The discussion on the pr has more emphasis on:

• hot reload / Reloading rotated certificate with Keycloak on Quarkus #10654
• creating an spi - which would need to be easily usable by the operator
• trust at the realm level, which was not in the scope of the initial issues identified here

Issues

• Add truststores to keycloak cr #24798
• Add config property to specify a list of truststores #24148
• Support importing Kubernetes CA #10794
• Support LDAPS with non-public certificates #9301
• Reloading rotated certificate with Keycloak on Quarkus #10654 - if in scope could influence what is responsible for creating the merged truststore
• Add support for certificate revocation check on outgoing interfaces #23729 (may not be in scope)

Motivation

To provide users with the flexibility to address the known issues around truststores from both the keycloak CR and direct usage of the server.