Goals

• Based on user configuration, expose workflow and supporting services Kubernetes svc at the 443 port instead of 80.
• At first, TLS configuration must come from the OpenShift internal certificates to avoid over-complex configurations. See https://docs.redhat.com/en/documentation/openshift_container_platform/4.15/html/security_and_compliance/configuring-certificates#add-service-serving 
• Internal JVMs cacerts must be configured to use OpenShift certificates.
• Manage Quarkus TLS configuration: https://quarkus.io/guides/tls-registry-reference

Description

Some users require internal applications to use TLS communication, even internally in the cluster. Currently, the platform supports TLS via OpenShift Route (external communication).

The workflow applications and the supporting services deployed on OpenShift by the operator must support TLS internally. This means that the SVC (service) will be configured to expose port 443 instead of 80. The Quarkus application will expose HTTPS on port 8443. The operator will mount and configure TLS for users based on the SonataFlowPlatform spec in a given namespace (or cluster).

OpenShift automatically mounts the cluster truststore on every workload, but the operator must configure Quarkus to use this additional truststore other than the JRE default (cacerts).

Risks and Assumptions

OpenShift must manage the certificate, and the platform won't accept external custom certificates.