Cilium网络策略安全准入评审与数据传输优化 - 第1节
1.1 Cilium 项目背景与定位
Cilium 是一个基于 eBPF（extended Berkeley Packet Filter）的开源项目，旨在为云原生环境（尤其是 Kubernetes）提供高性能的网络、可观测性与安全能力。它由 Isovalent（现已被 Cisco 收购）于 2016 年创建，并于 2021 年正式加入 CNCF（Cloud Native Computing Foundation）成为毕业项目。
Cilium 的核心设计理念是：将 eBPF 程序动态注入 Linux 内核，在不修改内核代码或容器应用的前提下，实现细粒度的网络策略控制、负载均衡与安全隔离。相比传统的 iptables/IPVS 或用户态代理方案，Cilium 能够显著降低数据路径的延迟与 CPU 开销。
- 2016 年：Cilium v1.0 发布，支持 Docker 与 Kubernetes 基础网络策略。
- 2021 年：成为 CNCF 毕业项目，生产部署超过百万节点。
- 2023 年：Cilium Service Mesh 模式 GA，替代 Envoy sidecar 实现 L7 策略。
- 2024 年：Cilium 成为 Kubernetes 社区默认 CNI 选项之一，被 AWS EKS Anywhere、Google GKE、Azure AKS 等主流云厂商原生集成。
1.2 核心概念：eBPF、Identity、Endpoint
1.2.1 eBPF：内核可编程的基石
eBPF 允许用户在 Linux 内核中安全地运行沙箱化程序，而无需加载内核模块或修改内核源码。Cilium 利用 eBPF 实现以下关键能力：
- 网络数据包过滤与转发：在 XDP（eXpress Data Path）或 TC（Traffic Control）钩子点执行策略决策。
- 系统调用跟踪：监控容器进程的系统调用行为，用于安全审计与异常检测。
- 负载均衡：通过 eBPF 实现高效的 ClusterIP/NodePort/LoadBalancer 转发，避免 iptables 规则膨胀。
- 可观测性：通过 eBPF Map 收集网络流、DNS 请求、HTTP 指标等数据。
1.2.2 Identity：基于身份的网络安全模型
Cilium 使用 Security Identity（安全身份）替代传统的 IP 地址作为网络策略的标识基础。每个 Kubernetes Pod 或外部实体在启动时会被分配一个 24 位的数字身份，该身份与标签选择器（Label Selector）绑定。
| 特性 | 传统 IP 策略 | Cilium Identity 策略 |
|---|---|---|
| 标识粒度 | IP 地址（静态/动态） | 标签组合（动态、语义化） |
| Pod 重启后 | IP 变化，策略需重新匹配 | Identity 不变，策略持续生效 |
| 跨集群通信 | 依赖 IP 路由与 NAT | Identity 全局唯一，策略随身份迁移 |
| 策略更新延迟 | 秒级（iptables 规则重载） | 毫秒级（eBPF Map 原子更新） |
1.2.3 Endpoint：策略执行的最小单元
在 Cilium 中，Endpoint 代表一个可以被网络策略管理的网络端点。通常一个 Kubernetes Pod 对应一个 Cilium Endpoint，但也可以是主机网络命名空间或外部工作负载。每个 Endpoint 包含以下关键属性：
- Identity：该 Endpoint 当前绑定的安全身份。
- Labels：从 Kubernetes 继承的标签，用于身份计算。
- Policy Map：eBPF 中存储的允许/拒绝规则集合。
- State：ready（就绪）、waiting-for-identity（等待身份）、disconnected（断开）等。
waiting-for-identity 状态时，Cilium 会默认拒绝所有进出流量，直到身份分配完成。这是防止未授权访问的关键安全机制。
1.3 Cilium 与 Kubernetes 的集成架构
Cilium 以 DaemonSet 形式部署在每个 Kubernetes 节点上，通过 CRD（Custom Resource Definition）扩展 Kubernetes API，实现网络策略、服务负载均衡与可观测性的统一管理。下图展示了 Cilium 在 Kubernetes 集群中的核心组件与数据流。
1.3.1 核心组件职责
| 组件 | 部署方式 | 核心职责 |
|---|---|---|
| Cilium Agent | DaemonSet（每节点一个） | 管理本地 eBPF 程序、同步 Endpoint 状态、执行策略下发、收集指标 |
| Cilium Operator | Deployment（通常 1-2 副本） | 全局身份分配、CRD 状态协调、节点间身份同步、故障恢复 |
| Cilium CLI | 二进制工具（可选） | 策略验证、故障排查、eBPF 调试、流量抓取 |
| Hubble | DaemonSet + Deployment | 可观测性层：流日志、服务拓扑、DNS 监控、HTTP 指标 |
1.3.2 数据路径：从 Pod 到 Pod 的 eBPF 转发
当集群内 Pod A（节点 1）访问 Pod D（节点 2）时，Cilium 的数据路径如下：
- 出站：Pod A 的 veth 对将数据包送入主机命名空间，Cilium 的 eBPF TC 程序在
cilium_host接口捕获数据包。 - 策略检查：eBPF 程序根据数据包的源 Identity（Pod A 的身份）和目标 Identity（Pod D 的身份）查询 Policy Map，判断是否允许。
- 封装/转发：如果允许，Cilium 根据路由模式（直接路由或隧道）将数据包转发到目标节点。默认使用 直接路由（Direct Routing），通过节点物理网卡发送，无需额外封装。
- 入站：目标节点的 eBPF 程序在物理网卡或隧道接口捕获数据包，再次执行策略检查，然后通过 veth 对交付给 Pod D。