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.

If you use net-istio for Ingress and enable mTLS via SMCP using security.dataPlane.mtls: true, Service Mesh deploys DestinationRules for the *.local host, which does not allow DomainMapping for OpenShift Serverless.

To work around this issue, enable mTLS by deploying PeerAuthentication instead of using security.dataPlane.mtls: true.

  • 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).

  1. Create a Kubernetes TLS secret:

    $ oc create secret tls <tls_secret_name> --cert=<path_to_certificate_file> --key=<path_to_key_file>
  2. 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.

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

    apiVersion: serving.knative.dev/v1alpha1
    kind: DomainMapping
      name: <domain_name>
      namespace: <namespace>
        name: <service_name>
        kind: Service
        apiVersion: serving.knative.dev/v1
    # TLS block specifies the secret to be used
        secretName: <tls_secret_name>
  1. 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
  2. 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. You can enable this mechanism by setting an environment variable to the KnativeServing custom resource (CR).

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.

  • 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).

  • Set the ENABLE_SECRET_INFORMER_FILTERING_BY_CERT_UID variable to true for net-kourier-controller in the KnativeServing CR:

    Example KnativeServing CR
    apiVersion: operator.knative.dev/v1beta1
    kind: KnativeServing
     name: knative-serving
     namespace: knative-serving
       - env:
         - container: controller
             value: 'true'
         name: net-kourier-controller