Serving 加密概述¶
警告
Knative Serving 的加密功能 cluster-local-domain-tls 和 system-internal-tls 处于实验阶段。请谨慎使用！
Knative Serving 加密分为三个部分：
- 集群外部（cluster external domain）的入口层 HTTPS，例如
myapp-<namespace>.example.com。 - 集群内部（cluster local domains）的入口层 HTTPS，例如
myapp.<namespace>.svc.cluster.local。 - Knative 内部组件（
ingress-controller、activator、queue-proxy）之间的 HTTPS。
注意
目前，所有控制平面流量（包括 Kubernetes PreStopHooks 和指标等元数据）均未加密。
详细介绍¶
各个部分相互独立，并且（可以）使用不同的证书颁发机构（CA）来签署证书。
外部域名加密¶
- 证书的公用名称/主题备用名称 (CN/SAN) 包含 Knative 服务的外部域名，例如
myapp-<namespace>.example.com。 - 这些证书由 ingress-controller 的外部端点通过 SNI 进行托管。
- 调用者必须信任签署证书的（外部）CA（这超出了 Knative 的范围）。
- 这些证书可以通过手动方式提供，也可以通过启用自动证书预配来提供。
有关此功能的更多信息，请参阅 配置外部域名加密。
集群内加密¶
- 证书的公用名称/主题备用名称 (CN/SAN) 包含 Knative 服务的集群内域名，例如
myapp.namespace.svc.cluster.local、myapp.namespace.svc、myapp.namespace。 - 这些证书由 ingress-controller 的集群内端点通过 SNI 进行托管。
- 调用者必须信任签署证书的 CA（这超出了 Knative 的范围）。一种方法是使用 cert-manager 的 trust-manager。
- 为了创建证书，Knative 依赖于 cert-manager 和 Knative 的 cert-manager 集成。需要安装并配置它们才能使该功能正常工作。
有关此功能的更多信息，请参阅 配置集群内域名加密。
Knative 系统内部加密¶
启用此配置后，Knative 系统内部组件（Ingress-Controller、Activator、Queue-Proxy）会托管 TLS 端点。
- 为了创建证书，Knative 依赖于 cert-manager 和 Knative 的 cert-manager 集成。需要安装并配置它们才能使该功能正常工作。
- 将使用特定的 SAN 来验证每次连接。每个组件都需要信任签署证书的 CA（可能是完整的证书链）。为此，Knative 系统组件将使用并信任提供的
CABundle。CA bundle 需要由集群管理员提供，可能使用 cert-manager 的 trust-manager。
有关此功能的更多信息，请参阅 配置 Knative 系统内部加密。