4. Cilium 网络策略基础:L3/L4 网络策略、L7 HTTP 策略、基于 Identity 的安全组
Cilium 的网络策略模型基于 Kubernetes NetworkPolicy 进行了深度扩展,不仅支持传统的 L3/L4 层访问控制,还引入了基于 Identity(身份) 的微隔离以及 L7 应用层 的精细化策略。本章将系统讲解这三种策略的核心原理、配置方法及适用场景。
4.1 基于 Identity 的安全组:Cilium 的微隔离基石
传统 Kubernetes NetworkPolicy 依赖 IP 地址 或 标签选择器 来定义策略。Cilium 在此基础上引入了 Identity(身份) 概念,将每个 Pod 或端点(Endpoint)的标签组合映射为一个全局唯一的 安全身份。策略不再绑定 IP,而是绑定 Identity,从而解决了 IP 动态变化带来的策略漂移问题。
核心优势: Identity 机制使得策略在 Pod 重启、扩缩容或节点迁移时自动生效,无需重新计算规则,极大提升了大规模集群下的策略管理效率。
Identity 的生成与分配流程
- 标签提取: Cilium Agent 监听 Pod 创建事件,提取其 Labels(如
app=frontend)。 - 身份计算: Agent 将标签集合发送到 Cilium Operator 或本地缓存,通过哈希算法生成一个 16 位的 Security Identity(如
12345)。 - 策略映射: 所有网络策略规则中的
fromEndpoints/toEndpoints字段最终被解析为 Identity 列表。 - eBPF 加载: 生成的 Identity 映射表被加载到节点 eBPF Map 中,数据包转发时直接匹配 Identity 而非 IP。
| 对比维度 | 传统 NetworkPolicy(IP/标签) | Cilium Identity 策略 |
|---|---|---|
| 策略粒度 | 基于 Pod 标签或 IP 段 | 基于标签组合的全局唯一身份 |
| IP 变化适应性 | 需重新计算规则或依赖 IP 池 | 自动适配,Identity 不变 |
| 大规模性能 | 规则数量随 Pod 数量线性增长 | Identity 聚合,规则数量可控 |
| 跨集群支持 | 困难,需全局 IP 路由 | 原生支持,Identity 全局唯一 |
最佳实践: 在定义 CiliumNetworkPolicy 时,优先使用
fromEndpoints / toEndpoints 结合标签选择器,而非 fromCIDR / toCIDR,以充分利用 Identity 的弹性优势。
4.2 L3/L4 网络策略:传统网络层的访问控制
L3/L4 策略控制 IP 地址(L3)和 端口/协议(L4)维度的流量。Cilium 完全兼容 Kubernetes 原生 NetworkPolicy,同时通过 CiliumNetworkPolicy CRD 提供了更丰富的匹配能力。
4.2.1 核心字段与匹配规则
fromEndpoints/toEndpoints: 基于 Identity 的端点选择器,推荐使用。fromCIDR/toCIDR: 基于 IP 段的匹配,适用于外部流量或非 Kubernetes 节点。fromCIDRSet/toCIDRSet: 支持 CIDR 列表与例外规则。ports: 定义目标端口与协议(TCP/UDP/SCTP)。
注意: 当同时使用
fromEndpoints 和 fromCIDR 时,策略规则之间是 OR 关系,即满足任一条件即允许。如需 AND 逻辑,需拆分为多条规则。
4.2.2 典型配置示例:允许 frontend 访问 backend 的 8080 端口
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
name: allow-frontend-to-backend
spec:
endpointSelector:
matchLabels:
app: backend
ingress:
- fromEndpoints:
- matchLabels:
app: frontend
toPorts:
- ports:
- port: "8080"
protocol: TCP
4.3 L7 HTTP 策略:应用层的精细化管控
L7 策略允许在 HTTP 协议 层面进行精细化控制,包括 请求路径、方法、Host 甚至 Header 的匹配。Cilium 通过 Envoy 代理 或 eBPF 原生解析 实现 L7 策略,无需 Sidecar 即可完成。
4.3.1 L7 策略的生效机制
- 流量拦截: Cilium Agent 通过 eBPF 将目标端口(如 80/443)的流量重定向到本地 Envoy 进程。
- 协议解析: Envoy 解析 HTTP 请求,提取 Method、Path、Host 等字段。
- 策略匹配: 将解析结果与
httpRules规则进行匹配,允许或拒绝请求。 - 转发/拒绝: 匹配成功的请求转发至目标 Pod,失败则返回 403 Forbidden。
| L7 匹配字段 | 描述 | 示例 |
|---|---|---|
method |
HTTP 方法(GET/POST/PUT/DELETE 等) | GET |
path |
请求路径,支持精确匹配与通配符 | /api/v1/users |
host |
请求的 Host 头 | api.example.com |
headers |
自定义 Header 匹配(Key: Value) | X-Auth-: secret |
4.3.2 典型配置示例:仅允许 GET /api/public 路径
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
name: allow-public-api
spec:
endpointSelector:
matchLabels:
app: api-server
ingress:
- fromEndpoints:
- matchLabels:
app: frontend
toPorts:
- ports:
- port: "80"
protocol: TCP
rules:
http:
- method: GET
path: /api/public
性能提示: L7 策略会引入额外的代理开销(Envoy)。对于高吞吐场景,建议仅对关键路径启用 L7 策略,其余流量使用 L3/L4 策略控制。
4.4 策略层级与优先级
Cilium 支持多种策略类型,它们之间存在明确的优先级与覆盖关系:
- Kubernetes NetworkPolicy: 原生策略,仅支持 L3/L4,优先级最低。
- CiliumNetworkPolicy: 增强策略,支持 L3/L4/L7,可覆盖原生策略。
- CiliumClusterwideNetworkPolicy: 集群级策略,适用于跨 Namespace 或全局管控。
当多条策略同时匹配时,Cilium 遵循 白名单(Allow) 模型:只要有一条策略明确允许,流量即被放行;若没有任何策略允许,则默认拒绝。
关键原则: Cilium 策略是 白名单 机制。未显式允许的流量默认被拒绝。建议先创建一条 Deny All 基线策略,再逐步开放必要端口。
4.5 实战:从 L3/L4 到 L7 的策略演进
以下是一个典型的策略演进路径,适用于微服务架构:
- 阶段一: 使用 L3/L4 策略,仅允许特定 Service 端口(如 80/443)互通。
- 阶段二: 引入 Identity 策略,将 IP 白名单替换为标签选择器,提升弹性。
- 阶段三: 对关键 API 路径启用 L7 HTTP 策略,限制 Method 和 Path,防止未授权访问。
- 阶段四: 结合监控指标(如
cilium_policy_l7_total)分析策略命中率,持续优化规则。
| 演进阶段 | 策略类型 | 管控粒度 | 适用场景 |
|---|---|---|---|
| 阶段一 | L3/L4 | IP + 端口 | 基础隔离,快速上线 |
| 阶段二 | Identity | 标签组合 | 动态环境,减少策略漂移 |
| 阶段三 | L7 HTTP | Method + Path + Header | API 网关、微服务安全 |
| 阶段四 | 监控 + 策略 | 指标驱动优化 | 持续合规与性能调优 |
推荐工具: 使用
cilium policy validate 命令验证策略 YAML 语法,使用 cilium policy trace 模拟流量路径,快速定位策略问题。