Red Hat Single Sign-on Operator and custom Keystore revisited
About a month ago, I wrote about securing your Red Hat SSO Keycloak-operator instance with your own Keystore. To recap quickly: the Red Hat SSO Keycloak instance of your OpenShift instance is not reachable by your services if your OpenShift cluster has a non-wildcard certificate. So, either the URL of your Keycloak route should be added as a SAN to the certificate, or you should create a custom Keystore specific for Keycloak.
The default Keycloak route has the TLS Termination set to reencrypt, which means that you get to Keycloak “through” the OpenShift certificate. But, the OpenShift reversed proxy creates a new connection using the self-signed certificate of the Keycloak instance. The Red Hat SSO Operator uses its own self-generated certificate to get to the APIs of Keycloak to reconcile the Custom Resources as the Keycloak instance, the realm, client, and users.
When you apply the updates as suggested in my article, you solve the problems of connecting to the Keycloak authorization server, but since the TLS Termination is set to passthrough and the Keycloak certificate is signed by another CA, the Operator will fail to connect.
Another HTTPS-listener
The solution to that is to have another HTTPS-listener to get to the authorization server and leave the default to be used by the Operator.
This means performing the following steps:
- Implement the solution as described in my previous article: Secure your Red Hat SSO/Keycloak Operator instance with your own Keystore.
- However, replace the postconfigure.sh script as described below.
- Add a new custom Service.
- Add a new custom OpenShift Route (or Ingress on plain Kubernetes).
Revised postconfigure
The previous version of the postconfigure.sh script reconfigured the existing HTTPS-listener. The new version adds a new HTTPS-listener in three steps.
1. Add A security Realm
First create a new security-realm, called UndertowCustomHTTPs.
These lines first add a new security-realm. Then it adds a server-identity called ssl to it. On this server-identity the Keystore is set, exactly as described in my previous article.
2. Add a new Socket Binding
Then add a new Socket Binding, using the following lines:
This Socket Binding adds the actual port. In this line, I just hard-coded the port to 8843. The default port is 8443. You could parameterize this of course, but since the default port is also quite fixed (I haven’t seen a property to set that in the Custom Resource).
3. Add the new Custom HTTP Listener
Next, add a custom HTTPS-listener, referring to the new custom Socket Binding:
As a last step in the script, the truststore is replaced, as described in the previous article. This will not contain the certificates from the truststore generated by starting up the Keycloak instance. I haven’t found problems with it, yet. But, I could adapt the script to merge the two.
Custom Service and Route
When the Keycloak instance is reconfigured with the new HTTPS-endpoint, it needs to be exposed using a Service and OpenShift Route (or Ingress in plain Kubernetes). I provided those on GitHub.
I named the Keycloak Custom service just keycloak-custom. since the default service is called just keycloak, irrespective of the name of the keycloak instance. Also, the port is just hardcoded to 8843. So, in our current Helm charts, we have no parameters for it yet.
Even so, the Keycloak custom route is named the same way, as keycloak-custom referring to the custom Keycloak service.
Obviously, the new HTTPS Listener results in a new URL. So, don’t forget to update/replace the Certificate in the Keystore with the new URL in the SANs.
Conclusion
Using the new setup, the Operator can control the Keycloak Instance, while the authorization server is reachable through the new port and Route.
There is a warning stating that setting a Security Realm on an https-listener is deprecated. However, this is conform the default setup. And as of the upstream Keycloak 20, Wildfly will be replaced by Quarkus.
At the time of writing we use version 7.6.1 of the Red Hat OpenShift operator:
According to a Realm Export, containing the Keycloak version, this refers to Keycloak version: 18.0.3.redhat-00001.
The Quarkus variant apparently has support for defining custom Keystore and Truststore through the Custom Resource Definition. So, I presume that in a few years this article will become obsolete.
