寫給 Kubernetes 工程師的 mTLS 指南

本文翻譯節選自?A Kubernetes engineer’s guide to mTLS^[1]，為了便于讀者理解，筆者對原文做了一點修改（本文刪除了原文中的與主題關系不大的 Linkerd 安裝的部分，將 Twillio 替換成國內讀者比較熟悉的 GitHub）。因為筆者最近在研究 Istio 中的身份認證及 SPIFFE，對如何在 Kubernetes 中應用 mTLS 以及為什么要使用 mTLS 產生了濃厚的興趣，再回想起五年前手動安裝 Kubernetes 時，因為給集群開啟 TLS 問題而導致安裝停滯不前。

本文的主要觀點是：在 Kubernetes 中我們不能僅依靠網絡層加密，還需要 mTLS 來對客戶端和服務端進行雙向的傳輸層認證。本文將聚焦于 TLS 的真實性，以及證書管理的難題，說明服務網格對于在 Kubernetes 中開啟 mTLS 帶來的便利。

簡介

Mutual TLS（雙向 TLS），或稱 mTLS，是 Kubernetes 中的一個熱門話題，尤其是對于那些負責為應用程序提供傳輸層加密的人來說。但是，你有沒有考慮過，什么是 mTLS，它提供什么樣的安全，為什么需要 mTLS？

本指南我將介紹什么是 mTLS，它與常規 TLS 的關系，以及為什么它與 Kubernetes 有關。我還會談論 mTLS 的一些優缺點及替代方案。

什么是 mTLS？

對于常規 TLS，只需要服務端認證，mTLS 相對來說有一個額外的規定：客戶端也要經過認證。但這意味著什么，為什么要這樣做呢？

在回答這些問題之前，我們需要先對 TLS 有一個基本的了解。TLS 是一個傳輸層協議，旨在為 TCP 連接提供安全保障（我們將在下面看到安全的確切含義）。TLS 在傳輸層工作，可以與任何使用 TCP 的應用層協議結合使用。例如，HTTPS 是 HTTP 與 TLS 的結合（HTTPS 中的 S 指的是 SSL，即 TLS 的前身），HTTP 不需要做任何改變來適應 TLS（至少，在協議層面。在實踐中，隨著 HTTPS 的引入，HTTP 的使用方式肯定已經發生了變化。例如，像 HSTS 這樣的功能現在被用來防止 HTTPS 可能發生的某些類型的攻擊）。

因為 TLS 中存在各種各樣的問題，使得其從安全的角度來看是不理想的。TLS 規范復雜，而且沒有得到充分的說明，有些地方并沒有真正的意義，而且不管怎樣，實現起來也不會 100% 符合 TLS 規范。

盡管有這些擔憂，TLS 還是無處不在。你現在就在使用 TLS：這個頁面是通過 HTTPS 提供的，你可能在瀏覽器的 URL 欄中看到一個小鎖圖標。

TLS 提供什么樣的安全性？

大多數人把 TLS 與加密聯系起來。但 TLS 不僅僅是這樣。TLS 為連接提供了三種安全保證：

??真實性：任何一方都能證明他們是自己所聲稱的身份。
??保密性：其他人無法看到正在交換的數據。
??完整性：收到的數據與發送的數據相同。

因此，雖然 TLS 確實給你提供了加密 —— 這就是它實現保密的方式 —— 但從 TLS 的角度來看，這對安全通信來說是不夠的：你需要所有這三種屬性。如果你沒有真實性，那么有人就可以在連接的另一端進行欺騙。如果你沒有完整性，那么有人可以修改通信中的關鍵信息。如果你沒有保密性，那么任何人都可以監聽。

在這三種保證中，本文主要關注真實性。

mTLS 什么時候有用？

回到我們最初的定義：mTLS 是簡單的常規 TLS，其中有一個額外的規定，即客戶端也要經過認證。有了對 TLS 的基本了解，我們現在可以解析這個聲明了。TLS 保證了真實性，但默認情況下，這只發生在一個方向上：客戶端對服務器進行認證，但服務器并不對客戶端進行認證。

為什么 TLS 的默認只在一個方向進行認證？因為客戶端的身份往往是不相關的。例如，在加載這個頁面時，你的瀏覽器已經驗證了要訪問的網站服務端的身份，但服務端并沒有驗證你的瀏覽器的身份。它實際上并不關心你的瀏覽器的身份。

當然，不驗證客戶端身份對于提供網頁服務是有意義的，但有很多類型的通信，客戶端的身份也很重要。例如 API 調用：如果你調用像 GitHub 這樣的服務，那么 GitHub 需要知道你是誰 —— 除其他原因外，這樣他們就可以給你發送賬單。如果不向 GitHub 提供某種客戶端身份，你就不能對 GitHub 的 API 進行調用。

但 GitHub 并不使用 mTLS。相反，你通過給 GitHub 一個秘密的認證令牌（token）來認證自己，這個令牌是創建賬戶時分配給你的。坦率地說，mTLS 設置起來很煩人（后面會有很多這方面的內容），所以如果你提供像 GitHub 這樣的公共 API，你可能會只使用 auth token。

然而，使用 mTLS 的認證有一些非常強大的 auth token 方法沒有的優勢。首先，mTLS 認證可以完全在應用程序之外完成，不需要任何應用程序級別的功能來創建、注冊或管理身份。使用 auth token 時，在你進行第一次 GitHub API 調用之前，你需要登錄網站，創建一個賬戶，獲得令牌（盡管這個客戶端令牌流程沒有使用 TLS 客戶端認證，但它仍然依靠 TLS 服務器認證來保證安全。TLS 確保令牌來自 GitHub 而不是一個偽裝者）。GitHub 的 API 必須知道這個 auth token，并提供將其傳遞給 API 調用和管理它的方法。但有了 mTLS，一個全新的客戶端就可以直接認證自己，即使從沒有人見過它。而應用程序不需要知道任何關于認證的事情，也不需要提供端點來管理認證。

綜上所述，我們看到 mTLS 非常適合以下情況：

1. 你需要安全通信；
2. 你關心客戶端的身份；
3. 不想為管理身份建立應用級流程；
4. 你可以管理實際實施的復雜性。

有種場景具有所有這些特征，那就是微服務！

使用 mTLS 來保護微服務的安全

mTLS 是保證微服務之間跨服務通信安全的好方法，原因就在上面。

首先，你想要安全的通信。當我們把我們的應用程序拆分為多個服務時，我們最終會在這些服務之間的網絡上發送敏感數據。任何能夠進入網絡的人都有可能讀取這些敏感數據并偽造請求。

第二，你關心客戶端的身份。首先，你要確保你能知道調用是什么時候發生的，以便進行診斷，并正確記錄指標等事項。此外，你可能想對這些身份進行授權（允許 A 調用 B 嗎）。我們將在后面討論更多關于授權的問題。

第三，你并不真的想為管理服務身份建立應用級的流程。這不是業務邏輯，開發人員的時間最好用在其他地方。

最后，如果你控制了平臺，你實際上可以管理實施 mTLS 的復雜性。或者至少，比 GitHub 做得更好。在我們的 GitHub 例子中，每個用戶都必須解決對 GitHub 進行身份驗證的難題。這個挑戰越難，對用戶就越不利（對 GitHub 的底線也越不利）。但是，如果我們能在平臺層面上實現 mTLS，我們就能一次性支付成本，而不是為每個服務或每個用戶支付。

綜上所述，mTLS 非常適用于確保微服務之間的通信安全。但是有一個問題。

實施 TLS 的難點：證書管理

到目前為止，我們已經為 mTLS 描繪了一幅美好的圖景。客戶端和服務器愉快地相互認證，然后它們之間的通信就安全了。在實踐中，阻礙 mTLS 工作的最大挑戰是證書管理。

TLS 中的認證是通過?公鑰密碼學和公鑰基礎設施（PKI）進行的?。這兩者本身就是一個巨大的話題，在這篇文章中我們不會去討論這些細節。但簡而言之，它們涉及大量的證書。

TLS 認證基于 X.509 證書。X.509 證書中包含身份和公鑰。公鑰有一個相應的私鑰，它不是證書的一部分。TLS 認證分兩步，第一步是向對方展示你的證書，然后用私鑰來證明證書中包含的身份屬于你（公鑰密碼學的神奇之處在于，任何復制證書的人都無法進行這種證明，因為他們沒有私鑰。因此，你可以非常自由地使用證書，包括通過明文渠道發送證書或將其存儲在公開場合）。

X.509 證書是由一個?證書授權機構（Certificate Authority，簡稱 CA）?簽署，其中包括受 CA 信任該的身份。證書用于 TLS 認證的第二步：如果有人向你展示他們的身份并證明他們擁有該身份，你現在必須決定是否信任該身份。TLS 在這里使用了一個簡單的規則：如果證書是由 CA 簽署的，且你信任該 CA，那么你就應該信任該身份。如何驗證 CA 對證書的簽名？通過使用該 CA 本身的 X.509 證書。怎么知道是否應該信任該 CA？嗯，這個就與 TLS 協議本身無關，你會被外界告知應該信任它（例如，你的瀏覽器帶有知名公共 CA 的證書，如 Verisign、Digicert 等，這些證書在發布時被打包在一起。當你下載 Firefox 時，你相信 Mozilla 已經把正確的證書放進了瀏覽器。對于集群內的通信，我們將創建我們自己的 CA，這意味著我們也必須以一種安全的方式，將這個 CA 的證書分發給集群的每個部分，這些部分需要做出信任決定）。

CA 也簽發證書。要獲得證書，你首先要創建公鑰和私鑰對。你保留私鑰，嗯，私鑰 —— 千萬不要在網絡上發送私鑰 —— 你向 CA 發送一個包含公鑰和你身份的證書簽名請求（Certificate Signing Request，簡稱 CSR）。如果 CA 批準了這個請求，它就會創建和簽署證書，并把證書發送給你。

所以，證書管理就是就成了證書創建和分發流程中的挑戰。我們需要確保有一個 CA，每個服務都可以向其發送 CSR，而且 CA 可以把證書發送給服務。我們還需要確保 CA 的安全，沒有人能夠訪問任何服務的私鑰，而且每個服務都知道自己的身份，而且不能被改變。

在 Kubernetes 這樣的環境中，服務實際上是一組不斷變化的副本，可以隨時創建或銷毀，每個副本都需要自己的證書，這使得證書分發的挑戰更加嚴峻。

而且?，?由于在實踐中，減少證書暴露損失（即當有人未經授權獲得秘鑰時）的最好方法是證書輪換：縮短證書的壽命，在證書過期前重新頒發。這意味著我們需要每隔 n 小時為每個副本重復整個證書請求和簽名的流程。

如果我們想在多個集群之間擴展安全通信，需要一種方法來確保在一個集群中產生的身份可以被其他集群所使用，而且如果某個集群被破壞，我們可以禁用該集群而不禁用其他集群，這就進一步增加了證書管理的復雜性，因為這將產生更多的證書。

總之，實施 mTLS 涉及到管理大量的證書，消耗大量的時間。這一挑戰的復雜性令人生畏。但盡管如此，mTLS 在 Kubernetes 的世界里已經看到了一些復興的趨勢。這是因為有一門技術使 mTLS 變得可行：服務網格。

Kubernetes、mTLS 和服務網格

服務網格是為集群開啟 mTLS 的一個絕佳的機制。它不僅可以處理證書管理的挑戰，還可以處理建立和接收 TLS 連接本身。它使得為集群添加 mTLS 成為一個零配置的操作：當你在 Kubernetes 集群上安裝服務網格的時候，網格化的 pod 之間的所有通信都自動被 mTLS 化。對于像 mTLS 這樣復雜的東西來說，這是很不可思議的。

這一切之所以能夠實現，是因為 Kubernetes 使一些本來非常復雜的事情，如 sidecar 模式，變得簡單易行。得益于 Kubernetes，服務網格可以：

??透明地將一個 sidecar 代理注入到每個應用程序的 pod 中，并通過該代理路由所有進出 pod 的 TCP 通信。
??將一個內部 CA 作為其控制平面的一部分，簽發 TLS 證書，并將該 CA 的證書安全地分配給所有代理。
??使用這個 CA 向每個代理發放短期的證書，與 pod 的 Kubernetes ServiceAccount 身份相聯系。
??每隔 N 小時重新簽發這些證書。
??讓每個代理對所有使用這些證書的 pod 的連接執行 mTLS，確保客戶端和服務器雙方都有有效的身份。
??在連接進入應用程序之前，使用這些身份應用授權策略。

當然，這只是一種簡化的描述。例如，Linkerd 實際上使用了兩級 CA，一個在集群層面，一個在全局層面，以便允許跨集群通信。Linkerd 可以使用多個信任根，所以你也可以輪流使用 CA。

常見問題：mTLS 實際上能保護什么？

事實上，mTLS 只能用于防止特定的攻擊：未經授權的網絡訪問。阻止入侵者嗅探網絡請求中的內容，阻止冒充服務進行訪問。

但是有很多東西是 mTLS 不能保護的，例如未經授權主機訪問。如果黑客入侵進了主機，mTLS 保護就無濟于事了：入侵者可以讀取密匙，嗅探或欺騙連接，顛覆 CA 并造成破壞，或任何其他惡意活動。

確保 Kubernetes 的安全并不容易，實際上 mTLS 只解決了 Kubernetes 的一小部分安全漏洞。

mTLS 與 IPSec 或 Wireguard 等網絡層加密相比怎么樣？

在 Kubernetes 中，一些 CNI 插件如 Calico 和 Cilium 可以通過 IPSec 或 Wireguard 等協議提供網絡層加密。像服務網格一樣，這種網絡層加密可以提供傳輸層加密，而應用程序本身不需要做任何事情。

雖然網絡層加密可以與 mTLS 結合使用，作為一種深度防御的形式，但有幾個原因可以說明網絡層加密不足以替代 mTLS。

如你所料，網絡層加密的最大缺點是圍繞身份的。因為它們在網絡層工作，Wireguard 和 IPSec 只能提供網絡身份，而不是工作負載身份。換句話說，它們不是使用工作負載本身固有的身份（比如?SPIFFE^[2]?或者 Kubernetes 的 ServiceAccount），而是使用該工作負載運行的 IP 地址。

依靠網絡身份有一系列的問題，包括：

1. 身份終止在集群邊界。Kubernetes 中的 IP 地址是以集群為范圍的，當跨越集群邊界的時候，你就必須想出另一種身份機制。因此，如果你正在進行跨集群通信，或者想要一個涵蓋非 Kubernetes 工作負載的身份系統，IP 地址就會落空。
2. 沒有直接的機制進行細粒度的授權。網絡層方法不能訪問七層信息，如 HTTP 路由、動詞以及 gRPC 方法（有些復雜的 CNI 通過啟動一個七層代理來解析數據，以服務網格模式來解決這個問題）。
3. 這不是零信任。零信任的安全模式要求我們將安全邊界轉移到盡可能細的層次。在 Kubernetes 中，這個單位就是 pod。有了服務網格的 mTLS，你的安全邊界就在 pod 層面，但對于網絡層的加密，你的安全邊界最多只能在主機層面執行；你必須信任網絡，等等。

由于這些原因，在 Kubernetes 中 mTLS 為你提供了比僅僅依靠網絡層加密更好的安全態勢。