在 Kubernetes 中實施零信任的七條準則

語言: CN / TW / HK
原文作者:Matthew Yacobucci of F5
轉載來源:NGINX 官方網站

面對接二連三的災難性安全漏洞和勒索軟體攻擊,2021 年 5 月,拜登政府頒佈了一項 行政命令 ,要求改進美國的安全技術,並特別呼籲構建 零信任 (zero trust,即 ZT) 安全模型。
 
同年 8 月,美國國家標準與技術研究院 (NIST) 釋出了一份 白皮書 ,白皮書定義了零信任架構 (ZTA),並探討了“零信任可以改善企業整體資訊科技安全態勢的部署模型和用例”。各個政府機構(包括網路安全和基礎設施安全域性 (CISA) 以及管理和預算辦公室)相繼釋出零信任實施指導檔案,其中包括一個成熟度模型以幫助實施者瞭解如何分步實現完全零信任部署。
 
多年來,Kubernetes 社群一直在 討論如何讓零信任 成為端到端加密戰略的關鍵組成部分。service mesh 提供商已經實施了一些關鍵實踐(例如 mTLS 和證書金鑰輪換),旨在簡化零信任的實施。但即便如此,我們仍處於在大規模應用中實施穩健零信任架構的早期階段。關於零信任對 Kubernetes 意味著什麼以及最佳實踐是什麼,仍然存在一些爭議。相比傳統 IT 和基礎架構系統,開箱即用的 Kubernetes 給不瞭解 Kubernetes 網路和安全與前者的區別的團隊帶來了重大的安全挑戰。

什麼是零信任?為何零信任很重要?

傳統的安全模型在部署環境周圍構築了一個強大的邊界,並通過一個集中的“看門人”驗證使用者身份,且只允許授權使用者訪問內部的基礎架構。隨著 微服務 、雲和分散式部署的採用,這種模型逐漸被淘汰,因為邊界已變得越來越模糊,甚至不確定邊界是否還存在。零信任應運而生。
在零信任模型中,幾乎沒有任何東西或任何人是可信的,包括使用者、應用、網路、伺服器、服務或 API。每一層的每一個元素都必須經過身份驗證和授權測試。當技術資產、應用或服務連線並交換資料時,所有通訊都通過指定的代理進行路由,該代理對所有各方進行身份驗證並根據訪問策略授予他們許可權。重要的是,除了明確授權訪問特定資源的人以外,零信任系統在每個級別都以最小許可權執行,並拒絕所有各方的訪問。
零信任具有很多優勢——它可以通過以下方式改善安全狀況:
 
  • 自動阻止未經授權的活動
  • 通過訪問控制減少可訪問的攻擊面
  • 快速檢測行為異常和危害指標(Indicator of Compromise)
  • 通過實時最小許可權策略限制訪問時間
  • 使安全性獨立於其他所有變數,包括環境和地理
  • 通過持續的認證和身份驗證攔截正在進行的攻擊
零信任對於 雲原生 應用和基礎架構尤為重要。鬆散耦合且可移植的雲原生應用被設計成在容器中執行,並根據需要改變位置和狀態。除了程式碼、配置和少數必要元素(例如將雲原生應用連結到外部世界或內部服務的 IP 地址)之外,一切都是短暫的。東西向流量(環境內部的流量)和南北向流量(進出環境的流量)看起來越來越相似。API 在所有通訊(包括應用環境內的通訊和與外部客戶端的通訊)中起中介作用。不斷驗證許可權和身份不僅有用,而且最終還是一種安全需要。

在 Kubernetes 中實施零信任的七條準則

為 Kubernetes 驅動的基礎架構和應用部署零信任可能具有一定的挑戰性,為此我們提供了一系列實施準則。這些準則可能看起來平淡無奇,但要從零開始實施也不輕鬆。
 

準則 1:避免增加 Kubernetes 架構的複雜性

在沒有零信任框架的情況下執行 Kubernetes 具有挑戰性,而新增零信任會使事情變得更加複雜。對於許多廠商來說,提供額外服務或功能的預設方式是新增新的 sidecar 或 Kubernetes 自定義資源定義 (CRD)。不幸的是,無論新增什麼都會增加複雜性。例如,當您新增一個新的 sidecar 來傳輸可觀察性資料時,Kubernetes 必須維護一個甚至兩個以上的網路連線。增加的複雜性不僅會降低應用的速度,而且由於需要更大的 pod 來滿足應用需求,還會導致基礎架構的成本急劇增加。 奧卡姆剃刀 原理適用於此:最簡單的零信任路徑、最少的 sidecar 和 CRD 通常就是最好的。

準則 2:將開發人員和終端使用者的額外開銷降至最低

開發人員不想考慮零信任,而且我們也沒有理由強迫他們考慮。當零信任的實施迫使開發人員改變其行為或工作流程時,他們可能會抗拒,因為他們認為安全防護會影響開發速度。改變行為或工作流程也顯著增加了人為錯誤的機會 —— 開發人員本身 始終是安全鏈中的薄弱環節。作為 NetOps 或 SecOps 工程師,如果零信任機制透明到開發人員(以及終端使用者和客戶)都不知道它們的存在,那麼您就成功了。事實上,通過增強安全策略及提高其自動化水平,從理論上來說,零信任甚至可以消除多因素身份驗證和許多安全流程中的不便,進而改善終端使用者的體驗。

準則 3:將零信任規則應用於資料平面和控制平面

雖然資料平面是應用的“活動所在地”,但控制平面通常也同樣容易(有時甚至更容易)遭受 供應鏈攻擊 和其他入侵。由於策略引擎以及用於遙測和跟蹤的資料收集系統等複雜元素的介入,在控制平面上實施零信任合規要比在資料平面上更復雜。雖然我們很想為資料平面實施零信任,並減少對控制平面及其所有移動部件的擔憂,但我們必須確保兩者都符合要求,以最大限度發揮零信任的優勢。

準則 4:為東西向和南北向流量實施零信任

許多組織開始選擇僅將零信任應用到南北向流量,因為來自環境外部的流量似乎不如內部流量可信。這是一種錯誤的做法。在 Kubernetes 中,東西向流量無論在外觀還是行為上都很像南北向流量。Kubernetes 服務、節點和 pod 都通過 API 在 HTTP 或 HTTPS 上進行通訊。將相同的零信任策略和流程應用到所有流量會明顯提高安全性,並且這樣做不會產生更多開銷。此外,一開始便在所有位置應用零信任還有一個好處,可避免在南北向零信任實踐發生改變後對東西向零信任實踐進行修補的風險或麻煩。

準則 5:同時使用 Ingress controller 和 service mesh

雖然不用 Ingress controller service mesh 也可以在 Kubernetes 中構建和執行應用,但如果您想輕鬆地讓零信任成為基礎架構中所有元素的預設設定,您就需要用到它們了。Ingress controller 包含了 API 閘道器和負載均衡器的一些較有用的功能。它的另一項強大優勢是可以用作真正的反向代理,能夠將流量路由到特定的 Kubernetes pod(與傳統的負載均衡器不同)。service mesh 從根本上簡化了零信任在東西向流量上的實施、面向審計和驗證目的的可觀測性和報告。因此,如果您想通過更簡單、更清晰的方式實現零信任,那麼請在架構設計時同時考慮 Ingress controller 和 service mesh。

準則 6:將 Ingress controller 與 service mesh 整合

該準則與準則 5 密切相關。並非所有 Ingress controller 都可以與所有 service mesh 緊密整合。例如,基於 Istio 的 service mesh 使用與 NGINX Ingress Controller 不同型別的證書管理系統。在設計階段確保這兩個工具能夠輕鬆地緊密整合,可以避免日後出現嚴重的複雜性和配置問題。有關整合南北向和東西向解決方案的示例,請閱讀我們的博文 “如何簡化 Kubernetes 出入向流量管理”

準則 7:自動化證書的正確處理

對於其他大多數安全的連線形式,證書維護對於在 Kubernetes 中執行用於加密的公鑰基礎設施 (PKI) 元件至關重要。而對於零信任一致性,證書管理必須是自動化和動態的,這意味著證書需要定期過期和輪換,以確保持續進行身份驗證。service mesh 和 Ingress controller 都需要自動進行證書頒發、輪換和到期。如果 Ingress controller 或 service mesh 的本地或最佳整合證書管理工具無法做到這一點,您要不就需要想其他辦法,要不就得選擇放棄。
 

更多資源

想要更及時全面地獲取 NGINX 相關的技術乾貨、互動問答、系列課程、活動資源?
請前往 NGINX 開源社群: