Serving Encryption Overview¶

Warning

The Knative Serving encryption features cluster-local-domain-tls and system-internal-tls are in experimental state. Please use with caution!

There are three parts to Knative Serving encryption:

HTTPS on the ingress layer external to the cluster (cluster external domain, like myapp-<namespace>.example.com).
HTTPS on the ingress layer internal to the cluster (cluster local domains, like myapp.<namespace>.svc.cluster.local).
HTTPS between Knative internal components (ingress-controller, activator, queue-proxy).

Overview of Knative encryption

Note

Currently, all control-plane traffic (including Kubernetes PreStopHooks and metadata like metrics) is not encrypted.

The parts in detail¶

The different parts are independent of each other and (can) use different Certificate Authorities to sign certificates.

External domain

Certificate CN/SAN contains the external domain of a Knative Service, e.g. myapp-<namespace>.example.com.
The certificates are hosted using SNI by the external endpoint of the ingress-controller.
The caller has to trust the (external) CA that signed the certificates (this is out of the scope of Knative).
These certificates are either provided manually or by enabling automatic certificate provisioning.

See Configure external domain encryption for more information on this feature.

Cluster local domain

Certificate CN/SAN contains the cluster-local domains of a Knative Service, e.g. myapp.namespace.svc.cluster.local, myapp.namespace.svc, myapp.namespace.
The certificates are hosted using SNI by the cluster-local endpoint of the ingress-controller.
The caller has to trust the CA that signed the certificates (this is out of the scope of Knative). One option to do this is using trust-manager from cert-manager.
To create the certificates, Knative relies on cert-manager and the Knative cert-manager integration. They need to be installed and configured for the feature to work.

See Configure cluster-local domain encryption for more information on this feature.

Knative system internal

Knative system internal components (Ingress-Controller, Activator, Queue-Proxy) are hosting TLS endpoints when this configuration is enabled.

To create the certificates, Knative relies on cert-manager and the Knative cert-manager integration. They need to be installed and configured for the feature to work.
Specific SANs are used to verify each connection. Each component needs to trust the CA (possibly the full chain) that signed the certificates. For this, Knative system components will consume and trust a provided CABundle. The CA bundle needs to be provided by the cluster administrator, possibly using trust-manager from cert-manager.