零信任對 Kubernetes 意味著什么
要點
- 零信任是一種被大量炒作的安全模型，但盡管存在營銷噪音，但它對于具有安全意識的組織具有一些具體而直接的價值。
- 零信任的核心是，將授權從“在邊界驗證一次”轉變為“隨時隨地驗證”。
- 為此，零信任要求我們重新思考身份的概念，并擺脫基于位置的身份，例如 IP 地址。
- Kubernetes 采用者在網絡層實現零信任時具有明顯的優勢，這要歸功于基于 Sidecar 的服務網格，它提供無需更改應用程序就可實現的最細粒度的身份驗證和授權。
- 雖然服務網格可以提供幫助，但 Kubernetes 安全性仍然是一個復雜而微妙的話題，需要從多個層次進行了解。
零信任是一種位于現代安全實踐前沿的強大的安全模型。這也是一個容易引起轟動和炒作的術語，因此很難消除噪音。那么，究竟什么是零信任，對于 Kubernetes，它究竟意味著什么？在本文中，我們將從工程的角度探討什么是零信任，并構建一個基本框架來理解它對 Kubernetes 運維和安全團隊等的影響。
介紹
如果你正在構建現代云軟件，無論是采用 Kubernetes 還是其他軟件，可能都聽說過“零信任”一詞。零信任的安全模式變得如此重要，以至于美國聯邦政府已經注意到：白宮最近發布了一份聯邦零信任戰略的備忘錄，要求所有美國聯邦機構在年底前滿足特定的零信任安全標準。2024財年；國防部創建了[零信任參考架構]；美國國家安全局發布了一份Kubernetes 強化指南，專門描述了 Kubernetes 中零信任安全的最佳實踐。
隨著這種噪音，零信任無疑吸引了很多營銷關注。但盡管有噪音，零信任不僅僅是一個空洞的術語——它代表了對未來安全的一些深刻和變革性的想法。那么具體來說，什么是零信任，為什么它突然變得如此重要？零信任對 Kubernetes 用戶意味著什么？
什么是零信任？
正如所料，零信任從根本上講是關于信任。它是解決安全核心問題之一的模型：是否允許 X 訪問 Y？換句話說，我們是否相信 X 可以訪問 Y？
當然，零信任中的“零”有點夸張。要使軟件正常工作，顯然某些東西需要信任其他東西。因此，零信任并不是完全消除信任，而是將信任降低到最低限度（眾所周知的最小特權原則）并確保它在每一點都得到執行。
這聽起來像是常識。但與技術中的許多新想法一樣，理解零信任的最佳方法是了解它的反應。零信任摒棄了邊界安全的觀點。在邊界安全模型中，在敏感組件周圍實施“裝甲”。例如，數據中心周圍可能有一個防火墻，其任務是阻止問題流量和參與者進入。這種模型，有時被稱為城堡策略，具有直觀的意義：城堡的墻壁是為了將壞人拒之門外。如果你在城堡里，那么根據定義，你就是一個好人。
零信任模型表明，邊界安全已經不足。根據零信任原則，即使在安全邊界內，仍必須將用戶、系統和網絡流量視為不受信任。國防部的參考架構很好地總結了這一點：
“在安全邊界之外或之內運行的任何參與者、系統、網絡或服務都是不可信的。相反，我們必須驗證任何試圖建立訪問權限的事物。從邊界驗證一次到對每個用戶、設備、應用程序和交易的持續驗證，這是我們如何保護基礎設施、網絡和數據的哲學的巨大范式轉變。”
當然，零信任并不意味著拋棄防火墻——縱深防御是任何安全策略的重要組成部分。這也不意味著我們可以忽略所有其他重要的安全組件，例如事件記錄和供應鏈管理。零信任只要求我們將信任檢查從“一次在邊界”轉移到“每次，無處不在”。
然而，為了正確地做到這一點，我們需要重新考慮一些關于“信任”意味著什么以及我們如何捕捉它的基本假設。
身份
零信任最直接的影響之一是它改變了我們思考和分配身份的方式，尤其是系統身份。
在邊界模型中，位置實際上就是身份。如果在防火墻內，那么是可信的；如果你在它之外，就不是。因此，基于邊界的系統可以允許基于客戶端 IP 地址等信息訪問敏感系統。
在零信任世界中，這已經不夠了。IP 地址僅用于指示位置，因此不再足以確定是否可以訪問特定資源。相反，我們需要另一種形式的身份：以某種內在方式與工作負載、用戶或系統相關聯。而且這種身份需要以某種方式進行驗證，而這種方式本身并不需要信任網絡。
這是一個具有豐富含義的大要求。提供網絡安全但依賴于 IP 地址等網絡標識符（如 IPSec 或 Wireguard）的系統不足以實現零信任。
策略
有了新的身份模型，我們現在需要一種方法來捕獲每個身份的訪問類型。在上面的邊界方案中，通常授予一系列 IP 地址對敏感資源的完全訪問權限。例如，我們可能會設置 IP 地址過濾，以確保僅允許防火墻內的 IP 地址訪問敏感服務。在零信任的情況下，我們反而需要執行必要的最低訪問級別。基于身份以及任何其他相關因素，應盡可能限制對資源的訪問。
雖然我們的應用程序代碼可以自己做出這些授權決策，但我們通常會使用在應用程序之外指定的某種形式的策略來捕獲它。擁有明確的策略允許我們在不修改應用程序代碼的情況下審核和更改訪問權限。
為了實現我們的零信任目標，這些策略可能非常復雜。我們可能有一個策略，它將對服務的訪問限制為只有那些需要訪問它的服務調用方（即，在雙方都使用工作負載身份）。我們可能會進一步細化，只允許訪問該服務上的某些接口（HTTP 路由、gRPC 方法）。更進一步，根據請求的用戶身份限制訪問。在所有情況下，目標都是最低權限——只有在非常必要時才能訪問系統和數據。
執行
最后，零信任要求我們在最細粒度的級別上同時執行身份驗證（確認身份）和授權（驗證策略是否允許該操作）。每個授予數據或計算訪問權限的系統都應該設置從外圍到單個組件的安全邊界。
與策略類似，這種執行理想情況下是在整個堆棧中統一完成的。不是每個組件都使用自己的自定義執行代碼，而是使用統一的執行層，統一之后方便審計，并將應用程序開發人員的關注點與運營和安全團隊的關注點分離。
Kubernetes 零信任
我們必須從第一原則重新思考身份，以任意表達性策略的形式來將信任具象化，并將新的執行機制滲透到基礎設施的各個層面。面對這些的要求，我們不可避免地經歷短暫的恐慌。前面是不是提到需要在 2024 財年之前實現？
好消息是，至少對于 Kubernetes 用戶來說，采用零信任的某些方面要容易得多。盡管有缺陷和復雜性，Kubernetes 是一個具有明確范圍、定義良好的安全模型和明確的擴展機制的平臺。這使其成為零信任實施的成功領域。
在 Kubernetes 中解決零信任網絡的最直接方法之一是使用服務網格。服務網格利用了 Kubernetes 強大的“sidecar”概念，其中平臺容器（譯者注：此處指 sidecar 代理容器）可以在部署時以后期綁定操作功能的形式，與應用程序容器動態注入到一起，。
服務網格使用這種 sidecar 方法在運行時將代理添加到應用程序 pod 中，并連接這些代理以處理所有傳入和傳出流量。這允許服務網格以與應用程序代碼解耦的方式交付功能。應用程序和平臺之間的關注點分離是服務網格主張的核心價值：當然，這些功能可以直接在應用程序中實現，但是通過解耦，我們允許安全團隊和開發人員相互獨立地迭代，同時仍然努力實現安全但功能齊全的應用程序的共同目標。
由于服務網格處理進出應用程序之間的默認網絡，因此它可以很好地處理零信任問題：
- 工作負載身份可以從 Kubernetes 中的 pod 身份而不是其 IP 地址中獲取。
- 可以通過在雙向 TLS 中包裝連接來執行身份驗證，這是 TLS 的一種變體，其使用加密信息在連接的兩端進行驗證。
- 授權策略可以用 Kubernetes 術語表示，例如，通過自定義資源定義 (CRD)，明確策略并并與應用程序解耦。
- 最重要的是，策略在跨技術棧的單個 pod 級別統一執行。每個 pod 都有自己的身份驗證和授權，這意味著網絡永遠不受信任。
所有這些共同實現了我們的大部分零信任目標（至少對于 Kubernetes 集群而言！）。我們使用工作負載身份而不是網絡身份；在最細粒度級別（pod）上執行，以及在技術棧中以一致且統一的方式應用身份驗證和授權的，而無需更改應用程序。
在基本框架內，不同的服務網格實現提供了不同的權衡。例如， Linkerd[5]是一個開源、Cloud Native Computing Foundation[6] 畢業的服務網格項目，它提供了一個以簡單性為目標和重點的實現，直接從 Kubernetes ServiceAccounts 提取工作負載標識來達到“零配置”，默認開啟雙向 TLS。同樣，Linkerd 的基于 Rust 的微代理提供了一個極簡的零信任實現。
當然，僅僅在集群中添加一個服務網格并不是萬能的。安裝后，必須完成定義、更新和評估授權策略的工作。集群運維人員必須小心確保所有新創建的 pod 都與它們的 sidecar 組件配對。當然，服務網格本身必須像集群上的任何軟件一樣進行維護、監控和迭代。然而，不管是不是靈丹妙藥，服務網格確實提供了從集群中默認的未加密、未經身份驗證的流量轉變為具有強大工作負載身份和豐富授權系統的默認加密、經過身份驗證的流量——這是朝著零信任邁出的一大步。
總結
零信任是一種強大的安全模型，處于現代安全實踐的前沿。如果可以消除圍繞它的營銷噪音，那么采用零信任有一些深刻而重要的好處。雖然零信任需要對身份等核心理念進行一些根本性的改變，但如果 Kubernetes 用戶能夠采用服務網格并從純粹基于邊界的網絡安全轉變為“對每個用戶、設備、應用程序和交易的持續驗證”，那么他們至少有很大的優勢。
