SSL/TLS Configuration

Edit online

Two options are available for enabling SSL/TLS communication (HTTPS) with the ITX Runtime Server.

With the first option, the Runtime Server can be configured to perform client authentication. This is enabled by setting restV1.inbound.https.clientAuth or rest.inbound.https.clientAuth to true for the V1 and V2 deployment modes, respectively. Client authentication is disabled by default.

  • With the first option, a Kubernetes Secret object needs to be provided. This object contains the server certificate and the server certificate key for the Runtime Server. Both are in PEM format. If you wish to enable client authentication, then you also need to provide a CA certificate file, again in PEM format, that can be used to authenticate clients.

    See the mappings restV1.inbound.https and rest.inbound.https for HTTPS TLS configuration. The keys that you use in the Secret object for certificate authority, server certificate and server key must be named ca.crt, tls.crt, and tls.key respectively.

    You can define and manage the Secret object directly and deploy it to the namespace prior to installing ITX Runtime Server, or you can use a cert-manager tool in your cluster to generate the secret automatically and to manage the certificates and keys stored in the secret, including their expiry and rotation. The name of the secret needs to be provided when deploying ITX Runtime Server.

  • With the second option, the built-in Service Serving Certificates feature of OpenShift is utilized to provide a server certificate, server private key, and a CA trust store. Use of the Service Serving Certificates feature is indicated by setting restV1.inbound.https.serviceServingCertificates or rest.inbound.https.serviceServingCertificates to true for the V1 and V2 deployment modes, respectively.

    When the Runtime Server is deployed, a Secret object is created for a Service whose backend uses the Service Serving Certificates feature. For example, if the Service Serving Certificates feature is used for the V2 deployment option, a Secret is created for the Service which exposes the HTTPS port of the REST server for the V2 deployment option. Naming and use of this Secret is handled automatically.

    A ConfigMap object is automatically created which contains a CA certificate for the Service Serving Certificates CA. The Service Serving Certificates option does not support client authentication, which may not be needed when all ITX-RS communication is internal to the cluster. When communicating externally, however, the RHOS Ingress Controller can be configured for client authentication. Even though ITX-RS is running without client authentication, external client communications can be authenticated with the RHOS Ingress Controller before any ITX-RS communication requests are re-encrypted and then forwarded to the ITX-RS service.

    For more information about the OpenShift Service Serving Certificates feature, see OpenShift documentation.

In both the V1 and V2 modes, HTTP connections are enabled by default. To disable HTTP connections, set restV1.inbound.http.enabled or rest.inbound.http.enabled to false, respectively.