這篇是 Buoyant 的創始人 William Morgan 文章《# What Does Zero Trust Mean for Kubernetes?》[1]的翻譯,文章很好的解釋了什麼是零信任、為什麼要實施零信任,以及服務網格如何以最小的程式碼實現零信任。
零信任是營銷炒作,還是新的機會,各位看官你怎麼看?
要點
- 零信任是一種被大量炒作的安全模型,但儘管存在營銷噪音,但它對於具有安全意識的組織具有一些具體而直接的價值。
- 零信任的核心是,將授權從「在邊界驗證一次」轉變為「隨時隨地驗證」。
- 為此,零信任要求我們重新思考身份的概念,並擺脫基於位置的身份,例如 IP 地址。
- Kubernetes 採用者在網路層實現零信任時具有明顯的優勢,這要歸功於基於 Sidecar 的服務網格,它提供無需更改應用程序就可實現的最細粒度的身份驗證和授權。
- 雖然服務網格可以提供幫助,但 Kubernetes 安全性仍然是一個複雜而微妙的話題,需要從多個層次進行了解。
零信任[2]是一種位於現代安全實踐前沿的強大的安全模型。這也是一個容易引起轟動和炒作的術語,因此很難消除噪音。那麼,究竟什麼是零信任,對於 Kubernetes,它究竟意味著什麼?在本文中,我們將從工程的角度探討什麼是零信任,並構建一個基本框架來理解它對 Kubernetes 運維和安全團隊等的影響。
介紹
如果你正在構建現代雲軟體,無論是採用 Kubernetes 還是其他軟體,可能都聽說過「零信任」一詞。零信任的安全模式變得如此重要,以至於美國聯邦政府已經注意到:白宮最近發佈了一份聯邦零信任戰略的備忘錄[3],要求所有美國聯邦機構在年底前滿足特定的零信任安全標準。2024財年;國防部創建了[零信任參考架構](https://dodcio.defense.gov/Portals/0/Documents/Library/(U “零信任參考架構”)ZT_RA_v1.1(U)_Mar21.pdf);美國國家安全局發佈了一份Kubernetes 強化指南[4],專門描述了 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 使用者能夠採用服務網格並從純粹基於邊界的網路安全轉變為「對每個使用者、設備、應用程序和交易的持續驗證」,那麼他們至少有很大的優勢。
關於作者
William Morgan
William Morgan是 Buoyant 的聯合創始人兼執行長,Linkerd 的創建者。在加入 Buoyant 之前,他是 Twitter 的一名基礎架構工程師,在那裡他幫助將 Twitter 從單體架構轉變為微服務。他是 Powerset、Microsoft 和 Adap.tv 的軟體工程師,以及 MITRE 的研究科學家。
參考資料
[1]《# What Does Zero Trust Mean for Kubernetes?》: https://www.infoq.com/articles/zero-trust-k8s/
[2]零信任: https://en.wikipedia.org/wiki/Zero_trust_security_model
[3]發佈了一份聯邦零信任戰略的備忘錄: https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-09.pdf
[4]Kubernetes強化指南: https://media.defense.gov/2021/Aug/03/2002820425/-1/-1/0/CTR_Kubernetes_Hardening_Guidance_1.1_20220315.PDF
[5]Linkerd: https://linkerd.io/
[6]Cloud Native Computing Foundation: https://www.cncf.io/