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