davgordo
commented
6 months ago I uncovered a TLS trust challenge when experimenting with the new Keycloak operator.
Background: Using the RH SSO operator, the only possible path for securing (TLS) Keycloak service endpoints was using edge-terminated OpenShift Routes. While this represented a security limitation, it also potentially hides complexity with TLS trust between Backstage and Keycloak because many cluster environments use certificates signed by public authorities for default router endpoints.
Issue: Now that the new Keycloak operator references a Kubernetes TLS secret for pod-terminated TLS connections, we can instrument a certificate with cert-manager. However, in the case that we use an internal issuer, we need to configure the Backstage instance to trust the issuer.
The RH SSO operator will eventually be deprecated in favor of the "Red Hat Keycloak" operator.
Completing this migration will require analysis of the CRDs which enable realm imports. It is unknown whether the CRDs supported by the new operator allow enough configuration control to load all key realm configuration for the demo.
Currently, we are importing a raw JSON-formatted realm export. https://github.com/contract-first-idp/platform-components/blob/main/charts/keycloak/templates/realmimport-configmap.yaml
This realm representation format is not likely compatible with the new Keycloak operator.