第 7 章 服务传输加密
您可以启用 OpenShift Serverless Serving 传输加密，以允许使用 TLS 通过安全和加密的 HTTPS 连接传输数据。
OpenShift Serverless Serving 传输加密只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议（SLA）支持，且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能，并有机会在开发阶段提供反馈意见。
有关红帽技术预览功能支持范围的更多信息，请参阅技术预览功能支持范围。
服务传输加密仅适用于 Kourier 作为入口层。对于 Red Hat OpenShift Service Mesh，使用服务网格 mTLS 功能来确保加密的流量。
7.1. Serving 传输加密概述
OpenShift Serverless Serving 传输加密有三个部分：
- 外部域加密
-
在集群外部的入口层传输加密。例如，cluster-external 域，如
myapp-<namespace>.example.com。 - 集群本地加密
-
在集群中的入口层上传输加密。例如，cluster-local 域，如
myapp.<namespace>.svc.cluster.local。 - system-internal 加密
-
ingress-gateway、激活器和queue-proxyKnative 内部组件之间的传输加密。
control-plane 流量，包括 Kubernetes PreStopHooks、metadata 和 metrics，不包含用户数据且没有加密。
不同的部分彼此独立，可以单独启用和禁用。它们可以使用相同或不同的证书颁发机构(CA)为必要的证书签名。
有关显示传输加密图，请参阅 OpenShift Serverless Serving Transport Encryption。
7.1.1. 外部域加密
外部域的传输加密由集群的入口层处理，即 OpenShift Container Platform ingress 或 Red Hat OpenShift Service Mesh。
7.1.2. 集群本地加密
集群本地加密为集群本地域启用传输加密。它具有以下属性：
-
证书通用名称(CN)或主题备用名称(SAN)包含 Knative Service 的 cluster-local 域，如
myapp.namespace.svc.cluster.local,myapp.namespace.svc,myapp.namespace. -
ingress-controller组件的 cluster-local 端点使用 SNI 来选择证书。 -
要创建证书，Knative 依赖于
cert-manager，它需要安装和配置该功能才能正常工作。如需更多信息，请参阅 Red Hat OpenShift 的 cert-manager Operator。
调用者必须信任签署集群本地证书的 CA。这是 OpenShift Serverless 的范围。
7.1.3. system-internal 加密
system-internal 加密为 ingress-gateway、activator 和 queue-proxy Knative 内部组件启用传输加密。使用此配置时，这些组件托管 TLS 端点。
要使用这个功能，必须满足以下先决条件：
-
要使 OpenShift Serverless 获取证书，必须安装并配置
cert-manager。 - 特定的 SAN 用于验证每个连接。每个组件都必须信任签发证书的 CA。为了满足此要求，OpenShift Serverless 系统组件会消耗并信任 CA 捆绑包。CA 捆绑包必须由集群管理员提供。
