红帽全球峰会6.7. 零信任网络
零信任（Zero trust）一个设计安全基础架构的方法，它基于内部的环境，其中的每个交流行为都从一个不受信任的状态开始。这与传统的架构不同。传统架构可能会根据交流是否是在防火墙内发起的来确定其信任性。更具体地说，零信任会尝试缩小安全基础架构中的漏洞（依赖隐式信任模型和一次性身份验证）。
OpenShift Container Platform 可以为平台上运行的容器添加一些零信任网络功能，而无需更改容器或它们中运行的软件。红帽提供的几种产品进一步增加了容器的零信任网络功能。如果您能够更改容器中运行的软件，则还有红帽支持的其他项目，可以添加进一步的功能。
探索零信任网络的以下目标功能。
6.7.1. 信任的根
公共证书和私钥对于零信任网络至关重要。它们用来识别另一个组件、验证和保护流量的安全组件。证书由其他证书签名，存在到根证书颁发机构 (CA) 的信任链。参与网络的所有内容需要最终具有 root CA 的公钥，以便它可以验证信任链。对于面向公共的项，通常是全局已知的根 CA，其密钥与操作系统、Web 浏览器等一起分发。但是，如果私有 CA 的证书被分发到所有方，则可以针对一个集群或一个机构运行私有 CA。
利用：
- OpenShift Container Platform：OpenShift 在安装时会创建一个集群 CA，用于保护集群资源。但是，OpenShift Container Platform 也可以在集群中为服务证书创建和签署证书，并在请求时可以将集群 CA 捆绑包注入 pod。由 OpenShift Container Platform 创建并签名的服务证书具有 26 个月的生存时间 (TTL)，并在 13 个月内自动轮转。如有必要，也可以手动轮转它们。
- OpenShift cert-manager Operator ：cert-manager 允许您请求由外部信任根签名的密钥。有许多可配置的签发者可以与外部签发者集成，以及与委派的签名证书一起运行的方法。cert-manager API 可供零信任网络中的其他软件使用，以请求必要的证书（如 Red Hat OpenShift Service Mesh），或者可由客户软件直接使用。
6.7.2. 流量身份验证和加密
确保网络上的所有流量都加密，并且端点是可识别的。例如，Mutual TLS 或 mTLS，这是 mutual 身份验证的方法。
利用：
- OpenShift Container Platform：使用透明 pod-to-pod IPsec，可以通过 IP 地址识别流量的源和目标。这可以实现对出口流量使用 IPsec 加密。通过使用 egress IP 功能，流量的源 IP 地址可用于识别集群中的流量源。
- Red Hat OpenShift Service Mesh: 提供强大的 mTLS 功能，这些功能可以透明地增加离开 pod 的流量以提供身份验证和加密。
- OpenShift cert-manager Operator：使用自定义资源定义 (CRD) 请求可挂载用于 SSL/TLS 协议的证书。
6.7.3. 身份识别和验证
在使用 CA 最小化证书后，您可以通过验证连接端的另一端的连接身份验证一个用户或客户端机器来建立信任关系。这还需要管理证书生命周期，以便在被破坏时限制使用。
利用：
- OpenShift Container Platform：集群签名的服务证书，以确保客户端与可信端点通信。这要求服务使用 SSL/TLS，并且客户端使用集群 CA。客户端身份必须使用某种其他方法提供。
- Red Hat Single Sign-On：提供与企业用户目录或第三方身份提供程序的请求身份验证集成。
- Red Hat OpenShift Service Mesh: 将连接透明升级到 mTLS、自动轮转、自定义证书过期以及请求使用 JSON Web 令牌 (JWT) 的身份验证。
- OpenShift cert-manager Operator ：创建和管理证书，供应用程序使用。证书可以由 CRD 控制并挂载为 secret，也可以更改应用程序以直接与 cert-manager API 交互。
6.7.4. 服务间的授权
务必要根据请求者的身份控制对服务的访问。这由平台完成，不需要每个应用程序来实现它。这样可以更好地审核和检查策略。
利用：
-
OpenShift Container Platform：可以使用 Kubernetes
NetworkPolicy和AdminNetworkPolicy对象在平台的网络层中强制实施隔离。 - Red Hat OpenShift Service Mesh: 使用标准 Istio 对象 对流量的复杂 L4 和 L7 控制，并使用 mTLS 识别流量源和目标，然后根据该信息应用策略。
6.7.5. 事务级验证
除了识别和验证连接的功能外，控制单个事务的访问也很有用。这可包括源、可观察性和语义验证的速率限制。
利用：
- Red Hat OpenShift Service Mesh: 执行对请求的 L7 检查，拒绝 HTTP 请求、事务级 可观察性和报告。Service Mesh 还可使用 JWT 提供基于请求的身份验证。
6.7.6. 风险评估
随着集群中的安全策略数量增加，策略允许和拒绝的视觉化变得越来越重要。这些工具可让您更轻松地创建、视觉化和管理集群安全策略。
利用：
-
Red Hat OpenShift Service Mesh: 使用 OpenShift Web 控制台创建和视觉化 Kubernetes
NetworkPolicy和AdminNetworkPolicy，以及 OpenShift NetworkingEgressFirewall对象。 - Red Hat Advanced Cluster Security for Kubernetes ：对象的高级视觉化。
6.7.7. 站点范围内的策略实施和分发
在集群中部署应用程序后，管理组成安全规则的所有对象就变得困难。务必要应用站点范围的策略，并审核部署的对象是否符合策略。这应该允许将某些权限委派给定义的绑定内的用户和集群管理员，并应允许例外策略。
利用：
6.7.8. 持续的可观察性，以及重新检查评估
运行的集群后，您希望能够观察流量，并使用定义的规则验证流量是否被端口。这对入侵检测、共识非常重要，有助于操作负载管理。
利用：
- Network Observability Operator：允许检查、监控和警报到集群中的 pod 和节点的网络连接。
- Red Hat Advanced Cluster Management (RHACM) for Kubernetes: 监控、收集和评估系统级事件，如进程执行、网络连接和流以及特权升级。它可以决定集群的基线，然后检测异常活动并提醒您。
- Red Hat OpenShift Service Mesh ： 可以监控进入和离开 pod 的流量。
- Red Hat OpenShift distributed tracing 平台 ：对于适当的检测应用程序，您可以看到与特定操作关联的所有流量，因为它被分成到微服务的子请求。这可让您识别分布式应用程序中的瓶颈。
6.7.9. 端点安全性
务必要信任在集群中运行服务的软件没有被破坏。例如，您可能需要确保在可信硬件上运行认证的镜像，并有策略只允许基于端点特征或来自端点特征的连接。
利用：
- OpenShift Container Platform：Secureboot 可以确保集群中的节点正在运行可信软件，因此平台本身（包括容器运行时）没有被篡改。您可以将 OpenShift Container Platform 配置为仅运行 由特定签名签名的镜像。
- Red Hat Trusted Artifact Signer：这可用于可信构建链并生成已签名的容器镜像。
6.7.10. 在集群外扩展信任
您可能希望通过允许集群到子域的 mint CA 来在集群外扩展信任。或者，您可能希望 attest 到集群中的工作负载身份到远程端点。
利用：
- OpenShift cert-manager Operator：您可以使用 cert-manager 管理委派的 CA，以便可以在不同集群之间或通过您的机构分发信任。
- Red Hat OpenShift Service Mesh: 可以使用 SPIFFE 为在远程或本地集群中运行的端点提供远程测试工作负载。
