Uploaded image for project: 'Keycloak'
  1. Keycloak
  2. KEYCLOAK-16207

Keycloak Operator needs a mechanism to support LDAPS with non-public certificates

    XMLWordPrintable

Details

    • Task
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Out of Date
    • None
    • None
    • Container - Operator
    • None
    • NEW
    • NEW
    • ---
    • ---

    Description

      Problem: deploying Keycloak via Keycloak Operator on Kubernetes (vanilla, launched via RKE, not openshift) and want to integrate with an AD running using its own CA-issued certificate via LDAPS.  Out of the box, there appears to be no way to do this via kubernetes configuration.

      Suggested approach: have a secret (similar to sso-x509-https-secret) in which the CA root/intermediate certs can be set which then get loaded into the cacerts file keycloak is using for LDAP.

      Attempted workaround:

      • inject certificates using sso-x509-https-secret (as in: kubectl create secret -n mynamespace generic sso-x509-https-secret  --from-file=./root.crt --from-file=./int.crt which then cause int.crt and root.crt to be visible inside the keycloak container at /etc/x509/https
      • via kubectl exec:
        • run the jboss-cli to find the path and password for the SPI Truststore (verify that standalone-ha.xml points to it)
        • use keytool (and the password above) to import the injects certs to the truststore
        • again run the jboss-cli to this time leverage the /subsystem=elytron/key-store=kcTrustStore:load() and /subsystem=elytron/trust-manager=kcTrustManager:init() to reload the truststore and associated trustmanager
        • running
          /subsystem=elytron/key-store=kcTrustStore:read-aliases and seeing my new aliases added (note that if run after using keytool and before doing load/init, not seeing the new aliases)
        • optional: use https://github.com/UniconLabs/java-keystore-ssl-test to validate that the truststore can access a webserver signed by the same AD CA (and that accessing the AD as https://ad:636 returns an error that strongly suggests it got past SSL and just didn't like that the LDAP server didn't return valid HTTP)
      • via kubectl logs: see that running the load() / init() did in fact do something based on seeing warnings about some of the certs in the file being expired
      • via the Keycloak Admin webpage, hit the verify auth (connection works but appears to only check TCP layer and not app layer), get error which logs show to be because the truststore isn't working.  This was same behavior with SPI Truststore used for LDAPS only or Always.  Not sure if there's an upstream bug with keycloak, but see below for "worse" workaround that actually worked.

      Current Workaround:

      • as with above, inject certificates using sso-x509-https secret
      • via docker -u root (could possibly have used exec-as plugin to kubectl to not have to use docker on the correct node), run
        keytool -importcert -file /etc/x509/https/root.crt -alias my_root -keystore <path to cacerts> (and repeat for my_intermediate)
      • configure LDAP in federation to NEVER use SPI Truststore
      • Be pleasantly surprised that verify auth works and can import users into Keycloak.

       

      Attachments

        Activity

          People

            Unassigned Unassigned
            carleton@mitre.org Valued Customer (Inactive)
            Votes:
            4 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: