Skip to content

Latest commit

 

History

History
44 lines (29 loc) · 3.59 KB

knative-encryption.md

File metadata and controls

44 lines (29 loc) · 3.59 KB
Raw

Knative Serving Encryption

⛔️ Warning: not everything is implemented, as Knative Serving encryption is still a work-in-progress. Tracking project: https://github.com/orgs/knative/projects/63/views/1

Overview

There are three parts to Knative Serving encryption

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

📝 Note: currently all control-plane traffic (including Kubernetes PreStopHooks and metadata like metrics) are not (yet) encrypted.

Overview of Knative encryption

The parts in detail

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

(1) External domain

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 using an implementation to the Knative Certificate abstraction. Currently, we support the net-certmanager implementation.
  • Please refer to the documentation for more information.

(2) Cluster-local certificates

Cluster local domain

  • Certificate CN/SAN contains the cluster-local domain 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 our bridging component net-certmanager. They need to be installed and configured for the feature to work.

(3) Knative internal certificates

Knative system internal

Knative internal system components (ingress-controller, activator, queue-proxy) are hosting TLS endpoints when this configuration is enabled.

  • To get the certificates, Knative relies on cert-manager and our bridging component net-certmanager. 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.