Kubernetes 中的後量子密碼學
隨著量子計算的出現，密碼學世界正處於一場重大變革的風口浪尖。雖然強大的量子計算機在許多應用中很大程度上仍是理論性的，但它們破解當前密碼學標準的潛力是一個嚴重的問題，特別是對於長期執行的系統。這就是“後量子密碼學”（PQC）的用武之地。在本文中，我將深入探討 PQC 對 TLS 的意義，更具體地說，對 Kubernetes 生態系統的意義。我將解釋 Kubernetes 中 PQC 的（令人驚訝的）現狀，以及這對當前和未來的叢集意味著什麼。
什麼是後量子密碼學
後量子密碼學指的是那些被認為能夠抵禦經典計算機和量子計算機攻擊的密碼學演算法。主要擔憂是，量子計算機使用像Shor 演算法這樣的演算法，可以高效地破解廣泛使用的公鑰密碼系統，如 RSA 和橢圓曲線密碼學（ECC），這些是當今安全通訊（包括 TLS）的基礎。業界正在積極致力於標準化和採用 PQC 演算法。由 NIST 首批標準化的演算法之一是模組格金鑰封裝機制（ML-KEM），以前稱為 Kyber，現在標準化為 FIPS-203（PDF 下載）。
很難預測量子計算機何時能夠破解經典演算法。然而，很明顯，我們需要立即開始遷移到 PQC 演算法，如下一節所示。為了對預測的時間線有一個感覺，我們可以參考一份涵蓋向後量子密碼學標準過渡的 NIST 報告。該報告宣佈，使用經典密碼學的系統應在 2030 年後棄用，並在 2035 年後停用。
金鑰交換與數字簽名：不同的需求，不同的時間線
在 TLS 中，我們需要保護兩個主要的密碼學操作：
金鑰交換：這是客戶端和伺服器就共享金鑰達成一致以加密其通訊的方式。如果攻擊者今天記錄了加密流量，他們將來如果獲得了能夠破解金鑰交換的量子計算機，就可以解密這些流量。這使得將 KEMs 遷移到 PQC 成為當務之急。
數字簽名：這些主要用於透過證書驗證伺服器（有時也包括客戶端）的身份。伺服器的真實性在連線時進行驗證。雖然很重要，但今天遭受攻擊的風險要低得多，因為信任伺服器的決定不能在事後被濫用。此外，與經典演算法相比，當前的 PQC 簽名方案通常會帶來顯著的計算開銷和更大的金鑰/簽名尺寸。
遷移到 PQ 證書的另一個重要障礙是根證書的升級。這些證書具有很長的有效期，並且作為信任錨安裝在許多裝置和作業系統中。
鑑於這些差異，TLS 中立即採用 PQC 的重點是混合金鑰交換機制。這些機制將經典演算法（如橢圓曲線 Diffie-Hellman 臨時金鑰交換（ECDHE））與 PQC 演算法（如 ML-KEM）相結合。只要其中至少一個組成演算法未被破解，由此產生的共享金鑰就是安全的。X25519MLKEM768 混合方案是支援最廣泛的一種。
當今 PQC 金鑰交換機制（KEMs）的現狀
整個生態系統對 PQC KEMs 的支援正在迅速改善。
Go：Go 標準庫的 crypto/tls 包在 1.24 版本（2025 年 2 月釋出）中引入了對 X25519MLKEM768 的支援。關鍵是，當沒有顯式配置時（即 Config.CurvePreferences 為 nil），它是預設啟用的。
瀏覽器和 OpenSSL：主流瀏覽器如 Chrome（131 版，2024 年 11 月）和 Firefox（135 版，2025 年 2 月），以及 OpenSSL（3.5.0 版，2025 年 4 月），也增加了對基於 ML-KEM 的混合方案的支援。
蘋果公司也在其作業系統的第 26 版中推出對 X25519MLKEM768 的支援。考慮到蘋果裝置的普及率，這將對全球 PQC 的採用產生重大影響。
有關更廣泛行業中 PQC 現狀的更詳細概述，請參閱 Cloudflare 的這篇部落格文章。
Kubernetes 中的後量子 KEMs：一次意外的到來
那麼，這對 Kubernetes 意味著什麼呢？Kubernetes 的元件，包括 API 伺服器和 kubelet，都是用 Go 構建的。
截至 2025 年 4 月釋出的 Kubernetes v1.33，該專案使用 Go 1.24。快速檢查 Kubernetes 程式碼庫發現，Config.CurvePreferences 並未顯式設定。這得出了一個有趣的結論：Kubernetes v1.33，由於使用了 Go 1.24，預設支援混合後量子 X25519MLKEM768 進行 TLS 連線！
你可以自己測試一下。如果你設定一個執行 Kubernetes v1.33.0 的 Minikube 叢集，你可以使用最新的 OpenSSL 客戶端連線到 API 伺服器：
$ minikube start --kubernetes-version=v1.33.0
$ kubectl cluster-info
Kubernetes control plane is running at https://127.0.0.1:<PORT>
$ kubectl config view --minify --raw -o jsonpath=\'{.clusters[0].cluster.certificate-authority-data}\' | base64 -d > ca.crt
$ openssl version
OpenSSL 3.5.0 8 Apr 2025 (Library: OpenSSL 3.5.0 8 Apr 2025)
$ echo -n "Q" | openssl s_client -connect 127.0.0.1:<PORT> -CAfile ca.crt
[...]
Negotiated TLS1.3 group: X25519MLKEM768
[...]
DONE
看吧，協商的組是 X25519MLKEM768！這是使 Kubernetes 具備量子安全性的重要一步，似乎沒有經過重大公告或專門的 KEP（Kubernetes 增強提案）。
Go 版本不匹配的陷阱
Go 1.23 和 1.24 版本出現了一個有趣的問題。Go 1.23 包含了對 ML-KEM 草案版本的實驗性支援，標識為 X25519Kyber768Draft00。如果 Config.CurvePreferences 為 nil，這個功能也是預設啟用的。Kubernetes v1.32 使用了 Go 1.23。然而，Go 1.24 移除了草案支援，並將其替換為標準化版本 X25519MLKEM768。
如果客戶端和伺服器使用不匹配的 Go 版本（一個使用 1.23，另一個使用 1.24）會發生什麼？它們將沒有共同的 PQC KEM 可供協商，握手將回退到經典的 ECC 曲線（例如 X25519）。這在實踐中是如何發生的呢？
考慮一個場景：
一個 Kubernetes 叢集正在執行 v1.32（使用 Go 1.23，因此支援 X25519Kyber768Draft00）。一位開發者將其 kubectl 升級到 v1.33，該版本使用 Go 1.24 編譯，只支援 X25519MLKEM768。現在，當 kubectl 與 v1.32 的 API 伺服器通訊時，它們不再共享一個共同的 PQC 演算法。連線將降級為經典密碼學，悄無聲息地失去了已經存在的 PQC 保護。這凸顯了理解 Go 版本升級的影響以及 TLS 棧細節的重要性。
限制：資料包大小
使用 ML-KEM 的一個實際考慮是其公鑰的大小，對於 ML-KEM-768，編碼後的金鑰大小約為 1.2 千位元組。考慮到典型的網路限制（最常見的是標準乙太網幀大小限制為 1500 位元組），這可能導致初始的 TLS ClientHello 訊息無法容納在單個 TCP/IP 資料包中。一些 TLS 庫或網路裝置可能無法妥善處理這種情況，因為它們假設 Client Hello 總是適合一個數據包。在一些與 Kubernetes 相關的專案和網路元件中已經觀察到這個問題，當使用 PQC KEMs 時可能導致連線失敗。更多細節可以在 tldr.fail 找到。
後量子簽名的現狀
雖然 KEMs 正在被更廣泛地採用，但 PQC 數字簽名在整合到標準工具鏈方面則較為落後。NIST 已經發布了 PQC 簽名標準，例如 ML-DSA (FIPS-204) 和 SLH-DSA (FIPS-205)。然而，以一種廣泛可用的方式實現這些標準（例如，用於 PQC 證書頒發機構）存在挑戰：
更大的金鑰和簽名：與 Ed25519 或 RSA 等經典演算法相比，PQC 簽名方案通常具有大得多的公鑰和簽名大小。例如，Dilithium2 金鑰可以比 Ed25519 金鑰大 30 倍，證書可以大 12 倍。
效能：簽名和驗證操作可能要慢得多。雖然某些演算法與經典演算法相當，但其他演算法可能會有更高的開銷，有時效能會差 10 到 1000 倍。為了改善這種情況，NIST 正在為 PQC 簽名進行第二輪標準化。
工具鏈支援：主流的 TLS 庫和 CA 軟體尚未對這些新的簽名演算法提供成熟的內建支援。例如，Go 團隊已表示，支援 ML-DSA 是一個高優先順序任務，但它最早可能出現在標準庫中的時間是 Go 1.26 （截至 2025 年 5 月）。
Cloudflare 的 CIRCL（Cloudflare 可互操作可重用密碼學庫）庫實現了一些 PQC 簽名方案，如 Dilithium 的變體，並且他們維護了一個集成了 CIRCL 的 Go 的分支 (cfgo)。使用 cfgo，可以嘗試生成用 PQC 演算法（如 Ed25519-Dilithium2）簽名的證書。然而，這需要使用自定義的 Go 工具鏈，並且尚未成為主流 Kubernetes 或 Go 發行版的一部分。
結論
通往後量子安全 Kubernetes 的旅程已經開始，並且可能比許多人意識到的要走得更遠，這要歸功於 Go 對 ML-KEM 的積極採用。在 Kubernetes v1.33 中，使用者已經在許多 TLS 連線中預設受益於混合後量子金鑰交換。
然而，意識到潛在的陷阱，例如 Go 版本不匹配導致降級和 Client Hello 資料包大小問題，是至關重要的。雖然 PQC 用於 KEMs 正在成為現實，但用於數字簽名和證書層次結構的 PQC 仍處於開發和主流採用的早期階段。作為 Kubernetes 的維護者和貢獻者，瞭解這些發展將是確保平臺長期安全的關鍵。