2019年1月，世界上最流行的容器編排系統(tǒng)Kubernetes發(fā)現(xiàn)了第一個(gè)嚴(yán)重的安全漏洞，該漏洞襲擊了該項(xiàng)目的生態(tài)系統(tǒng)。漏洞CVE-2018-1002105允許攻擊者通過Kubernetes API服務(wù)器破壞群集，該服務(wù)器允許執(zhí)行惡意代碼以安裝惡意軟件等。那年早些時(shí)候，Kubernetes控制面板的錯(cuò)誤配置導(dǎo)致在Tesla資源上安裝了加密貨幣挖掘軟件。然后，攻擊者利用了Kubernetes面板之一不受密碼保護(hù)的事實(shí)，這使他們可以使用一個(gè)帳戶訪問其中一個(gè)Pod來訪問AWS中更大的Tesla基礎(chǔ)架構(gòu)。

加快容器及其編排的實(shí)施速度的組織還需要采取強(qiáng)制性步驟來保護(hù)其基礎(chǔ)結(jié)構(gòu)的這一關(guān)鍵部分。以下是基于客戶數(shù)據(jù)的九種Kubernetes最佳安全做法。跟隨他們以更好地保護(hù)您的基礎(chǔ)架構(gòu)。

　　1.更新到最新版本

[Kubernetes]的每個(gè)季度發(fā)行版中不僅有錯(cuò)誤修復(fù)，而且還提供新的安全功能。要利用它們，我們建議使用最新的穩(wěn)定版本。

更新和支持可能比發(fā)行版中提供的新功能困難，因此，至少每季度計(jì)劃一次更新?？梢允褂猛泄艿腒ubernetes-solutions提供程序顯著簡(jiǎn)化更新。

　　2.啟用基于角色的訪問控制

使用RBAC來控制誰可以訪問Kubernetes API以及他們具有哪些權(quán)限。通常，在Kubernetes 1.6版及更高版本中，默認(rèn)情況下會(huì)啟用RBAC，但是如果此后已更新且未更改配置，則應(yīng)仔細(xì)檢查設(shè)置。

但是，啟用RBAC是不夠的-仍然需要有效地使用它。在一般情況下，應(yīng)避免對(duì)整個(gè)群集的權(quán)限，而應(yīng)優(yōu)先考慮某些命名空間中的權(quán)限。即使在調(diào)試時(shí)，也要避免給集群管理員特權(quán)-僅在必要時(shí)不時(shí)授予權(quán)限更為安全。

如果應(yīng)用程序需要訪問Kubernetes API，請(qǐng)創(chuàng)建單獨(dú)的服務(wù)帳戶。并為他們提供每個(gè)用例所需的最小權(quán)限集。這種方法比給名稱空間中的默認(rèn)帳戶過多的特權(quán)要好得多。

　　3.使用名稱空間設(shè)置安全邊界

創(chuàng)建單獨(dú)的名稱空間對(duì)于組件隔離的第一級(jí)很重要。當(dāng)不同類型的工作負(fù)載部署在單獨(dú)的命名空間中時(shí)，調(diào)整安全設(shè)置要容易得多。

　　4.分離敏感的工作負(fù)載

限制危害潛在后果的一種好習(xí)慣是在一組專用的計(jì)算機(jī)上運(yùn)行帶有敏感數(shù)據(jù)的工作負(fù)載。這種方法降低了安全性較低的應(yīng)用程序訪問敏感應(yīng)用程序在同一容器可執(zhí)行環(huán)境或同一主機(jī)上運(yùn)行的數(shù)據(jù)的風(fēng)險(xiǎn)。例如，受感染節(jié)點(diǎn)的kubelet通常僅在將秘密內(nèi)容安裝在計(jì)劃在同一節(jié)點(diǎn)上執(zhí)行的Pod上時(shí)才可以訪問秘密內(nèi)容。如果可以在多個(gè)群集節(jié)點(diǎn)上找到重要機(jī)密，則攻擊者將有更多機(jī)會(huì)來獲取這些機(jī)密。

可以使用節(jié)點(diǎn)池，在云中或本地以及Kubernetes控制機(jī)制來完成分離。

　　5.保護(hù)對(duì)云服務(wù)元數(shù)據(jù)的訪問

敏感的元數(shù)據(jù)可能被盜用或出于惡意目的在集群中升級(jí)特權(quán)。例如，Shopify的漏洞賞金計(jì)劃中的一項(xiàng)最新發(fā)現(xiàn)詳細(xì)顯示了用戶如何通過使用專門為一種微服務(wù)生成的數(shù)據(jù)從云提供商接收元數(shù)據(jù)來超越權(quán)限。

GKE元數(shù)據(jù)隱藏功能以避免此類問題的方式更改了部署群集的機(jī)制。我們建議在實(shí)施永久解決方案之前使用它。

　　6.創(chuàng)建和定義群集網(wǎng)絡(luò)策略

網(wǎng)絡(luò)策略-允許您控制進(jìn)出容器化應(yīng)用程序?qū)W(wǎng)絡(luò)的訪問。要使用它們，您必須具有支持此類資源的網(wǎng)絡(luò)提供商。

一旦一切準(zhǔn)備就緒，就從簡(jiǎn)單的默認(rèn)網(wǎng)絡(luò)策略開始-例如，默認(rèn)情況下阻止來自其他名稱空間的流量。

　　7.設(shè)置集群的Pod安全策略

Pod安全策略設(shè)置用于啟動(dòng)集群中工作負(fù)載的默認(rèn)值。考慮定義策略并啟用Pod Security Policy準(zhǔn)入控制器：這些步驟的說明會(huì)根據(jù)所使用的云提供商或部署模型而有所不同。

開始時(shí)，您可能希望禁用容器中的NET_RAW功能，以保護(hù)自己免受某些類型的欺騙攻擊。

　　8.開展節(jié)點(diǎn)安全性工作

要提高主機(jī)安全性，您可以按照以下步驟操作：

· 確保安全且正確地配置了主機(jī)。一種方法是CIS基準(zhǔn)測(cè)試;許多產(chǎn)品都有自動(dòng)檢查器，可以自動(dòng)檢查系統(tǒng)是否符合這些標(biāo)準(zhǔn)。

· 監(jiān)視重要端口的網(wǎng)絡(luò)可用性。確保網(wǎng)絡(luò)禁止訪問kubelet使用的端口，包括10250和10255?？紤]限制對(duì)Kubernetes API服務(wù)器的訪問-受信任的網(wǎng)絡(luò)除外。在不需要在kubelet API中進(jìn)行身份驗(yàn)證和授權(quán)的集群中，攻擊者通常會(huì)訪問此類端口以啟動(dòng)加密貨幣礦工。

· 最小化對(duì)Kubernetes主機(jī)的管理訪問原則上應(yīng)限制對(duì)群集節(jié)點(diǎn)的訪問：通常，對(duì)于調(diào)試和解決其他問題，您可以在不直接訪問節(jié)點(diǎn)的情況下進(jìn)行。

　　9.啟用審核日志記錄

確保啟用了審核日志，并且正在監(jiān)視其中的異?；虿恍枰腁PI調(diào)用的發(fā)生，尤其是在任何授權(quán)失敗的情況下-此類條目將帶有“禁止”狀態(tài)的消息。授權(quán)失敗可能意味著攻擊者試圖利用獲得的憑據(jù)。

托管解決方案提供商可以在其界面中訪問此數(shù)據(jù)，并可以幫助您在授權(quán)失敗的情況下設(shè)置通知。

展望未來

請(qǐng)遵循以下準(zhǔn)則以獲得更安全的Kubernetes集群。請(qǐng)記住，即使在安全地配置了集群之后，也需要確保容器配置和操作的其他方面的安全性。為了提高技術(shù)堆棧的安全性，請(qǐng)研究工具，這些工具提供了用于管理已部署容器，不斷監(jiān)視和保護(hù)容器以及云原生應(yīng)用程序的中央系統(tǒng)。想了解更多關(guān)于網(wǎng)絡(luò)安全的信息，請(qǐng)繼續(xù)關(guān)注中培偉業(yè)。