Securing a mapped service using a TLS certificate - Configuring custom domains for Knative services | Serving

Securing a service with a custom domain by using a TLS certificate

After you have configured a custom domain for a Knative service, you can use a TLS certificate to secure the mapped service. To do this, you must create a Kubernetes TLS secret, and then update the DomainMapping CR to use the TLS secret that you have created.

Prerequisites

You configured a custom domain for a Knative service and have a working DomainMapping CR.
You have a TLS certificate from your Certificate Authority provider or a self-signed certificate.
You have obtained the cert and key files from your Certificate Authority provider, or a self-signed certificate.
Install the OpenShift CLI (oc).

Procedure

Create a Kubernetes TLS secret:

$ oc create secret tls <tls_secret_name> --cert=<path_to_certificate_file> --key=<path_to_key_file>

Add the networking.internal.knative.dev/certificate-uid: <id>` label to the Kubernetes TLS secret:
```
$ oc label secret <tls_secret_name> networking.internal.knative.dev/certificate-uid="<id>"
```
If you are using a third-party secret provider such as cert-manager, you can configure your secret manager to label the Kubernetes TLS secret automatically. Cert-manager users can use the secret template offered to automatically generate secrets with the correct label. In this case, secret filtering is done based on the key only, but this value can carry useful information such as the certificate ID that the secret contains.

The cert-manager Operator for Red Hat OpenShift is a Technology Preview feature. For more information, see the Installing the cert-manager Operator for Red Hat OpenShift documentation.

Update the DomainMapping CR to use the TLS secret that you have created:

apiVersion: serving.knative.dev/v1beta1
kind: DomainMapping
metadata:
  name: <domain_name>
  namespace: <namespace>
spec:
  ref:
    name: <service_name>
    kind: Service
    apiVersion: serving.knative.dev/v1
# TLS block specifies the secret to be used
  tls:
    secretName: <tls_secret_name>

Verification

Verify that the DomainMapping CR status is True, and that the URL column of the output shows the mapped domain with the scheme https:

$ oc get domainmapping <domain_name>

Example output

NAME                      URL                               READY   REASON
example.com               https://example.com               True

Optional: If the service is exposed publicly, verify that it is available by running the following command:
```
$ curl https://<domain_name>
```
If the certificate is self-signed, skip verification by adding the -k flag to the curl command.

Improving net-kourier memory usage by using secret filtering

By default, the informers implementation for the Kubernetes client-go library fetches all resources of a particular type. This can lead to a substantial overhead when many resources are available, which can cause the Knative net-kourier ingress controller to fail on large clusters due to memory leaking. However, a filtering mechanism is available for the Knative net-kourier ingress controller, which enables the controller to only fetch Knative related secrets.

The secret filtering is enabled by default on the OpenShift Serverless Operator side. An environment variable, ENABLE_secret_INFORMER_FILTERING_BY_CERT_UID=true, is added by default to the net-kourier controller pods.

If you enable secret filtering, all of your secrets need to be labeled with networking.internal.knative.dev/certificate-uid: "<id>". Otherwise, Knative Serving does not detect them, which leads to failures. You must label both new and existing secrets.

Prerequisites

You have cluster administrator permissions on OpenShift Container Platform, or you have cluster or dedicated administrator permissions on Red Hat OpenShift Service on AWS or OpenShift Dedicated.
A project that you created or that you have roles and permissions for to create applications and other workloads.
Install the OpenShift Serverless Operator and Knative Serving.
Install the OpenShift CLI (oc).

You can disable the secret filtering by setting the ENABLE_secret_INFORMER_FILTERING_BY_CERT_UID variable to false by using the workloads field in the KnativeServing custom resource (CR).

Example KnativeServing CR

apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
...
  workloads:
    - env:
        - container: controller
          envVars:
            - name: ENABLE_secret_INFORMER_FILTERING_BY_CERT_UID
              value: 'false'
      name: net-kourier-controller