要點

• 零信任是一種被大量炒作的安全模型，但盡管存在營銷噪音，但它對于具有安全意識的組織具有一些具體而直接的價值。
• 零信任的核心是，將授權(quán)從“在邊界驗證一次”轉(zhuǎn)變?yōu)椤半S時隨地驗證”。
• 為此，零信任要求我們重新思考身份的概念，并擺脫基于位置的身份，例如 IP 地址。
• Kubernetes 采用者在網(wǎng)絡(luò)層實現(xiàn)零信任時具有明顯的優(yōu)勢，這要歸功于基于 Sidecar 的服務(wù)網(wǎng)格，它提供無需更改應用程序就可實現(xiàn)的最細粒度的身份驗證和授權(quán)。
• 雖然服務(wù)網(wǎng)格可以提供幫助，但 Kubernetes 安全性仍然是一個復雜而微妙的話題，需要從多個層次進行了解。

零信任是一種位于現(xiàn)代安全實踐前沿的強大的安全模型。這也是一個容易引起轟動和炒作的術(shù)語，因此很難消除噪音。那么，究竟什么是零信任，對于 Kubernetes，它究竟意味著什么？在本文中，我們將從工程的角度探討什么是零信任，并構(gòu)建一個基本框架來理解它對 Kubernetes 運維和安全團隊等的影響。

介紹

如果你正在構(gòu)建現(xiàn)代云軟件，無論是采用 Kubernetes 還是其他軟件，可能都聽說過“零信任”一詞。零信任的安全模式變得如此重要，以至于美國聯(lián)邦政府已經(jīng)注意到：白宮最近發(fā)布了一份聯(lián)邦零信任戰(zhàn)略的備忘錄，要求所有美國聯(lián)邦機構(gòu)在年底前滿足特定的零信任安全標準。2024財年；國防部創(chuàng)建了[零信任參考架構(gòu)]；美國國家安全局發(fā)布了一份Kubernetes 強化指南，專門描述了 Kubernetes 中零信任安全的最佳實踐。

隨著這種噪音，零信任無疑吸引了很多營銷關(guān)注。但盡管有噪音，零信任不僅僅是一個空洞的術(shù)語——它代表了對未來安全的一些深刻和變革性的想法。那么具體來說，什么是零信任，為什么它突然變得如此重要？零信任對 Kubernetes 用戶意味著什么？

什么是零信任？

正如所料，零信任從根本上講是關(guān)于信任。它是解決安全核心問題之一的模型：是否允許 X 訪問 Y？換句話說，我們是否相信 X 可以訪問 Y？

當然，零信任中的“零”有點夸張。要使軟件正常工作，顯然某些東西需要信任其他東西。因此，零信任并不是完全消除信任，而是將信任降低到最低限度（眾所周知的最小特權(quán)原則）并確保它在每一點都得到執(zhí)行。

這聽起來像是常識。但與技術(shù)中的許多新想法一樣，理解零信任的最佳方法是了解它的反應。零信任摒棄了邊界安全的觀點。在邊界安全模型中，在敏感組件周圍實施“裝甲”。例如，數(shù)據(jù)中心周圍可能有一個防火墻，其任務(wù)是阻止問題流量和參與者進入。這種模型，有時被稱為城堡策略，具有直觀的意義：城堡的墻壁是為了將壞人拒之門外。如果你在城堡里，那么根據(jù)定義，你就是一個好人。

零信任模型表明，邊界安全已經(jīng)不足。根據(jù)零信任原則，即使在安全邊界內(nèi)，仍必須將用戶、系統(tǒng)和網(wǎng)絡(luò)流量視為不受信任。國防部的參考架構(gòu)很好地總結(jié)了這一點：

“在安全邊界之外或之內(nèi)運行的任何參與者、系統(tǒng)、網(wǎng)絡(luò)或服務(wù)都是不可信的。相反，我們必須驗證任何試圖建立訪問權(quán)限的事物。從邊界驗證一次到對每個用戶、設(shè)備、應用程序和交易的持續(xù)驗證，這是我們?nèi)绾伪Ｗo基礎(chǔ)設(shè)施、網(wǎng)絡(luò)和數(shù)據(jù)的哲學的巨大范式轉(zhuǎn)變。”

當然，零信任并不意味著拋棄防火墻——縱深防御是任何安全策略的重要組成部分。這也不意味著我們可以忽略所有其他重要的安全組件，例如事件記錄和供應鏈管理。零信任只要求我們將信任檢查從“一次在邊界”轉(zhuǎn)移到“每次，無處不在”。

然而，為了正確地做到這一點，我們需要重新考慮一些關(guān)于“信任”意味著什么以及我們?nèi)绾尾蹲剿幕炯僭O(shè)。

身份

零信任最直接的影響之一是它改變了我們思考和分配身份的方式，尤其是系統(tǒng)身份。

在邊界模型中，位置實際上就是身份。如果在防火墻內(nèi)，那么是可信的；如果你在它之外，就不是。因此，基于邊界的系統(tǒng)可以允許基于客戶端 IP 地址等信息訪問敏感系統(tǒng)。

在零信任世界中，這已經(jīng)不夠了。IP 地址僅用于指示位置，因此不再足以確定是否可以訪問特定資源。相反，我們需要另一種形式的身份：以某種內(nèi)在方式與工作負載、用戶或系統(tǒng)相關(guān)聯(lián)。而且這種身份需要以某種方式進行驗證，而這種方式本身并不需要信任網(wǎng)絡(luò)。

這是一個具有豐富含義的大要求。提供網(wǎng)絡(luò)安全但依賴于 IP 地址等網(wǎng)絡(luò)標識符（如 IPSec 或 Wireguard）的系統(tǒng)不足以實現(xiàn)零信任。

策略

有了新的身份模型，我們現(xiàn)在需要一種方法來捕獲每個身份的訪問類型。在上面的邊界方案中，通常授予一系列 IP 地址對敏感資源的完全訪問權(quán)限。例如，我們可能會設(shè)置 IP 地址過濾，以確保僅允許防火墻內(nèi)的 IP 地址訪問敏感服務(wù)。在零信任的情況下，我們反而需要執(zhí)行必要的最低訪問級別。基于身份以及任何其他相關(guān)因素，應盡可能限制對資源的訪問。

雖然我們的應用程序代碼可以自己做出這些授權(quán)決策，但我們通常會使用在應用程序之外指定的某種形式的策略來捕獲它。擁有明確的策略允許我們在不修改應用程序代碼的情況下審核和更改訪問權(quán)限。

為了實現(xiàn)我們的零信任目標，這些策略可能非常復雜。我們可能有一個策略，它將對服務(wù)的訪問限制為只有那些需要訪問它的服務(wù)調(diào)用方（即，在雙方都使用工作負載身份）。我們可能會進一步細化，只允許訪問該服務(wù)上的某些接口（HTTP 路由、gRPC 方法）。更進一步，根據(jù)請求的用戶身份限制訪問。在所有情況下，目標都是最低權(quán)限——只有在非常必要時才能訪問系統(tǒng)和數(shù)據(jù)。

執(zhí)行

最后，零信任要求我們在最細粒度的級別上同時執(zhí)行身份驗證（確認身份）和授權(quán)（驗證策略是否允許該操作）。每個授予數(shù)據(jù)或計算訪問權(quán)限的系統(tǒng)都應該設(shè)置從外圍到單個組件的安全邊界。

與策略類似，這種執(zhí)行理想情況下是在整個堆棧中統(tǒng)一完成的。不是每個組件都使用自己的自定義執(zhí)行代碼，而是使用統(tǒng)一的執(zhí)行層，統(tǒng)一之后方便審計，并將應用程序開發(fā)人員的關(guān)注點與運營和安全團隊的關(guān)注點分離。

Kubernetes 零信任

我們必須從第一原則重新思考身份，以任意表達性策略的形式來將信任具象化，并將新的執(zhí)行機制滲透到基礎(chǔ)設(shè)施的各個層面。面對這些的要求，我們不可避免地經(jīng)歷短暫的恐慌。前面是不是提到需要在 2024 財年之前實現(xiàn)？

好消息是，至少對于 Kubernetes 用戶來說，采用零信任的某些方面要容易得多。盡管有缺陷和復雜性，Kubernetes 是一個具有明確范圍、定義良好的安全模型和明確的擴展機制的平臺。這使其成為零信任實施的成功領(lǐng)域。

在 Kubernetes 中解決零信任網(wǎng)絡(luò)的最直接方法之一是使用服務(wù)網(wǎng)格。服務(wù)網(wǎng)格利用了 Kubernetes 強大的“sidecar”概念，其中平臺容器（譯者注：此處指 sidecar 代理容器）可以在部署時以后期綁定操作功能的形式，與應用程序容器動態(tài)注入到一起，。

服務(wù)網(wǎng)格使用這種 sidecar 方法在運行時將代理添加到應用程序 pod 中，并連接這些代理以處理所有傳入和傳出流量。這允許服務(wù)網(wǎng)格以與應用程序代碼解耦的方式交付功能。應用程序和平臺之間的關(guān)注點分離是服務(wù)網(wǎng)格主張的核心價值：當然，這些功能可以直接在應用程序中實現(xiàn)，但是通過解耦，我們允許安全團隊和開發(fā)人員相互獨立地迭代，同時仍然努力實現(xiàn)安全但功能齊全的應用程序的共同目標。

由于服務(wù)網(wǎng)格處理進出應用程序之間的默認網(wǎng)絡(luò)，因此它可以很好地處理零信任問題：

1. 工作負載身份可以從 Kubernetes 中的 pod 身份而不是其 IP 地址中獲取。
2. 可以通過在雙向 TLS 中包裝連接來執(zhí)行身份驗證，這是 TLS 的一種變體，其使用加密信息在連接的兩端進行驗證。
3. 授權(quán)策略可以用 Kubernetes 術(shù)語表示，例如，通過自定義資源定義 (CRD)，明確策略并并與應用程序解耦。
4. 最重要的是，策略在跨技術(shù)棧的單個 pod 級別統(tǒng)一執(zhí)行。每個 pod 都有自己的身份驗證和授權(quán)，這意味著網(wǎng)絡(luò)永遠不受信任。

所有這些共同實現(xiàn)了我們的大部分零信任目標（至少對于 Kubernetes 集群而言！）。我們使用工作負載身份而不是網(wǎng)絡(luò)身份；在最細粒度級別（pod）上執(zhí)行，以及在技術(shù)棧中以一致且統(tǒng)一的方式應用身份驗證和授權(quán)的，而無需更改應用程序。

在基本框架內(nèi)，不同的服務(wù)網(wǎng)格實現(xiàn)提供了不同的權(quán)衡。例如， Linkerd[5]是一個開源、Cloud Native Computing Foundation[6] 畢業(yè)的服務(wù)網(wǎng)格項目，它提供了一個以簡單性為目標和重點的實現(xiàn)，直接從 Kubernetes ServiceAccounts 提取工作負載標識來達到“零配置”，默認開啟雙向 TLS。同樣，Linkerd 的基于 Rust 的微代理提供了一個極簡的零信任實現(xiàn)。

當然，僅僅在集群中添加一個服務(wù)網(wǎng)格并不是萬能的。安裝后，必須完成定義、更新和評估授權(quán)策略的工作。集群運維人員必須小心確保所有新創(chuàng)建的 pod 都與它們的 sidecar 組件配對。當然，服務(wù)網(wǎng)格本身必須像集群上的任何軟件一樣進行維護、監(jiān)控和迭代。然而，不管是不是靈丹妙藥，服務(wù)網(wǎng)格確實提供了從集群中默認的未加密、未經(jīng)身份驗證的流量轉(zhuǎn)變?yōu)榫哂袕姶蠊ぷ髫撦d身份和豐富授權(quán)系統(tǒng)的默認加密、經(jīng)過身份驗證的流量——這是朝著零信任邁出的一大步。

總結(jié)

零信任是一種強大的安全模型，處于現(xiàn)代安全實踐的前沿。如果可以消除圍繞它的營銷噪音，那么采用零信任有一些深刻而重要的好處。雖然零信任需要對身份等核心理念進行一些根本性的改變，但如果 Kubernetes 用戶能夠采用服務(wù)網(wǎng)格并從純粹基于邊界的網(wǎng)絡(luò)安全轉(zhuǎn)變?yōu)椤皩γ總€用戶、設(shè)備、應用程序和交易的持續(xù)驗證”，那么他們至少有很大的優(yōu)勢。