operator-preconfig-tls-routes.adoc

Configuring SSL/TLS and Routes

Support for {ocp} edge termination routes have been added by way of a new managed component, tls. This separates the route component from SSL/TLS and allows users to configure both separately.

EXTERNAL_TLS_TERMINATION: true is the opinionated setting.

Note	Managed tls means that the default cluster wildcard certificate is used. Unmanaged tls means that the user provided key and certificate pair is be injected into the route.

The ssl.cert and ssl.key are now moved to a separate, persistent secret, which ensures that the key and certificate pair are not regenerated upon every reconcile. The key and certificate pair are now formatted as edge routes and mounted to the same directory in the Quay container.

Multiple permutations are possible when configuring SSL/TLS and routes, but the following rules apply:

• If SSL/TLS is managed, then your route must also be managed.

• If SSL/TLS is unmanaged then you must supply certificates directly in the config bundle.

The following table describes the valid options:

Table 1. Valid configuration options for TLS and routes

Option	Route	TLS	Certs provided	Result
My own load balancer handles TLS	Managed	Managed	No	Edge route with default wildcard cert
{productname} handles TLS	Managed	Unmanaged	Yes	Passthrough route with certs mounted inside the pod
{productname} handles TLS	Unmanaged	Unmanaged	Yes	Certificates are set inside of the quay pod, but the route must be created manually

Creating the config bundle secret with the SSL/TLS cert and key pair

Use the following procedure to create a config bundle secret that includes your own SSL/TLS certificate and key pair.

Procedure

• Enter the following command to create config bundle secret that includes your own SSL/TLS certificate and key pair:

  $ oc create secret generic --from-file config.yaml=./config.yaml --from-file ssl.cert=./ssl.cert --from-file ssl.key=./ssl.key config-bundle-secret