Kubernetes 現(xiàn)在是最流行的容器編排平臺(tái)。世界上的 Mesoses 和 Docker Swarms 幾乎消失了，老實(shí)說，我不會(huì)想念他們的。但其市場主導(dǎo)地位的不利之處在于，Kubernetes 也成為想要損害其安全性的不良行為者的嚴(yán)重目標(biāo)。

一些可悲的事實(shí)：容器安全處于糟糕的狀態(tài)

• 目前有 56% 的開發(fā)人員甚至沒有掃描他們的容器！
• Gartner 預(yù)計(jì)，到 2023 年，超過70% 的公司將運(yùn)行容器化應(yīng)用程序。
• 根據(jù)紅帽 2022 年的一份報(bào)告，錯(cuò)誤配置占所有 Kubernetes 安全事件的 59% 。

作為一個(gè)社區(qū)，我們需要為此做點(diǎn)什么！

2022 NSA/CISA Kubernetes 強(qiáng)化指南總結(jié)

最初于 2021/8/3 日發(fā)布，然后由 NSA 和 CISA 于 2022 年 3 月 15 日更新的技術(shù)報(bào)告“Kubernetes 強(qiáng)化指南”在這里為您提供幫助！對于依賴 Kubernetes 作為容器平臺(tái)的組織來說，這是一份非常好的文檔。它提供了有關(guān)如何保護(hù)平臺(tái)的詳細(xì)信息和動(dòng)手示例。

我將在此總結(jié)技術(shù)報(bào)告的主要要點(diǎn)，并根據(jù)我在云安全方面的個(gè)人經(jīng)驗(yàn)提供額外的見解。

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

為什么我們喜歡容器是因?yàn)殓R像是一個(gè)軟件及其所有依賴項(xiàng)的不可變包。不變性是一種資產(chǎn)，因?yàn)橥粋€(gè)容器可以接受質(zhì)量保證流程，并從開發(fā)升級到生產(chǎn)，而無需任何更改。但這也是一種負(fù)擔(dān)，因?yàn)槿萜麋R像是軟件時(shí)間膠囊：它們不會(huì)在發(fā)現(xiàn)新漏洞時(shí)自動(dòng)獲取更新。

掃描容器鏡像中的已知漏洞是一種安全最佳實(shí)踐（盡管只有 44% 的開發(fā)人員這樣做）。但大多數(shù)只是在最初將鏡像推送到注冊表時(shí)掃描圖像。這就產(chǎn)生了一個(gè)問題。因?yàn)閼?yīng)用程序越穩(wěn)定，它更新的頻率就越低，從而無法經(jīng)常被推送到注冊表。

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

作為緩解措施，NSA/CISA 報(bào)告建議使用 Kubernetes 準(zhǔn)入控制器，該控制器將在 Pod 部署時(shí)請求掃描。但是仔細(xì)想想，這會(huì)遇到同樣的問題：如果長時(shí)間部署不經(jīng)常更新的應(yīng)用程序，那么這種額外的部署時(shí)檢查將無法適當(dāng)?shù)乇Ｗo(hù)長時(shí)間運(yùn)行的應(yīng)用程序。

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

以盡可能少的權(quán)限運(yùn)行容器和 Pod

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

容器中的默認(rèn)用戶是系統(tǒng)管理員 root 用戶。您必須手動(dòng)選擇退出。Kubernetes 對容器化應(yīng)用程序的功能幾乎沒有任何額外限制。因此，如果針對 Kubernetes 容器平臺(tái)中的應(yīng)用程序的網(wǎng)絡(luò)攻擊成功，則授予參與者的權(quán)限和權(quán)限集非常廣泛。

為降低風(fēng)險(xiǎn)，應(yīng)制定政策以確保并強(qiáng)制執(zhí)行：

• 容器不會(huì)以“root”用戶身份運(yùn)行（如果可能，容器運(yùn)行時(shí)本身也不會(huì)——默認(rèn)用戶會(huì)這樣做），以限制應(yīng)用程序的權(quán)限，從而限制黑客攻擊的行為；
• 容器文件系統(tǒng)是不可變的，以防止不良行為者擦除其攻擊軌跡；
• 最嚴(yán)格的 Pod 安全策略（Kubernetes v1.21 以上）或 Pod 安全標(biāo)準(zhǔn)（Kubernetes v1.22+）用于，例如，以非 root 用戶身份運(yùn)行，并禁止特權(quán)升級以本質(zhì)上成為 root 用戶，以及訪問容器主機(jī)操作系統(tǒng)；
• 默認(rèn)服務(wù)帳戶令牌不需要對 Pod 進(jìn)行訪問，因?yàn)樗鼈兛赡軙?huì)比您預(yù)期的更多地訪問 Kubernetes 集群的 API。您的應(yīng)用程序可能甚至不需要這個(gè)，那么為什么默認(rèn)情況下它存在呢？

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

使用網(wǎng)絡(luò)分離來控制妥協(xié)可能造成的損害程度

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

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

使用防火墻限制不必要的網(wǎng)絡(luò)連接和加密以保護(hù)機(jī)密性

Kubernetes 容器平臺(tái)由一個(gè)控制平面和一組工作節(jié)點(diǎn)組成。控制平面節(jié)點(diǎn)托管控制整個(gè)集群的組件。因此，設(shè)法控制控制平面的不良行為者因此可以進(jìn)行任意后續(xù)攻擊并完全命令集群進(jìn)行欺騙。

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

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

使用強(qiáng)身份驗(yàn)證和授權(quán)來限制用戶和管理員訪問以及限制攻擊面

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

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

并且希望（并且慷慨地）被視為易于使用的錯(cuò)誤嘗試，Kubernetes 默認(rèn)還支持匿名請求。這應(yīng)該毫無疑問地被關(guān)閉。

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

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

開啟日志審計(jì)，以便管理員可以監(jiān)控活動(dòng)并提醒潛在的惡意活動(dòng)

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

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

定期檢查所有 Kubernetes 設(shè)置并使用漏洞掃描來確保適當(dāng)考慮風(fēng)險(xiǎn)并應(yīng)用安全補(bǔ)丁

Kubernetes每年大約發(fā)布 3 次新版本的容器平臺(tái)。僅針對當(dāng)前版本和之前的兩個(gè)版本提供安全更新。因此，為了保持最新的安全性，運(yùn)營商必須每年至少安裝一次新版本。最好他們會(huì)遵循每個(gè)新版本，因?yàn)槲視?huì)親切地稱之為過去相當(dāng)幼稚的安全功能正在逐漸改進(jìn)。

我希望我現(xiàn)在已經(jīng)說清楚了：默認(rèn)情況下，Kubernetes 并不安全。禁用的安全功能的數(shù)量表明，默認(rèn)情況下有意不考慮安全性。新的安全威脅不斷出現(xiàn)。因此，強(qiáng)烈建議使用整個(gè)平臺(tái)的自動(dòng)漏洞掃描，包括控制平面和工作節(jié)點(diǎn)本身。發(fā)現(xiàn)問題，立馬告警。

不過，有一個(gè)問題。自動(dòng)化測試能抓住一切嗎？不，絕對不是。但它確實(shí)捕獲了一些更明顯的錯(cuò)誤，如果被不良行為者發(fā)現(xiàn)，則表明該平臺(tái)也可能在其他方面配置不當(dāng)。以我的經(jīng)驗(yàn)，即使不照顧低垂的果實(shí)也是一個(gè)巨大的“歡迎”標(biāo)志。

自動(dòng)化漏洞工具是否足夠？

許多工具承諾自動(dòng)掃描容器鏡像以及 Kubernetes 集群的配置或其中管理的資源的漏洞。這些提供了一個(gè)吸引人的產(chǎn)品，因?yàn)樗鼈儗⑼怀鲥e(cuò)誤配置。但它們的范圍和功能有限。它們沒有（技術(shù)上也不能）涵蓋 NSA/CISA Kubernetes 強(qiáng)化指南建議的所有內(nèi)容。

安全公司 ARMO 發(fā)布了Kubescape。它聲稱是第一個(gè)根據(jù) NSA/CISA 技術(shù)報(bào)告中的最佳實(shí)踐驗(yàn)證集群的工具。事實(shí)上，在撰寫本文時(shí)，它確實(shí)包含一組很好的自動(dòng)化測試。

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

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

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

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

超越 NSA/CISA Kubernetes 強(qiáng)化指南

防止配置錯(cuò)誤，不要只檢查它

基于角色的訪問控制 (RBAC) 可以確定誰可以在什么情況下做什么。但僅僅因?yàn)橐粭l規(guī)則說 Lars 可以在“生產(chǎn)環(huán)境”中“更新配置”，并不意味著他可以無限制地訪問——還必須防止 Lars 犯錯(cuò)誤。畢竟，三分之二的內(nèi)部威脅是由于疏忽造成的。

與大多數(shù)云系統(tǒng)一樣，Kubernetes 僅附帶一個(gè)系統(tǒng)來強(qiáng)制執(zhí)行 RBAC，但沒有強(qiáng)制執(zhí)行限制用戶實(shí)際操作的合理策略。

事后檢查錯(cuò)誤配置是某些系統(tǒng)提供的功能；AWS Config現(xiàn)在看到了一些用于此目的的牽引力。

但我更希望有一個(gè)完全防止錯(cuò)誤配置的系統(tǒng)。策略應(yīng)以自動(dòng)可執(zhí)行的形式編碼。CNCF 項(xiàng)目開放策略代理(OPA) 可以做到這一點(diǎn)。它可以充當(dāng)Kubernetes 準(zhǔn)入控制器，因此可以確保不會(huì)違反策略。OPA 用途廣泛；您可以從官方圖書館學(xué)習(xí)或從其他現(xiàn)成的政策中進(jìn)行選擇，并以此為基礎(chǔ)。

給予應(yīng)用程序的任何權(quán)限也會(huì)給予不良行為者

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

畢竟，這就是像勒索軟件這樣的壞東西設(shè)法傳播的方式。它們只感染網(wǎng)絡(luò)應(yīng)用程序中的一個(gè)點(diǎn)，然后繼續(xù)傳播。鏈條的強(qiáng)度實(shí)際上取決于其最薄弱的環(huán)節(jié)。

如果我們真的考慮到這一點(diǎn)，那么您的 REST API 組件應(yīng)該擁有任何權(quán)限，除了處理請求和發(fā)回響應(yīng)之外，應(yīng)該沒有任何其它權(quán)限。

牢記云資源

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

Kubernetes 生態(tài)系統(tǒng)中有各種控制器使云集成變得簡單，簡單就是偉大的！但絕不允許簡單性損害安全性。因此，您必須確保這些控制器不會(huì)將幼稚的安全設(shè)置放在它們管理的資源上。您應(yīng)該徹底拒絕那些沒有明確宣傳它們?nèi)绾喂芾戆踩缘墓ぞ?。包括沒有指定他們需要哪些 IAM 權(quán)限的工具，以及那些沒有公開配置他們將實(shí)施哪些權(quán)限的方法的工具。

您的應(yīng)用程序是否無意中在云中擁有權(quán)限？

您是否授予云服務(wù)器訪問權(quán)限以修改您的云資源？AWS稱為實(shí)例配置文件（其他云提供商在不同名稱下具有相同概念）授予虛擬機(jī)修改云資源的權(quán)限。通過在該虛擬機(jī)中運(yùn)行，容器化應(yīng)用程序也可以擁有它。它所需要做的只是對云的元數(shù)據(jù)服務(wù)進(jìn)行一系列網(wǎng)絡(luò)調(diào)用，并且它具有與您為服務(wù)器提供的相同級別的訪問權(quán)限。因?yàn)樗诜?wù)器上運(yùn)行，所以云將其視為“服務(wù)器”。

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

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

許多容器鏡像倉庫支持在推送鏡像時(shí)掃描鏡像。這很棒！NSA/CISA Kubernetes 強(qiáng)化指南建議準(zhǔn)入控制器在部署時(shí)請求掃描。

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

相反，我堅(jiān)決支持定期掃描主動(dòng)部署到 Kubernetes 容器平臺(tái)的所有容器鏡像。通過確定所有已部署的容器映像版本并每天掃描它們來自動(dòng)執(zhí)行此檢查。

這意味著您可以獲得最新漏洞數(shù)據(jù)庫的優(yōu)勢，以對抗不經(jīng)常更新的穩(wěn)定軟件的舊容器鏡像。如果掃描發(fā)現(xiàn)依賴項(xiàng)存在問題，您可以使用更新的依賴項(xiàng)重新構(gòu)建鏡像，并使用（希望）很少或沒有其他更改來部署它，因?yàn)榇a本身沒有更改。

定期安全測試您的整個(gè)系統(tǒng)

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

在過去的一個(gè)項(xiàng)目中，我深情地記得發(fā)現(xiàn)以自動(dòng)化方式創(chuàng)建某種類型的資源會(huì)使整個(gè)系統(tǒng)戛然而止。一臺(tái)筆記本電腦可以成功地對整個(gè)系統(tǒng)發(fā)起拒絕服務(wù)攻擊，而不會(huì)做任何明顯惡意的事情。

即使您的工程師本身可能沒有接受過安全培訓(xùn)，主要思想是灌輸安全第一的心態(tài)。這可能是一帆風(fēng)順和安全災(zāi)難之間的區(qū)別。

制定災(zāi)難恢復(fù) (DR) 計(jì)劃并進(jìn)行實(shí)踐

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

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

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

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

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

IDS 記錄和監(jiān)控應(yīng)用程序的正常行為，并根據(jù)這些基線不斷檢查活動(dòng)。如果應(yīng)用程序開始以新的方式運(yùn)行，則可能表明它已被不良行為者利用。例如，如果它開始嘗試讀取或?qū)懭胛募?，而它通常不這樣做，這是一個(gè)非常好的跡象——它不像它自己開始那樣做！

CNCF項(xiàng)目 Falco也可以幫助您遵循本指南。指定規(guī)則當(dāng)然很麻煩，但提供應(yīng)用程序需要的防護(hù)欄是必不可少的。您可以從社區(qū)提供的服務(wù)開始。

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

信息安全不是一次性的，它是一個(gè)持續(xù)的過程。威脅在不斷演變，因此應(yīng)對措施也必須如此。通過在我們的平臺(tái)上設(shè)置護(hù)欄并不斷努力為我們的應(yīng)用程序和服務(wù)器提供最少的權(quán)限，我們可以減少我們的攻擊面。

云的固有復(fù)雜性和動(dòng)態(tài)特性為不良行為者提供了許多實(shí)施攻擊和隱藏的場所。我們有責(zé)任限制這些機(jī)會(huì)。

結(jié)束的想法

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