新功能上线与应用演进的速度不断加快，直接推高了架构的复杂性。这种不间断的快节奏不仅源于对新功能的追求，更是日益被层出不穷的新漏洞所裹挟。修补单个关键依赖项，可能会引发一连串必要的更新和意料之外的架构变更，因为每款产品和解决方案都包含无数实现选项，以及各种需要启用或禁用的功能。要将这套复杂的体系适配到您的特定环境中，确保每个组件都按行业最佳实践部署，无疑是一项艰巨的挑战。有效验证模式应运而生，弥合了这一差距。它提供开箱即用且经过严格测试的部署方案，适用于各种用例，让您无需从头开始搭建安全至上的复杂架构。
关于漏洞管理的残酷真相
2025 年，新发布的通用漏洞披露（CVE）超过 40,000 个，意味着每天有 100 多个新漏洞涌现。如今，AI 驱动的漏洞利用生成技术，正大幅缩短从漏洞披露到野外被实际利用的窗口期。《追逐圣杯》一文指出，如果一味追求零 CVE 的完美分数，有时反而会适得其反，因为它会分散我们对深层次纵深防御策略的注意力。一个上午 9 点还“干净”的组件，可能在下午 5 点就被披露出新漏洞。即使您真的实现了零已知 CVE，未知漏洞也始终存在。
对于运行着数百个容器化工作负载的企业环境而言，“补丁算术”（即误认为安全防护仅仅是一场数字游戏，CVE 越少风险就越低）根本站不住脚。与在单一操作系统上运行的传统单体式架构不同，分布式容器环境引入了显著更高的架构复杂性。无数微服务和网络触点提供了海量配置选项，一旦哪个环节出错，都可能在无意中造成安全漏洞。试图立即修复一切问题，不仅是永无止境的徒劳之举，更与基于风险的现代安全策略背道而驰。这种做法还忽略了一个基本事实：无论您多么积极快速地应用更新，修补滞后总是不可避免。
那么，在漏洞披露与补丁部署之间的这段空窗期间，我们该怎么做？答案在于一条已存在多年、但如今比以往任何时候都更加关键的安全原则：零信任架构。
零信任对红帽 OpenShift 集群意味着什么
零信任不是一款可以安装的产品，而是一种架构理念。它假设入侵已经发生，要求每一次交互都必须经过显式验证和授权。根据 NIST SP 800-207 标准，零信任意味着移除那些仅凭物理或网络位置便赋予资源（资产、应用或用户帐户）的隐式信任。在与任何企业资源建立会话之前，身份验证和授权都必须作为独立环节先行执行完毕。
在 Kubernetes 和红帽 OpenShift 中实施零信任，需要采用涵盖工作负载身份、机密管理和运行时访问控制的多层方法。单就网络域而言，这一理念最关键的影响之一，便是摒弃默认的扁平网络态势，即每个 pod 都能自由通信的状态。默认情况下，Kubernetes 不施加任何内部网络限制，这就相当于一栋大楼仅仅因为装了大门（比如集群入口控制器、API 网关或边界防火墙），就放任内部所有房门统统敞开。对于现代云原生环境而言，仅仅依靠这种边界防御是根本不够的。
根据零信任模型，我们假设入侵已经发生，并且恶意行为者已经进入您的环境——这些可能是绕过边界的外部攻击者、被攻陷的供应链组件，或是直接从内部发起攻击的恶意内部威胁。通过实施 Kubernetes 网络资源限制，我们可以创建一个默认拒绝的网络连接，要求必须经过显式身份验证和授权，才能使用网络并访问相连接的其他资源（图 1）。
从理论到实践：分层零信任验证模式（ZTVP）
为了将这些最佳实践转化为现实，我们利用了分层零信任验证模式（ZTVP）。该验证模式融合了基础架构即代码（IaC）最佳实践与 GitOps 自动化，大幅缩短了专为安全防护和可扩展性而设计的复杂 OpenShift 部署的设置时间。在过去三个月中，ZTVP 项目取得了重大进展，获得了 Tested Tier（已测试层级）认证。
该模式将多个组件整合为一个统一的、GitOps 部署的零信任架构：
- 零信任工作负载身份管理器（ZTWIM）：基于 SPIFFE/SPIRE 项目为工作负载提供短期加密身份。
- HashiCorp Vault：以安全优先的方式存储敏感资产和集群机密，并与 ZTWIM 集成以进行 JWT 身份验证。
- 红帽构建的 Keycloak：管理用户身份验证和联合身份。
- 红帽 Kubernetes 高级集群安全防护：充当智能安全大脑，提供统一的多集群监控、主动式准入控制、实时行为异常检测，以及在我们示例中至关重要的网络策略分析器。
网络策略：最后一道防线
虽然网络策略常被视为零信任的基石，但它们本身并非一项原则，而是一种主动式架构机制，用于强制执行零信任模型的预期结果。红帽概述了零信任的四项核心原则，而精心设计的网络策略能够有效支撑每项原则的实现：
- 微分段：通过在单个 pod 级别管理流量，网络策略本质上将集群划分为细粒度且安全性更高的分段。
- 最小权限访问：默认拒绝的安全态势，确保工作负载仅被授予其正常运行所绝对必需的确切网络权限，多一分都不给。
- 去边界化：安全控制不再局限于集群的“大门”，而是直接部署到工作负载自身周围。
- 假设已入侵：通过主动消除横向攻击路径，严格的入口和出口规则已就位，一旦发生入侵，立即限制安全事件的波及范围。
此外，Kubernetes 网络策略极为重要的一个方面是，它们与所保护的应用 pod 位于不同的控制平面上。这意味着，即便攻击者成功攻陷容器并在该应用内获得了更高权限，也无法轻易地重新定义或绕过限制它们的网络边界。为了增强内部环境的整体安全态势，并真正将这些原则付诸实践，我们必须定义细粒度的网络策略，在 pod 级别同时管控入口和出口流量：
- 入口策略：用于控制传入 pod 的流量，强制执行“服务仅接受来自显式授权源的连接”这一规则。如果集群中的相邻 pod 被攻陷，强大的入口策略可阻止攻击者横向访问您的敏感工作负载。
- 出口策略：用于控制从 pod 传出的流量。其目标是严格限制 pod 可访问的外部或内部资源。如果某个 pod 被攻陷，出口策略能够有效遏制攻击者能力，使其无法窃取数据、执行广泛的网络侦察，或从外部命令与控制服务器下载恶意负载。
default-deny 基础
虽然定义具体的入口和出口规则至关重要，但仅依赖这些规则会留下危险的缺口，让人为错误和欺骗性攻击有机可乘。默认情况下，Kubernetes 以 allow-all 模式运行，这意味着任何未被显式限制的流量都将被放行。如果开发人员忘记应用某项策略，该 pod 就等于门户大开。但风险远不止于无心之失。在供应链攻击中，开发人员可能会在不知情的情况下，被诱骗部署遭到入侵的第三方组件，对暗藏的恶意负载及其后果毫无察觉。
default-deny 策略将这一范式从黑名单机制转变为白名单机制。零信任的核心原则要求每一次交互都必须经过显式授权，因此从逻辑上讲，绝不允许任何隐式访问。通过从一开始就严格阻断所有流量，default-deny 态势营造了一种安全环境：任何意外疏忽（或巧妙伪装、试图回联的恶意容器）都会导致连接被安全地阻断。它迫使您在设计阶段就显式授予访问权限，从而将原本可能悄无声息的灾难性泄露，转变为显而易见且易于修复的部署错误。
这种方法始于一条简单却强大的规则：默认拒绝所有流量。每个命名空间都会收到一个 default-deny 的 NetworkPolicy，除非存在显式允许策略，否则该策略会阻断每个 pod 的入口和出口流量。
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-in-namespace
spec:
podSelector: {}
policyTypes:
- Ingress
- Egress一旦 NetworkPolicy 将命名空间中的某个 pod 作为目标，该 pod 就不再拥有无限制的访问权限。通过定义默认阻断访问的策略，就能与零信任默认拒绝的态势保持一致。
当无法修补时，为何零信任至关重要
设想一个企业场景，类似于臭名昭著的 Log4j 危机，或更近期的 React2Shell 漏洞（CVE-2025-55182）之类的框架冲击：
- 您的应用使用的某个广泛部署的库中，突然披露了一个严重远程代码执行（RCE）漏洞。
- 攻击者只需向受影响服务发送一个特制请求，该漏洞就会允许其完全接管服务器。
- 由于该库深度嵌入您的依赖项中，经过验证的补丁需要数天时间才能完成测试并部署到生产环境中。
对于采用零信任网络策略的企业组织，其影响微乎其微：
- 攻击者入侵任何 pod 后，都能轻松跨任何命名空间访问易受攻击的服务（无横向隔离）。
- 实施 ZTVP 网络策略后：攻击者无法从其他命名空间访问服务（命名空间隔离）。
- 攻击者可以连接到服务上暴露的任何端口，包括关键或管理端口（无端口级过滤）。
- 实施 ZTVP 网络策略后：攻击者无法连接到未被显式允许的端口（端口级过滤）。
- 攻击者可以自由发起出站连接，以窃取数据或建立命令与控制（C2）通道（无出口限制）。
- 实施 ZTVP 网络策略后：攻击者无法将数据泄露到外部端点（出口限制）。
演示：消除攻击路径
我们制作了一个演示视频，直观展示了妥善实施的网络策略如何主动消除攻击路径。最初，我们看到的是一个未采取 default-deny 态势的环境，此时攻击者可以利用供应链漏洞轻松执行大范围侦察，在网络中肆意探测，寻找其他未经修补的组件加以利用。随后我们看到，一旦应用了严格的网络策略，情况便截然不同。
即使攻击者成功入侵了某个 pod，他们侦查网络、扫描漏洞或横向移动的能力也会被完全瓦解。策略将攻击者限制在被攻陷的容器内，从而有效遏制威胁蔓延，为您争取到实施纠正措施所需的关键时间。虽然严格的网络边界并非全面安全策略中唯一的失效保护机制，但它们无疑是构筑最后一道防线的最佳起点。
这个演示展示了网络策略如何将攻击限制在被攻陷的容器内，从而有效遏制威胁蔓延，并为您争取到实施纠正措施所需的关键时间。
全局视野：纵深防御
网络策略只是全面安全策略的其中一层。分层零信任验证模式将这些策略与多种安全机制相结合，包括 SPIFFE/SPIRE 工作负载身份（使用零信任工作负载身份管理器）、Vault 管理的机密、使用身份提供程序（IdP）（如我们默认的红帽构建的 Keycloak）的集中式身份验证，以及红帽 Kubernetes 高级集群安全防护运行时监控。网络策略补全了整个安全图景：即使身份、机密和应用安全防线全部失守，网络层仍能发挥有效的隔离与遏制作用。
但是，如何才能知道网络策略是否真正奏效？又该如何察觉某个已被攻陷的容器是否在反复探测您的内部边界？当零日漏洞利用触发被拒绝的连接时，会发生什么？
我们将在本系列博客文章中解答这些关键问题，探讨分层零信任验证模式如何实施零信任安全实践。以下是后续内容预告：
- 利用红帽 Kubernetes 高级集群安全防护实现主动防御：实施深度运行时监控、自动化网络策略扫描和实时警报，充当您的安全中枢。
- 身份与机密：借助零信任工作负载身份管理器和 Vault 集成，更安全地管理工作负载身份。
- 供应链：通过强制执行内容签名和验证管道任务，实现端到端的软件供应链锁定，确保只有受信任的代码才能进入您的集群。
准备好亲眼见证它的实际效果了吗？无需等待下一篇文章即可开始体验。查看分层零信任验证模式，探索其架构，并亲自尝试网络策略演示。
参考资料
关于作者
Przemysław “Rogue” Roguski is a Security Architect at Red Hat who specializes in shift-left security initiatives focusing on embedding security best practices and attestation into the earliest stages of the SDLC. He contributes security analysis work on Red Hat OpenShift and other OpenShift-related products. He also designs security solutions and processes across Red Hat.
He contributes to the security ecosystem as a member of the CISA SBOM/VEX working groups, an OASIS OpenEoX Technical Committee member and a key contributor to the CWE program.
