Cilium mTLS 加密为 Kubernetes 中的 Pod 到 Pod 流量提供透明、相互 TLS（mTLS）加密和身份验证，无需应用程序更改或引入任何额外的网络堆栈。
它可确保在交换任何流量之前，对源工作负载和目标工作负荷进行加密身份验证。 此方法为 Kubernetes 工作负载启用零信任网络模型。
所有加密和身份验证都发生在应用程序层下方，这意味着无需修改、重新生成或重启工作负载即可从 mTLS 中受益。
AKS 的 Cilium mTLS 加密是 高级容器网络服务（ACNS） 功能集的一部分，其实现基于 Cilium。
Important
AKS 预览功能可在自助服务和自愿选择的基础上启用。 预览版按“现状”和“视供应情况”提供，它们不包括在服务级别协议和有限保证范围内。 AKS 预览功能是由客户支持尽最大努力部分覆盖。 因此，这些功能并不适合用于生产。 有关详细信息，请参阅以下支持文章：
Architecture
概括而言，Cilium mTLS 通过结合标识颁发、透明流量拦截和工作负载级加密强制来保护流量。
为每个工作负荷分配一个派生自 Kubernetes 属性（如命名空间和 ServiceAccount）的加密标识。 启动 Pod 到 Pod TCP 流量时，会在节点级别以透明方式截获流量。 然后，在转发到目标工作负荷之前，使用相互 TLS 对流量进行身份验证和加密。
该系统由三个合作组件组成：
- SPIRE - 提供工作负荷标识和证书颁发。
- ztunnel - 在数据平面中强制实施 mTLS。
- Cilium - 在端口 15001 上安装将出站流量重定向到 ztunnel 的 iptables 规则。
这些组件共同确保在整个群集中以透明且一致的方式进行身份验证和加密。
标识和身份验证模型
Cilium mTLS 使用基于 SPIFFE 工作负荷标识的相互身份验证。
每个工作负载分配一个来源于以下内容的 SPIFFE 标识（SVID）：
- Kubernetes 命名空间
- Kubernetes ServiceAccount
当工作负荷启动连接时：
- 源 ztunnel 检索工作负荷的有效 SVID。
- 目标 ztunnel 节点验证所呈现的身份。
- 双方在允许流量流动之前完成相互验证。
身份验证决策基于工作负荷标识，而不是网络位置。 此设计可确保：
- 只有经过身份验证的工作负荷才能进行通信。
- 身份在重新安排和扩展过程中保持一致。
- 信任不依赖于 IP 寻址或网络拓扑。
加密流程
身份验证成功后，使用相互 TLS 保护流量。
- 截获在 Pod 网络命名空间内的流量并将其重定向到本地 ztunnel 实例。
- 源 ztunnel 向目标 ztunnel 发起 mTLS 会话。
- 证书是交换和验证的。
- 在传输之前对应用程序数据进行加密。
- 目的地 ztunnel 会解密流量并将其传送到目标 Pod。
注册 Pod 中的每个数据包都经过加密。 没有纯文本窗口，也没有删除的第一个数据包。 连接通过 ztunnel 内联保持，直到 mTLS 隧道建立完成后，流量才通过 HBONE（HTTP/2 CONNECT）隧道进行双向传输。
核心组件
SPIRE （身份和信任）
SPIRE （SPIFFE 运行时环境）负责工作负荷标识和证书管理。 SPIRE 有两个主要组件：SPIRE 服务器和 SPIRE 代理。
SPIRE 服务器充当群集证书颁发机构（CA）。 它仅向被允许接收身份的工作负荷颁发短期 X.509 证书（SVID）。 它使用 Kubernetes 原生证明，将标识绑定到命名空间和 ServiceAccount 等属性，而不是将标识绑定到 IP 地址等网络属性。
在每个节点上， SPIRE 代理 负责向 SPIRE 服务器证明节点，并代表本地工作负荷检索证书。 工作负荷仅与 SPIRE 代理通信，并且从不直接与 SPIRE 服务器通信。
SPIRE 确保每个工作负载标识都是：
- 可加密验证。
- 自动发出并轮换。
- 绑定到 Kubernetes 基元，而不是 IP 地址。
- 在 Pod 重启和重新调度时保持稳定。
此标识基础可实现与拓扑无关的强信任决策。
Ztunnel （mTLS 数据平面）
Ztunnel 是一个轻型节点级第 4 层代理，负责在工作负荷之间强制实施 mTLS。 它作为 DaemonSet 运行，每个节点有一个实例，因此不需要每个 Pod 的 Sidecar 代理。
当工作负荷启动 TCP 连接时，ztunnel 会与对等节点的 ztunnel 实例建立相互身份验证的 TLS 会话。 它使用从 SPIRE 获取的证书在允许流量流动之前对连接的两端进行身份验证。
Ztunnel 强制实施以下保证：
- 连接双方必须提供有效的工作负荷证书。
- 证书根据群集信任域进行验证。
- 流量始终在传输过程中加密。
- 注册的工作负载不允许使用纯文本备选方案。
通过在节点级别集中执行 mTLS，ztunnel 提供强大的安全属性，而不会增加每个 Pod 的操作开销。
Cilium （重定向规则和 Pod 注册）
Cilium 负责使 mTLS 对应用程序透明。
当命名空间标记为“io.cilium/mtls-enabled=true”时，Cilium 代理将注册该命名空间中的所有 Pod。 它输入每个 Pod 的网络命名空间，并安装 iptables 规则，用于将出站流量重定向到端口 15001 上的 ztunnel。
Cilium 还会将工作负荷元数据（如 Pod UID）传递给 ztunnel，并与 Cilium 运算符集成，以向 SPIRE 注册工作负荷标识。
从应用程序的角度来看，通信继续使用标准 TCP 套接字。 加密和身份验证完全在应用程序层下强制实施，无需更改代码。
范围和信任边界
命名空间注册
Cilium mTLS 是可选的，并限制在命名空间级别。 必须显式标记命名空间才能启用 mTLS 强制实施。 启用后，该命名空间中的所有 Pod 都会受到强制身份验证和加密的约束。
未注册命名空间中的 Pod 不会受到影响。 此设计允许跨环境进行增量推出和暂存采用。
执行模型
只有当两个 Pod 都加入时，才应用加密。 已注册工作负载和非注册工作负荷之间的流量以纯文本形式继续，而不会造成连接问题或硬故障。
| 来源 | 目的地 | Result |
|---|---|---|
| 已报名 | 已报名 | 加密 （基于 HBONE 的 mTLS） |
| 已报名 | 未加入 | 纯文本传递 |
| 未加入 | 已报名 | 纯文本 （由 ztunnel 捕获，但未加密） |
| 未加入 | 未加入 | 普通 Cilium 数据路径 （无 ztunnel 参与） |
注意事项和限制
- 此功能仅适用于启用了 高级容器网络服务（ACNS） 的由 Cilium 提供支持的 Azure CNI 群集。
- mTLS 在命名空间级别启用。 已注册命名空间中的所有 Pod 都参与 mTLS。 不支持 Pod 级选择加入或选择退出。
- Cilium mTLS 当前保护基于 TCP 的 Pod 到 Pod 流量。 它当前不会加密或对其他协议（包括 UDP）进行身份验证。
- 在当前阶段，mTLS 不支持 L4/L7 网络策略强制实施。
- 无法引入自定义 CA。 SPIRE 充当群集证书颁发机构并管理证书颁发和轮换。
- 不支持在同一群集上同时启用 mTLS 和 WireGuard。
- 不支持启用 Istio 和 Cilium mTLS 加密。
- 不支持跨群集流量的 mTLS 加密。
- 集成需要内核中的 iptables 支持，并且不能用于不支持 iptables 的环境（例如某些最小化的容器运行时）。
- 没有网络命名空间路径（如主机网络 Pod）的 Pod 无法在 ztunnel 中注册，并在注册过程中被排除。
后续步骤
了解如何在 AKS 上应用 Cilium mTLS 加密 。
有关 Azure Kubernetes 服务的高级容器网络服务（AKS）的详细信息，请参阅 Azure Kubernetes 服务的高级容器网络服务（AKS）是什么？。