Cilium mTLS 加密（公開預覽版）

Cilium mTLS 加密在 Kubernetes 中為 Pod 到 Pod 流量提供透明、相互的 TLS (mTLS) 加密與驗證，且無需應用程式變更或引入任何額外的網路協定堆疊。

它確保來源與目的地工作負載在交換任何流量前都經過加密驗證。此方法使 Kubernetes 工作負載能建立零信任網路模型。

所有加密與認證都在應用層以下進行，意味著工作負載不需要修改、重建或重新啟動，也能享受 mTLS。

針對 AKS 的 Cilium mTLS 加密是先進容器網路服務（ACNS）功能集的一部分，其實作基於 Cilium。

這很重要

AKS 預覽功能可透過自助服務，以加入方式使用。預覽是「依現況」及「可用時」提供的，並不包括在服務等級協定和有限保固之內。客戶支援部門會盡最大努力，部分支援 AKS 預覽。因此，這些功能不適合實際執行用途。如需詳細資訊，請參閱下列支援文章：

建築

在高層次上，Cilium mTLS 透過結合身份核發、透明流量攔截及工作負載層級加密執行來保護流量。

每個工作負載會被分配一個加密身份，該身份源自 Kubernetes 屬性，如命名空間和 ServiceAccount。當 Pod 到 Pod TCP 流量開始時，該流量會在節點層級遭到透明攔截。接著，流量會透過互惠 TLS 進行認證與加密，然後再轉發給目的地工作負載。

該系統由三個協同組成部分組成：

SPIRE - 提供工作負載識別碼及憑證的發行。
ztunnel - 在資料平面強制執行 mTLS。
Cilium - 會安裝 iptables 規則，將傳出流量重新導向至連接埠 15001 上的 ztunnel。

這些元件共同確保認證與加密在叢集中透明且一致地進行。

身份與認證模型

Cilium mTLS 採用基於 SPIFFE 工作負載身份的互認證。

每個工作負載會獲指派一個衍生自以下項目的 SPIFFE 身分識別 (SVID)：

Kubernetes 命名空間
Kubernetes 服務帳戶

當工作負載啟動連線時：

來源 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 憑證 (SVIDs)。它使用 Kubernetes 原生的證明技術，將身份綁定於命名空間和 ServiceAccount 等屬性，而非網路屬性如 IP 位址。

在每個節點上， SPIRE 代理 負責向 SPIRE 伺服器認證該節點，並代表本地工作負載取得憑證。工作負載僅與 SPIRE 代理通訊，絕不會直接與 SPIRE 伺服器通訊。

SPIRE 確保每個工作負載身分識別都是：

可透過密碼學驗證。
自動核發並輪換。
綁定至 Kubernetes 原生组件，而非 IP 位址。
在 Pod 重啟和重新排程事件中保持穩定。

此身份基礎使得強大且不依賴拓撲的信任決策成為可能。

Ztunnel（mTLS 資料平面）

Ztunnel 是一個輕量級的節點層 Layer 4 代理，負責在工作負載間強制執行 mTLS。它會以 DaemonSet 的形式執行，且在每個節點上有一個執行個體，免除每個 pod sidecar 的 Proxy 需求。

當工作負載發起 TCP 連線時，ztunnel 會與對等節點的 ztunnel 實例建立一個相互認證的 TLS 會話。它使用從 SPIRE 取得的憑證，在允許流量流動前，先驗證連線雙方的身份。

Ztunnel 強制執行以下保證：

連線雙方必須提供有效的工作負載憑證。
憑證會根據叢集信任域進行驗證。
流量在線上總是被加密。
註冊工作負載不允許使用純文字回退。

透過將 mTLS 強制執行集中於節點層級，ztunnel 提供強大的安全特性，且不增加每個 pod 的操作負擔。

Cilium（重定向規則與小隊註冊）

Cilium 負責讓 mTLS 對應用程式透明。

當命名空間被標記為「io.cilium/mtls-enabled=true」時，Cilium 代理會註冊該命名空間中的所有 pods。它會進入每個 pod 的網路命名空間，並安裝 iptables 規則，將出站流量重新導向至 15001 埠的 ztunnel。

Cilium 也會將工作負載元資料（如 Pod UID）傳遞至 ztunnel，並與 Cilium 運算子整合，用 SPIRE 註冊工作負載身份。

從應用程式的角度來看，通訊仍使用標準 TCP 套接字進行。加密與認證完全在應用層底下執行，無需更改程式碼。

範圍與信託邊界

命名空間註冊

Cilium mTLS 是可選擇加入的，並且範圍設定在命名空間層級。命名空間必須明確標示，才能啟用 mTLS 強制執行。啟用後，該命名空間內的所有 pod 都必須進行強制認證與加密。

未註冊命名空間中的 Pods 不會受到影響。此設計允許逐步部署及跨環境分階段採用。

執行模型

加密僅在兩個小組同時註冊時才會生效。註冊與未註冊工作負載之間的流量以明文形式持續，不會造成連線問題或硬故障。

來源	目的地	Result
已註冊	已註冊	加密（mTLS over HBONE）
已註冊	未註冊者	純文字穿透
未註冊者	已註冊	明文（由 ztunnel 擷取，但未加密）
未註冊者	未註冊者	正常的 Cilium 資料路徑（無 ztunnel 參與）

考慮事項與限制條件

此功能僅適用於使用 Azure CNI，由 Cilium 支援，且已啟用先進容器網路服務（ACNS）的叢集。
mTLS 在命名空間層級啟用。所有註冊命名空間中的 pod 都會參與 mTLS。不支援在 Pod 層級進行選擇加入或退出。
Cilium mTLS 目前保護基於 TCP 的 pod-to-pod 通信流量。目前它不加密或認證其他協定，包括 UDP。
目前階段，mTLS 不支援 L4/L7 網路政策的強制執行。
您不能攜帶自訂 CA。 SPIRE 作為叢集憑證授權機構，負責憑證的發行與輪替管理。
在同一叢集上同時啟用 mTLS 和 WireGuard 是不支援的。
不支援同時啟用 Istio 和 Cilium mTLS 加密。
不支援跨叢集流量的 mTLS 加密。
此整合需要核心支援 iptables，且無法用於不支援 iptables 的環境（例如某些最小容器執行環境）。
沒有網路命名空間路徑的 Pod（例如使用主機網路的 Pods）無法註冊至 ztunnel，並將在註冊過程中被排除。

定價