【Cilium / eBPF】透明加密：WireGuard / IPsec 的路径税与失败模式

合规口头禅是「东西向也要加密」。落到 Cilium，问题变成：谁生成密钥、哪些包进隧道、加密发生在策略/LB 的哪一侧、以及发现滞后时会不会明文打出去。 本篇写 Cilium 集成与失败模式；WireGuard 协议与内核实现外链站内 wireguard 系列，不在这里重讲 Noise 握手。

本文是「Cilium / eBPF 数据面内核」系列第 9 篇（共 16 篇）。→ 系列目录

篇目	核心内容
第 8 篇 · Hubble 信号	观测与丢包错位
第 9 篇 · 透明加密	WG/IPsec 路径税与失败
第 10 篇 · L7 Mesh 边界	可选 Envoy

版本锚定：Cilium v1.20.0 — Transparent Encryption、WireGuard、IPsec。v1.20 亦提及 ztunnel 加密（Beta）——本篇不展开。无集群不伪造 wg show / 抓包结论。

一、透明加密在栈上的位置

Cilium 透明加密的目标是：对工作负载 尽量无感 地加密「发往远端 Cilium 管理端点 / 主机」的流量。判断「要不要加密」依赖与策略类似的信息面——目的 IP 是否已映射到远端 Cilium 端点或节点身份（官方 Known Issues 原文叙述）。

flowchart LR
  pod["Pod traffic"] --> policy["Policy / LB / CT"]
  policy --> enc{"Remote Cilium\nendpoint known?"}
  enc -->|"yes"| tun["WireGuard or IPsec"]
  enc -->|"not yet"| plain["May leave plaintext"]
  tun --> wire["Node fabric"]

因此加密不是「网卡上无条件 IPsec esp=all」，而是 与 identity/ipcache 耦合的条件封装。这解释了两类事故：

1. 新节点 / 新 Pod 信息未扩散前，首批包可能明文出站；
2. 关了到 world 的出站或开启 strict mode 后，行为与「默认全加密」直觉不符。

二、WireGuard 路径：密钥、注解与覆盖表

2.1 控制面

启用 encryption.enabled=true 且 encryption.type=wireguard（或 ConfigMap enable-wireguard）后，每节点 agent：

1. 生成本地密钥对；
2. 把公钥写到 CiliumNode 注解 network.cilium.io/wg-pub-key；
3. 与其他已知节点建立 WireGuard peer，用对端公钥加解密发往该节点上 Cilium 管理端点的流量。

默认覆盖：节点间 Pod→Pod。文档另提供 node encryption（encryption.nodeEncryption=true，Beta 叙事）：扩展到 node↔︎node、pod↔︎node、node↔︎pod；控制面节点默认 opt-out，以免密钥更新窗口锁死 API 访问。生产启用前必须读当前版本的例外表（哪些通信对仍明文）。

2.2 与站内 WireGuard 系列的分工

Cilium 把 WG 当成 节点隧道与密钥分发自动化，不是让每个 Pod 跑 wg-quick。

2.3 路径税（机制级，非自测排名）

税来自可核对的机制，不来自未跑 benchmark：

• CPU：每包加密/解密（内核 WG）；
• MTU：封装开销迫使跨节点有效载荷下降，不分片应用更敏感；
• 连接建立：peer 与密钥注解传播之前的短暂异常；
• 排障税：中间盒看不到明文五元组；Hubble 需声明观测点（第 8 篇）。

是否「值得」取决于威胁模型：云 VPC 内威胁是否包含链路窃听；若合规只要求「存储加密」，透明加密可能是纯税。选型终章再收；本篇只要求把税说清楚。

三、IPsec 路径：对比坐标

IPsec 透明加密是另一实现叶：密钥与 SPI 管理、XFRM 状态、与路由模式的组合约束与 WG 不同。v1.20 文档维护独立 IPsec 章；CHANGELOG 显示若干旧选项移除（如部分 strict/overlay 弃用项）——升级时按 v1.20 文档核对，勿沿用 1.14 时代博客旗标。

相对 WG 的工程对照（机制，非性能排行）：

选择时常被「哪个更快」带偏；先问团队能否操作对应失败面（XFRM 状态卡死 vs WG peer 缺失）。

四、Strict mode：补洞与新洞

官方 Transparent Encryption 章把已知问题钉得很硬：

出站加密依赖「目的是否为远端 Cilium 端点」的同一类发现机制；在学到映射之前，若策略允许出集群，初始包可能明文离开节点。

缓解：

1. 策略：禁止或收紧到 reserved:world 的出站，或只用受信 toCIDR / toFQDN；
2. encryption.strictMode.egress：对配置的 CIDR（文档限制：IPv4；IPv6 不受该 egress strict 保护）强制加密出站；新端点信息仍须先传播；
3. encryption.strictMode.ingress：丢弃「声称是集群内、但不是从 WG 隧道进来」的入站，缓解明文注入；仅 WG；不保护 node-to-node 加密路径的全部语义；要求 Cilium 管到所有可承载 Pod 流量的接口；CNI chaining 当前不支持（文档指向上游 issue）。

Strict mode 把「明文窗口」换成「传播未完成则失败」——可用性与机密性的显式折中。排障表象从「偶发明文」变为「新 Pod 短期内不通」。

五、失败模式表

命令语义：

# 语义：确认加密功能与模式出现在状态面
cilium status
# 节点上检查 WireGuard 接口与 peer（需权限；勿伪造输出）
# wg show
# ip link show type wireguard

六、与策略、Service、L7 的交界

• 策略：加密不替代 NetworkPolicy。机密性 ≠ 授权。明文窗口缓解往往 靠策略收紧 world。
• Service / DSR：南北向封装与 DSR dispatch、云反欺骗叠加时，故障图更陡；先固定 LB mode 再开加密。
• L7 Envoy：重定向到节点代理的路径是否二次封装，取决于流量是否仍被判为「远端节点 Cilium 流量」；排障要标清「Pod→Envoy→Pod」是否同节点（同节点常不经跨节点 WG）。

七、谱系、争论与开放问题

谱系：IPsec（IETF 长期标准）→ 主机 VPN 运维模型 → WireGuard（Donenfeld, NDSS 2017 WireGuard: Next Generation Kernel Network Tunnel）以简单密钥与内核实现降低运维面 → Cilium 把 WG/IPsec 接到 K8s 节点身份与 ipcache，做透明加密而非 per-pod VPN。

争论：

1. 链路加密 vs 应用 TLS：WG 防链路窃听；不能代替服务身份与 HTTP 级鉴权。双层都开时税叠加。
2. 默认加密 vs 显式窗口：自动加密易漏「未发现远端」窗口；strict mode 更安全也更脆。
3. WG vs IPsec：实现与运维文化差；用未实测数字宣称全面胜出违反本站证据规则。

开放问题：

1. 发现窗口与策略/strict 的组合能否形式化成「可证明不明文出站」的部署配置集？
2. 加密与 Hubble 采样对齐后，如何避免「合规已加密」但排障只能盲飞？（第 8、12 篇）

八、威胁模型：加密在防什么、不防什么

透明加密回答的是：节点之间链路上的窃听与篡改（在密钥与实现正确的前提下）。它不回答：

• Pod 被攻破后的横向凭证窃取（那是身份与策略问题）；
• 应用明文 HTTP 被对端合法进程阅读（需要 TLS 或网格 mTLS）；
• 主机内核已被控时的密钥泄露（密钥在节点信任域内）。

因此「开了 WireGuard = 零信任完成」是范畴错误。更干净的分层是：链路（本篇）/ 工作负载身份（策略与可选网格）/ 应用鉴权。重复加密可以叠加税，却不能用一层冒充三层。

运维上还有 密钥轮换与节点生命周期：节点滚动时公钥注解更新，peer 列表随之变。轮换窗口与 strict mode 叠加时，短时不通优先查 peer 是否收敛，而不是先改业务代码。控制面节点默认不参与 node encryption，是为了保留「还能进集群修加密」的逃生舱——关掉 opt-out 前要有带外通道。

相对只依赖云厂商 VPC 加密的选项：Cilium 透明加密把控制权留在集群配置里，也把失败面留在集群里。若组织已强制所有流量走专用加密线路且禁止旁路，重复开 WG 可能只买 MTU 税；若多租户共享二层或主机网络不可信，则税是必要的。

8.1 与隧道模式、native routing 的组合

集群本身若已用 VXLAN/Geneve 做 Pod 网络封装，再套 WG/IPsec，等于 双重封装：MTU 与 CPU 税叠加，排障时抓包层级更多。native routing 下透明加密往往更「干净」，但仍受云路由与安全组约束。选型时应在拓扑图上画出「业务载荷外面包了几层」，而不是只在 Helm values 里叠布尔开关。

IPsec 路径上，XFRM 状态与策略是否与 Cilium 预期一致，是经典难点：手工 ip xfrm 残留、或与主机自建 VPN 抢策略，会导致「部分节点加密、部分明文」的撕裂态。WG 路径上则更常见 peer 缺失与 MTU 问题。两种撕裂态在 Hubble 上都可能表现为间歇性跨节点失败，而集群内同节点流量完全正常——这是加密故障的指纹之一。

升级到 v1.20 时，对照 CHANGELOG 删除的弃用旗标，避免旧 GitOps 仓库静默带上无效键：看起来「加密仍开启」，实际行为已变。配置漂移比内核 bug 更常见。

从合规审计角度，审计员常问「是否全流量加密」。诚实答案必须带条件：默认 Pod 跨节点、是否含节点流量、strict mode 是否打开、发现窗口是否接受、IPv6 是否在 egress strict 保护外。把这些条件写进架构说明，比只贴一张「encryption.enabled=true」截图更经得起追问。

同节点东西向流量通常不经跨节点 WG：加密税主要打在跨节点路径上。容量规划若用「全网平均 CPU」掩盖「跨 AZ 节点对」热点，会在第一次跨区演练才暴露。把加密税按路径类型记账，比按集群平均值记账更接近真实。密钥与注解的 GitOps 可见性也有限：公钥在 CiliumNode 上，私钥在节点本地——备份与泄露模型要按此设计。

九、本篇边界

不写：ztunnel Beta 全书、IPsec 每个 XFRM 旗标、伪造加解密 pps。
密码学与内核 WG 细节见 wireguard/。下一篇只划 L7 / Mesh 边界：何时必须把包送进 Envoy，何时不该指望 Cilium 替代 sidecar/Ambient。

一句话收束：Cilium 透明加密是挂在 identity 发现上的条件隧道；税在 CPU/MTU/排障，险在传播窗口与接口覆盖——strict mode 换的是失败模式，不是免费机密性。

参考资料

官方文档（A）

• Cilium v1.20 — Transparent Encryption — 已知问题、strict mode
• Cilium v1.20 — WireGuard Transparent Encryption
• Cilium v1.20 — IPsec Transparent Encryption

论文（A）

• Jason A. Donenfeld, WireGuard: Next Generation Kernel Network Tunnel, NDSS 2017

站内

• WireGuard 系列索引
• 第 8 篇 · Hubble 信号
• 第 2 篇 · Identity

→ 上一篇：Hubble 信号 · 系列目录 · 下一篇：L7 与 Mesh 边界