大家好！您是否正在为Kubernetes环境中的网络安全而烦恼？🤔 许多人可能正在使用基于eBPF的强大网络/安全解决方案 Cilium。您是否曾努力创建并应用了CiliumNetworkPolicy，却发现“咦？为什么策略没有生效？”或者“我什么都没做，为什么所有通信都被阻止了？”
今天，我们将深入探讨一个许多人容易忽略但却决定整个集群安全级别的关键设置：Cilium的策略执行模式(Policy Enforcement Mode)。仅此一项设置，您的集群就可能成为坚不可摧的堡垒，也可能变成敞开的大门！🚪
🌐 整体概览：决定安全起点的总开关
Cilium的策略执行模式是一个应用于整个集群的全局设置。它就像为建筑物的所有门设置基本规则一样。它是一个总开关，决定是“默认锁定所有门？(Default Deny)”还是“默认打开所有门？(Default Allow)”。
此模式主要分为三种，每种的运行方式和安全级别都完全不同。现在我们来逐一了解。
1. always 模式: 🏰 铜墙铁壁！零信任的开端
这是最强大、最安全的模式。顾名思义，它始终执行策略。
- 工作方式: 对集群内的所有Pod默认应用“拒绝所有通信 (Default Deny)”策略。这意味着任何未通过CiliumNetworkPolicy明确允许的流量都将被无情地阻止。
- 比喻: 这是一座所有门都紧锁的尖端安全大楼。要打开紧锁的门，必须有明确规定谁可以通过哪扇门进入的门禁卡（策略）。
- 何时使用？:
- 安全性至关重要的生产环境
- 希望从一开始就实现零信任(Zero Trust)网络模型时
- 希望从根本上杜绝因失误造成的安全漏洞时
注意！ ⚠️ 如果在生产环境中突然应用此模式，所有没有明确允许策略的服务之间的通信可能会立即中断。充分的测试和策略准备是必不可少的！
2. never 模式: 🤠 自由的法外之地？其实一切尽在计划中！
顾名思义，此模式从不执行策略。
- 工作方式: 即使您创建了CiliumNetworkPolicy资源，Cilium也会完全忽略它们。所有Pod都可以自由地相互通信。Cilium纯粹执行CNI（网络接口）、服务网格和负载均衡功能。
- 比喻: 这是一个没有墙壁或门的巨大开放式办公室。任何人都可以自由地在任何地方移动。
- 何时使用？:
- 当您希望专注于基于eBPF的高性能网络或可观测性(Observability)功能，而不是Cilium强大的网络策略功能时
- 当网络策略由其他安全解决方案（例如：Istio）集中管理时
- 在需要暂时解决策略执行问题并查明原因的调试场景中
此模式并非意味着“放弃安全”。它可能是一种战略选择，将策略执行责任委托给其他地方，或出于特定目的而有意禁用它。
3. default 模式: 🤔 条件式应用，渐进式安全强化的关键
这可能是最令人困惑但也是最灵活的模式。它也是安装Cilium时的默认值。
- 工作方式: 此模式是条件式运行的。
- 未被任何CiliumNetworkPolicy的目标(Selector)选中的Pod将允许所有流量 (Default Allow)。
- 被一个或多个CiliumNetworkPolicy选中的Pod，从那一刻起，默认情况下所有流量都将被阻止 (Default Deny)，并且只有根据该策略中明确规定的规则才允许通信。
- 比喻: 这是一座平时所有门都敞开的普通大楼。但是，一旦在某个办公室门前贴上“安全区域”的牌子（策略），该办公室就会变成一个只有授权人员才能进入的受控区域。其他门仍然是敞开的。
- 虽然不是官方名称…: 最能描述此模式工作方式的词就是 Conditional（条件式）。尽管配置文件中没有写conditional，但用这个词来记忆会更容易理解。
通过代码理解 default 模式
我们来亲自看看这个模式是如何运作的？Cilium 配置通常在名为 cilium-config 的 ConfigMap 中管理。
# cilium-config ConfigMap 的一部分
apiVersion: v1
kind: ConfigMap
metadata:
name: cilium-config
namespace: kube-system
data:
# 这里就是设置策略模式的地方！
policy-enforcement-mode: "default" # 可更改为 "always", "never"现在，我们通过一个场景来了解 default 模式的运作。假设有 frontend、backend、database 三个 Pod。
场景 1: 没有策略时
当 policy-enforcement-mode 为 default 且没有任何 CiliumNetworkPolicy 时，所有 Pod 都可以自由地相互通信。
frontend <---> backend (O)
frontend <---> database (O)
backend <---> database (O)场景 2: 添加保护 backend 的策略
现在，我们来添加一个策略，只控制进入 (ingress) backend Pod 的流量。这个策略只允许来自 frontend Pod 的访问。
# raw-data: CiliumNetworkPolicy 示例
apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
name: backend-policy
namespace: default
spec:
endpointSelector:
matchLabels:
app: backend # 🎯 此策略仅适用于 app=backend 的 Pod。
ingress:
- fromEndpoints:
- matchLabels:
app: frontend # 🔑 仅允许来自 app=frontend Pod 的访问当这个策略应用的那一刻，奇妙的变化发生了！✨
- backend Pod: 由于它被策略的 endpointSelector 选中，因此切换到“安全模式”。现在，只有带有 app: frontend 标签的 Pod 才能访问 backend。
- frontend、database Pod: 由于它们未被任何策略选中，因此仍然保持“默认允许”状态。
结果如下：
frontend ---> backend (O, 정책에 의해 허용)
database ---> backend (X, 정책에 의해 차단)
# frontend 和 database 不受策略影响，因此可以自由通信
frontend <---> database (O)正如所见，default 模式是一种非常实用的方法，它可以在不中断整个集群通信的情况下，从重要的应用程序开始逐步加强安全性。
🧐 一目了然地比较并做出正确选择
| 模式 | 运作方式 | 安全级别 | 推荐使用场景 |
|---|---|---|---|
| always | 所有 Pod 默认拒绝 (Default Deny) | 🔒 最高 | 生产环境，零信任环境 |
| default | 仅对选中的 Pod 默认拒绝 (Conditional Deny) | ⚠️ 中等 | 渐进式安全引入，开发/测试环境 |
| never | 忽略所有策略，允许所有流量 (Always Allow) | 🔓 无 | 调试，策略由其他工具管理时 |
结论：为您的集群穿上合适的衣服
Cilium的策略执行模式不仅仅是一个简单的配置值，它是一个决定集群整体安全理念的重要选择。
- 如果您想要最高级别的安全性，请选择 always。
- 如果您想逐步引入安全性，请选择 default。
- 如果您有特殊目的（例如调试），请选择 never。
现在就检查您的集群设置。它正在以哪种模式运行？希望本文能帮助您为您的Kubernetes环境制定最合适的安全策略！💪
发表回复