SSL/TLS Configuration

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

• With the first option, a Kubernetes Secret object needs to be provided containing the server certificate, in PEM format, for the ITX Runtime Server to present during SSL handshake, and the server certificate key, also in PEM format, for the server to use for signing messages and encrypting content. If you wish to enable mutual-authentication, then you also need to provide the CA certificate, again in PEM format, that was used to sign the certificate of the clients making REST API calls to ITX Runtime Server pods and presenting their certificates. 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. When ITX Runtime Server is deployed, a ConfigMap with the name itx-rs-config-ssc is automatically created with the service-ca key containing PEM encoded CA certificate used for signing certificate for the deployed service. The certificate and its corresponding key are also created for the deployed service, and are stored in the automatically generated Secret object, whose itx-rs-svc name needs to be provided in the ssl.secret key field of the values.yaml file when deploying ITX Runtime server.