Kubernetes 現在是最流行的容器編排平臺。世界上的 Mesoses 和 Docker Swarms 幾乎消失了，老實說，我不會想念他們的。但其市場主導地位的不利之處在于，Kubernetes 也成為想要損害其安全性的不良行為者的嚴重目標。

一些可悲的事實：容器安全處于糟糕的狀態

• 目前有 56% 的開發人員甚至沒有掃描他們的容器！
• Gartner 預計，到 2023 年，超過70% 的公司將運行容器化應用程序。
• 根據紅帽 2022 年的一份報告，錯誤配置占所有 Kubernetes 安全事件的 59% 。

作為一個社區，我們需要為此做點什么！

2022 NSA/CISA Kubernetes 強化指南總結

最初于 2021/8/3 日發布，然后由 NSA 和 CISA 于 2022 年 3 月 15 日更新的技術報告“Kubernetes 強化指南”在這里為您提供幫助！對于依賴 Kubernetes 作為容器平臺的組織來說，這是一份非常好的文檔。它提供了有關如何保護平臺的詳細信息和動手示例。

我將在此總結技術報告的主要要點，并根據我在云安全方面的個人經驗提供額外的見解。

掃描容器和 Pod 以查找漏洞或錯誤配置

為什么我們喜歡容器是因為鏡像是一個軟件及其所有依賴項的不可變包。不變性是一種資產，因為同一個容器可以接受質量保證流程，并從開發升級到生產，而無需任何更改。但這也是一種負擔，因為容器鏡像是軟件時間膠囊：它們不會在發現新漏洞時自動獲取更新。

掃描容器鏡像中的已知漏洞是一種安全最佳實踐（盡管只有 44% 的開發人員這樣做）。但大多數只是在最初將鏡像推送到注冊表時掃描圖像。這就產生了一個問題。因為應用程序越穩定，它更新的頻率就越低，從而無法經常被推送到注冊表。

具有諷刺意味的是，穩定性使得容器鏡像更容易在更新之間變得脆弱。

作為緩解措施，NSA/CISA 報告建議使用 Kubernetes 準入控制器，該控制器將在 Pod 部署時請求掃描。但是仔細想想，這會遇到同樣的問題：如果長時間部署不經常更新的應用程序，那么這種額外的部署時檢查將無法適當地保護長時間運行的應用程序。

這就是為什么我強烈建議建立一個流程來定期確定哪些容器部署到您的集群，并定期掃描這些鏡像。只需安排每天循環一次 Pod 并讓注冊表掃描其中的容器映像。這樣，您的掃描結果是最新且準確的。

以盡可能少的權限運行容器和 Pod

從第一天開始，Kubernetes 和容器運行時的默認安全狀態就非常松懈。而在一個2/3 的內部威脅是由疏忽造成的世界中，讓軟件或用戶擁有過于廣泛的權限，無疑是疏忽大意！

容器中的默認用戶是系統管理員 root 用戶。您必須手動選擇退出。Kubernetes 對容器化應用程序的功能幾乎沒有任何額外限制。因此，如果針對 Kubernetes 容器平臺中的應用程序的網絡攻擊成功，則授予參與者的權限和權限集非常廣泛。

為降低風險，應制定政策以確保并強制執行：

• 容器不會以“root”用戶身份運行（如果可能，容器運行時本身也不會——默認用戶會這樣做），以限制應用程序的權限，從而限制黑客攻擊的行為；
• 容器文件系統是不可變的，以防止不良行為者擦除其攻擊軌跡；
• 最嚴格的 Pod 安全策略（Kubernetes v1.21 以上）或 Pod 安全標準（Kubernetes v1.22+）用于，例如，以非 root 用戶身份運行，并禁止特權升級以本質上成為 root 用戶，以及訪問容器主機操作系統；
• 默認服務帳戶令牌不需要對 Pod 進行訪問，因為它們可能會比您預期的更多地訪問 Kubernetes 集群的 API。您的應用程序可能甚至不需要這個，那么為什么默認情況下它存在呢？

我認為這些基線政策應該始終到位是不言而喻的。但是您可能也有更多的政策。那些對您的組織來說是特別的。為此，我全心全意地推薦使用 Kubernetes 中可用的配置以及Open Policy Agent (OPA)。通過受官方庫或第三方政策啟發的配置，它可以根據每個請求強制執行所有政策事項。

使用網絡分離來控制妥協可能造成的損害程度

Kubernetes 中的默認網絡設置允許 Pod 自由地相互連接，而不管它們部署在哪個命名空間中。這種免費的網絡方法意味著不良行為者只需進入單個 Pod 即可獲得不受限制的訪問給其他人。因此，整個平臺僅與最不安全的組件一樣安全，而壞人所要做的就是通過您最不安全的組件進入。然后，剩下的就是歷史了。

Kubernetes 網絡策略對網絡施加了可配置的限制。這些實現方式因使用的容器網絡接口 (CNI)提供程序而異，但本質上變成了 Kubernetes 資源感知防火墻規則。這可以很容易地指定只有“后端組件”才能調用“數據庫”，而不是其他任何東西。因此，API 網關的弱點并不意味著可以輕松地對平臺中的任何組件發起攻擊。

使用防火墻限制不必要的網絡連接和加密以保護機密性

Kubernetes 容器平臺由一個控制平面和一組工作節點組成。控制平面節點托管控制整個集群的組件。因此，設法控制控制平面的不良行為者因此可以進行任意后續攻擊并完全命令集群進行欺騙。

通過防火墻的網絡外圍防御可以幫助緩解來自（外部）惡意威脅參與者的此類攻擊。控制平面的任何組件（Kubernetes API、etcd、控制器管理器等）的暴露程度都不應超過滿足組織需求的絕對必要程度。

另請注意，Kubernetes 集群內的網絡流量通常未加密。這意味著敏感信息可能會被不法分子設法放置在容器平臺中的軟件獲取和利用。為了防止此類攻擊，可以對集群中的所有流量進行加密。如果集群使用提供加密作為配置選項的 CNI 提供程序，這是一個相當微不足道且完全透明的更改。例如，Calico 可以通過利用 WireGuard 來做到這一點。如果您不能充分信任底層網絡以滿足您的信息安全需求，建議您這樣做。

使用強身份驗證和授權來限制用戶和管理員訪問以及限制攻擊面

Kubernetes 容器平臺在其 API 服務器中具有基于角色的訪問控制功能。但是，出于某種原因，這些必須顯式激活。此外，典型的 Kubernetes 安裝為安裝集群的人提供了一個永不過期的系統管理員“令牌”。使用此令牌可提供對集群的完全且永久的訪問權限。猜猜我對此有何感想？

盡管默認情況下未啟用，但 Kubernetes 支持通過各種方法進行身份驗證。有各種各樣的，但我強烈建議使用 OpenID Connect 令牌。您可以與許多身份提供者服務集成，并且大多數支持發出此類令牌。它們還可以包含有關用戶所在組的信息，因此可以在組級別設置基于角色的訪問控制規則。對于那些不這樣做的人，Keycloak或Dex IdP可能可以與它們集成。

并且希望（并且慷慨地）被視為易于使用的錯誤嘗試，Kubernetes 默認還支持匿名請求。這應該毫無疑問地被關閉。

應該啟用和配置基于角色的訪問控制以遵守最小權限原則。就像這樣，只應向軟件和用戶授予最小的特權集，并且應根據請求審查任何額外的特權請求。

如您所知，我確實建議 (a) 禁用管理員令牌，(b) 啟用 OpenID Connect，(b) 禁用匿名訪問，以及 (d) 啟用基于角色的訪問控制。并且，（e）您實際上盡可能地限制權限。

開啟日志審計，以便管理員可以監控活動并提醒潛在的惡意活動

Kubernetes 控制平面內置了審計日志記錄功能。但是，同樣（注意這里的主題？），它們必須通過配置顯式啟用。就像 Kubernetes Hardening Guidance 技術報告一樣，我當然也建議啟用這些，這樣操作員就可以深入了解他們集群中發生的事情。

然而，僅僅啟用一個非常頻繁的日志流（所有針對 Kubernetes API 的自動請求也會留下審計線索）只是提供了大海撈針。大海撈針需要實際解析和使用這些日志。這可以通過在您的日志存儲解決方案（例如 Opensearch、Splunk 或 DataDog）中過濾表達式來完成，也可以通過自動化系統（例如CNCF 項目 Falco ）的自動和策略感知解析來完成。它可以與日志處理服務一起充當自動化安全事件和事件管理 (SIEM) 系統。

定期檢查所有 Kubernetes 設置并使用漏洞掃描來確保適當考慮風險并應用安全補丁

Kubernetes每年大約發布 3 次新版本的容器平臺。僅針對當前版本和之前的兩個版本提供安全更新。因此，為了保持最新的安全性，運營商必須每年至少安裝一次新版本。最好他們會遵循每個新版本，因為我會親切地稱之為過去相當幼稚的安全功能正在逐漸改進。

我希望我現在已經說清楚了：默認情況下，Kubernetes 并不安全。禁用的安全功能的數量表明，默認情況下有意不考慮安全性。新的安全威脅不斷出現。因此，強烈建議使用整個平臺的自動漏洞掃描，包括控制平面和工作節點本身。發現問題，立馬告警。

不過，有一個問題。自動化測試能抓住一切嗎？不，絕對不是。但它確實捕獲了一些更明顯的錯誤，如果被不良行為者發現，則表明該平臺也可能在其他方面配置不當。以我的經驗，即使不照顧低垂的果實也是一個巨大的“歡迎”標志。

自動化漏洞工具是否足夠？

許多工具承諾自動掃描容器鏡像以及 Kubernetes 集群的配置或其中管理的資源的漏洞。這些提供了一個吸引人的產品，因為它們將突出錯誤配置。但它們的范圍和功能有限。它們沒有（技術上也不能）涵蓋 NSA/CISA Kubernetes 強化指南建議的所有內容。

安全公司 ARMO 發布了Kubescape。它聲稱是第一個根據 NSA/CISA 技術報告中的最佳實踐驗證集群的工具。事實上，在撰寫本文時，它確實包含一組很好的自動化測試。

它使用 Kubernetes API，現在，截至 2022 年，它還使用主機級檢查功能來執行檢查。這使它可以訪問大量可以檢查的配置。但是，存在限制：一般情況下無法驗證，例如容器注冊表中的容器鏡像漏洞掃描策略是否生效，審計日志是否自動審核，節點之間是否有防火墻，或者是否有最嚴格的權限限制您的組織在虛擬機或云級別上就位。所有這些都需要對組織政策和流程有更多的了解，而不是期望一個工具擁有它是合理的。

自 Kubescape 成立以來，2022 年的最新更新大大擴展了 Kubescape 的范圍，例如擁有自己的鏡像掃描功能、RBAC 可視化器和調查器、輔助修復等等。它還與谷歌云集成，因此可以從那里收集信息。鑒于 ARMO 在 2022 年 4 月成功籌集了 3000 萬美元的 A 輪融資，Kubescape 可以做的廣度和深度似乎只會顯著增加。

Aqua Security 也同樣發布了kube-bench。它可以通過檢查控制平面主機上正在運行的進程來檢查控制平面的配置方式。不幸的是，它無法檢查不屬于 Kubernetes 配置的安全功能。

因此答案是“否”。一個人不能僅僅運行自動檢查并聲稱擁有完美（甚至是良好）的安全態勢。還需要對安全策略的實際理解，以及不僅僅是集群本身，而是更廣闊的視野。

超越 NSA/CISA Kubernetes 強化指南

防止配置錯誤，不要只檢查它

基于角色的訪問控制 (RBAC) 可以確定誰可以在什么情況下做什么。但僅僅因為一條規則說 Lars 可以在“生產環境”中“更新配置”，并不意味著他可以無限制地訪問——還必須防止 Lars 犯錯誤。畢竟，三分之二的內部威脅是由于疏忽造成的。

與大多數云系統一樣，Kubernetes 僅附帶一個系統來強制執行 RBAC，但沒有強制執行限制用戶實際操作的合理策略。

事后檢查錯誤配置是某些系統提供的功能；AWS Config現在看到了一些用于此目的的牽引力。

但我更希望有一個完全防止錯誤配置的系統。策略應以自動可執行的形式編碼。CNCF 項目開放策略代理(OPA) 可以做到這一點。它可以充當Kubernetes 準入控制器，因此可以確保不會違反策略。OPA 用途廣泛；您可以從官方圖書館學習或從其他現成的政策中進行選擇，并以此為基礎。

給予應用程序的任何權限也會給予不良行為者

如果不良行為者設法破壞您的應用程序，他們將擁有與應用程序完全相同的權限。也許這看起來很明顯。但我的經驗告訴我，這在實踐中并沒有被認真對待。壞人將擁有 Kubernetes 容器平臺、網絡、云、第三方 SaaS 集成、連接 VPN 的后臺位置中的所有功能——所有功能。

畢竟，這就是像勒索軟件這樣的壞東西設法傳播的方式。它們只感染網絡應用程序中的一個點，然后繼續傳播。鏈條的強度實際上取決于其最薄弱的環節。

如果我們真的考慮到這一點，那么您的 REST API 組件應該擁有任何權限，除了處理請求和發回響應之外，應該沒有任何其它權限。

牢記云資源

我們都看到了頭條新聞。無論是被錯誤配置為允許匿名訪問的 S3 存儲桶，還是允許訪問任何客戶數據庫的 Microsoft Azure CosmosDB 的主密鑰，信息都很明確。每當我們使用云資源時，我們必須始終牢記它們及其配置。

Kubernetes 生態系統中有各種控制器使云集成變得簡單，簡單就是偉大的！但絕不允許簡單性損害安全性。因此，您必須確保這些控制器不會將幼稚的安全設置放在它們管理的資源上。您應該徹底拒絕那些沒有明確宣傳它們如何管理安全性的工具。包括沒有指定他們需要哪些 IAM 權限的工具，以及那些沒有公開配置他們將實施哪些權限的方法的工具。

您的應用程序是否無意中在云中擁有權限？

您是否授予云服務器訪問權限以修改您的云資源？AWS稱為實例配置文件（其他云提供商在不同名稱下具有相同概念）授予虛擬機修改云資源的權限。通過在該虛擬機中運行，容器化應用程序也可以擁有它。它所需要做的只是對云的元數據服務進行一系列網絡調用，并且它具有與您為服務器提供的相同級別的訪問權限。因為它在服務器上運行，所以云將其視為“服務器”。

我一遍又一遍地看到人們會在這里和那里向服務器的實例配置文件添加一些權限，以使他們想做的任何事情都能正常工作。創建負載均衡器，更新一些 DNS 記錄，修改自動伸縮組；之類的東西。但他們這樣做只是為了支持他們的預期用例，而不是意識到所有非預期用例都將具有相同的權限。

定期掃描所有已部署的容器鏡像

許多容器鏡像倉庫支持在推送鏡像時掃描鏡像。這很棒！NSA/CISA Kubernetes 強化指南建議準入控制器在部署時請求掃描。

但是，如果由于軟件穩定而使鏡像保持部署數周或數月怎么辦？幾周前的初始掃描可能是干凈的，但今天的新掃描會顯示漏洞。

相反，我堅決支持定期掃描主動部署到 Kubernetes 容器平臺的所有容器鏡像。通過確定所有已部署的容器映像版本并每天掃描它們來自動執行此檢查。

這意味著您可以獲得最新漏洞數據庫的優勢，以對抗不經常更新的穩定軟件的舊容器鏡像。如果掃描發現依賴項存在問題，您可以使用更新的依賴項重新構建鏡像，并使用（希望）很少或沒有其他更改來部署它，因為代碼本身沒有更改。

定期安全測試您的整個系統

您的軟件工程師有一些外部威脅沒有的東西：訪問源代碼。如果您還為他們提供時間和祝福來對您的系統進行安全測試，那么奇跡就會發生。

在過去的一個項目中，我深情地記得發現以自動化方式創建某種類型的資源會使整個系統戛然而止。一臺筆記本電腦可以成功地對整個系統發起拒絕服務攻擊，而不會做任何明顯惡意的事情。

即使您的工程師本身可能沒有接受過安全培訓，主要思想是灌輸安全第一的心態。這可能是一帆風順和安全災難之間的區別。

制定災難恢復 (DR) 計劃并進行實踐

與我交談過的公司數量之多，他們認為災難恢復僅意味著“備份”，這令人震驚。提示：真的不是。備份是必要的，但還不夠。

從災難中恢復意味著能夠在特定時間范圍內在其他地方站起來整個技術堆棧。雖然通常認為災難意味著整個云區域的中斷，但我認為安全事件絕對算作災難！由于您不再信任已部署的應用程序，因此您需要回答以下問題：您可以多快破壞整個基礎架構并恢復到事件發生前的狀態？

當被問到這個令人不安的問題時，仍然認為 DR 就等于“備份”的公司通常會承認，他們甚至不會定期嘗試從這些備份中恢復。如果信息技術是您工作的核心，請認真對待這方面。

使用入侵檢測系統 (IDS) 和安全信息和事件管理 (SIEM) 系統

Kubernetes Hardening Guidance 提到了這些，但實際上并沒有告訴您如何處理它們或如何使用它們。

IDS 記錄和監控應用程序的正常行為，并根據這些基線不斷檢查活動。如果應用程序開始以新的方式運行，則可能表明它已被不良行為者利用。例如，如果它開始嘗試讀取或寫入文件，而它通常不這樣做，這是一個非常好的跡象——它不像它自己開始那樣做！

CNCF項目 Falco也可以幫助您遵循本指南。指定規則當然很麻煩，但提供應用程序需要的防護欄是必不可少的。您可以從社區提供的服務開始。

Falco 可以與例如 Elasticsearch 結合使用，檢查您的（審計）日志，并以這種方式充當 SIEM。我也建議以這種方式使用它。如果您已經有一個不同的系統，那么一定要使用它。但是用點東西。由于當今的許多法規要求您通知用戶有關數據泄露的信息，因此您確實需要一個有助于管理安全信息和事件的系統。安全日志數據量太大而無法手動處理，尤其是當您當前受到攻擊時。

信息安全不是一次性的，它是一個持續的過程。威脅在不斷演變，因此應對措施也必須如此。通過在我們的平臺上設置護欄并不斷努力為我們的應用程序和服務器提供最少的權限，我們可以減少我們的攻擊面。

云的固有復雜性和動態特性為不良行為者提供了許多實施攻擊和隱藏的場所。我們有責任限制這些機會。

結束的想法

Kubernetes 默認不安全，本身也不安全。您絕對可以而且必須加強其配置。云提供商提供的所謂“托管 Kubernetes 服務”幾乎沒有為您提供本文中包含的建議（如果有的話）。他們當然不會添加任何其他深度安全所需的工具。他們也沒有興趣這樣做，根據他們的“責任共擔模型”，他們負責云的安全，但您負責云中的安全。