Secured routes

• Creating a re-encrypt route with a custom certificate
• Creating an edge route with a custom certificate
• Creating a passthrough route

Secure routes provide the ability to use several types of TLS termination to serve certificates to the client. The following sections describe how to create re-encrypt, edge, and passthrough routes with custom certificates.

Creating a re-encrypt route with a custom certificate

You can configure a secure route using reencrypt TLS termination with a custom certificate by using the oc create route command.

Prerequisites

• You must have a certificate/key pair in PEM-encoded files, where the certificate is valid for the route host.

• You may have a separate CA certificate in a PEM-encoded file that completes the certificate chain.

• You must have a separate destination CA certificate in a PEM-encoded file.

• You must have a service that you want to expose.

$ openssl rsa -in password_protected_tls.key -out tls.key

Procedure

This procedure creates a Route resource with a custom certificate and reencrypt TLS termination. The following assumes that the certificate/key pair are in the tls.crt and tls.key files in the current working directory. You must also specify a destination CA certificate to enable the Ingress Controller to trust the service’s certificate. You may also specify a CA certificate if needed to complete the certificate chain. Substitute the actual path names for tls.crt, tls.key, cacert.crt, and (optionally) ca.crt. Substitute the name of the Service resource that you want to expose for frontend. Substitute the appropriate hostname for www.example.com.

• Create a secure Route resource using reencrypt TLS termination and a custom certificate:

  $ oc create route reencrypt --service=frontend --cert=tls.crt --key=tls.key --dest-ca-cert=destca.crt --ca-cert=ca.crt --hostname=www.example.com

  If you examine the resulting Route resource, it should look similar to the following:

  YAML Definition of the Secure Route

  apiVersion: v1
  kind: Route
  metadata:
    name: frontend
  spec:
    host: www.example.com
    to:
      kind: Service
      name: frontend
    tls:
      termination: reencrypt
      key: |-
        -----BEGIN PRIVATE KEY-----
        [...]
        -----END PRIVATE KEY-----
      certificate: |-
        -----BEGIN CERTIFICATE-----
        [...]
        -----END CERTIFICATE-----
      caCertificate: |-
        -----BEGIN CERTIFICATE-----
        [...]
        -----END CERTIFICATE-----
      destinationCACertificate: |-
        -----BEGIN CERTIFICATE-----
        [...]
        -----END CERTIFICATE-----

  See oc create route reencrypt --help for more options.

Creating an edge route with a custom certificate

You can configure a secure route using edge TLS termination with a custom certificate by using the oc create route command. With an edge route, the Ingress Controller terminates TLS encryption before forwarding traffic to the destination pod. The route specifies the TLS certificate and key that the Ingress Controller uses for the route.

Prerequisites

• You must have a certificate/key pair in PEM-encoded files, where the certificate is valid for the route host.

• You may have a separate CA certificate in a PEM-encoded file that completes the certificate chain.

• You must have a service that you want to expose.

$ openssl rsa -in password_protected_tls.key -out tls.key

Procedure

This procedure creates a Route resource with a custom certificate and edge TLS termination. The following assumes that the certificate/key pair are in the tls.crt and tls.key files in the current working directory. You may also specify a CA certificate if needed to complete the certificate chain. Substitute the actual path names for tls.crt, tls.key, and (optionally) ca.crt. Substitute the name of the service that you want to expose for frontend. Substitute the appropriate hostname for www.example.com.

• Create a secure Route resource using edge TLS termination and a custom certificate.

  $ oc create route edge --service=frontend --cert=tls.crt --key=tls.key --ca-cert=ca.crt --hostname=www.example.com

  If you examine the resulting Route resource, it should look similar to the following:

  YAML Definition of the Secure Route

  apiVersion: v1
  kind: Route
  metadata:
    name: frontend
  spec:
    host: www.example.com
    to:
      kind: Service
      name: frontend
    tls:
      termination: edge
      key: |-
        -----BEGIN PRIVATE KEY-----
        [...]
        -----END PRIVATE KEY-----
      certificate: |-
        -----BEGIN CERTIFICATE-----
        [...]
        -----END CERTIFICATE-----
      caCertificate: |-
        -----BEGIN CERTIFICATE-----
        [...]
        -----END CERTIFICATE-----

  See oc create route edge --help for more options.

Creating a passthrough route

You can configure a secure route using passthrough termination by using the oc create route command. With passthrough termination, encrypted traffic is sent straight to the destination without the router providing TLS termination. Therefore no key or certificate is required on the route.

Prerequisites

• You must have a service that you want to expose.

Procedure

• Create a Route resource:

  $ oc create route passthrough route-passthrough-secured --service=frontend --port=8080

  If you examine the resulting Route resource, it should look similar to the following:

  A Secured Route Using Passthrough Termination

  apiVersion: v1
  kind: Route
  metadata:
    name: route-passthrough-secured (1)
  spec:
    host: www.example.com
    port:
      targetPort: 8080
    tls:
      termination: passthrough (2)
      insecureEdgeTerminationPolicy: None (3)
    to:
      kind: Service
      name: frontend

  1	The name of the object, which is limited to 63 characters.
  2	The termination field is set to passthrough. This is the only required tls field.
  3	Optional insecureEdgeTerminationPolicy. The only valid values are None, Redirect, or empty for disabled.

  The destination pod is responsible for serving certificates for the traffic at the endpoint. This is currently the only method that can support requiring client certificates, also known as two-way authentication.