確保Kubernetes控制平臺(tái)安全的十個(gè)提示

譯文
作者： 李睿 2023-04-07 17:19:04

云計(jì)算

云原生 Kubernetes控制平臺(tái)如今成為網(wǎng)絡(luò)犯罪分子的誘人目標(biāo)，而了解和掌握一些網(wǎng)絡(luò)安全的提示可以幫助用戶高枕無(wú)憂。

察哈爾右翼后網(wǎng)站建設(shè)公司創(chuàng)新互聯(lián),察哈爾右翼后網(wǎng)站設(shè)計(jì)制作，有大型網(wǎng)站制作公司豐富經(jīng)驗(yàn)。已為察哈爾右翼后成百上千提供企業(yè)網(wǎng)站建設(shè)服務(wù)。企業(yè)網(wǎng)站搭建\外貿(mào)網(wǎng)站制作要多少錢，請(qǐng)找那個(gè)售后服務(wù)好的察哈爾右翼后做網(wǎng)站的公司定做！

譯者 | 李睿

審校 | 重樓

51CTO讀者成長(zhǎng)計(jì)劃社群招募，咨詢小助手（微信號(hào)：TTalkxiaozhuli）

在調(diào)研機(jī)構(gòu)最近發(fā)布的一份調(diào)查報(bào)告中，94%的受訪者表示經(jīng)歷過(guò)與Kubernetes相關(guān)的安全事件。錯(cuò)誤配置是最常見(jiàn)的Kubernetes漏洞，70%的受訪者表示存在這一漏洞。那么，對(duì)于網(wǎng)絡(luò)犯罪分子具有吸引力的目標(biāo)是什么?Kubernetes控制平臺(tái)。

企業(yè)的團(tuán)隊(duì)必須加強(qiáng)節(jié)點(diǎn)、主節(jié)點(diǎn)、核心組件、API和面向公眾的pod的邊界安全。否則，它們無(wú)法保護(hù)集群免受現(xiàn)有和潛在漏洞的侵害。以下是可以幫助企業(yè)保護(hù)Kubernetes控制平臺(tái)的10個(gè)最佳實(shí)踐，并將加快部署過(guò)程。

一、保護(hù)Kubernetes控制平臺(tái)的10個(gè)提示

1.使用Kubernetes基于角色的訪問(wèn)控制(RBAC)  

利用基于角色的訪問(wèn)控制(RBAC)設(shè)置可以訪問(wèn)Kubernetes API的用戶權(quán)限。用戶會(huì)發(fā)現(xiàn)在Kubernetes 1.6及更高版本中默認(rèn)啟用了RBAC。由于Kubernetes匯集了授權(quán)控制器，因此在啟用RBAC時(shí)可以禁用以往的基于屬性的訪問(wèn)控制(ABAC)。

在設(shè)置權(quán)限時(shí)，選擇特定于命名空間的權(quán)限而不是集群范圍的權(quán)限。即使企業(yè)的團(tuán)隊(duì)成員忙于調(diào)試，也不要給任何人提供集群管理員的權(quán)限。否則，集群的安全性可能會(huì)受到影響。

2.實(shí)施隔離

不要將Kubernetes節(jié)點(diǎn)直接暴露給公共網(wǎng)絡(luò)。與其相反，節(jié)點(diǎn)的最佳位置是與企業(yè)網(wǎng)絡(luò)沒(méi)有直接連接的獨(dú)立網(wǎng)絡(luò)。

另一個(gè)重要的隔離最佳實(shí)踐是分離Kubernetes控制和數(shù)據(jù)流量。用戶希望它們通過(guò)同一管道，因?yàn)閷?duì)數(shù)據(jù)平臺(tái)的開(kāi)放訪問(wèn)將導(dǎo)致對(duì)控制平臺(tái)的開(kāi)放訪問(wèn)。

3.避免將對(duì)象部署到默認(rèn)命名空間  

在Kubernetes中，命名空間提供了一種隔離集群內(nèi)資源組的機(jī)制。因此，對(duì)于許多用戶分布在多個(gè)團(tuán)隊(duì)或項(xiàng)目中的環(huán)境，它們都是很好的用例。

所有沒(méi)有指定名稱空間的對(duì)象最終都會(huì)使用默認(rèn)名稱空間。這使得在最關(guān)鍵的工作負(fù)載附近部署惡意容器更加容易。因此，建議為部署中的對(duì)象創(chuàng)建命名空間。

4.避免使用禁止的類型

避免使用被禁止的類型，例如NodePort或LoadBalancer。與其相反，應(yīng)該通過(guò)ClusterIP公開(kāi)服務(wù)。通過(guò)這種方式，可以避免某些惡意行為者發(fā)現(xiàn)集群基礎(chǔ)設(shè)施組件。

5.加密機(jī)密數(shù)據(jù)

在Kubernetes的基本實(shí)現(xiàn)中，人們是否知道機(jī)密數(shù)據(jù)在默認(rèn)情況下是不加密的?但是，如果用戶使用Kubernetes管理的服務(wù)(如GKE)，機(jī)密數(shù)據(jù)將在靜止時(shí)加密。

為什么加密機(jī)密數(shù)據(jù)很重要?任何攔截鍵值存儲(chǔ)的人都可以訪問(wèn)集群中的所有內(nèi)容。這包括所有純文本的集群機(jī)密數(shù)據(jù)。因此，加密集群狀態(tài)存儲(chǔ)是保護(hù)集群免受靜態(tài)數(shù)據(jù)泄露的最佳方式。

6.安全訪問(wèn)Etcd

對(duì)Etcd的訪問(wèn)等同于根權(quán)限。這就是為什么它是一個(gè)關(guān)鍵的控制平臺(tái)組件的原因，也是控制平臺(tái)內(nèi)最重要的安全部件。

確保與Etcd的通信是加密的，并且客戶端使用基于證書(shū)的身份驗(yàn)證。為了限制攻擊面，在理想情況下，只有API服務(wù)器有權(quán)訪問(wèn)Etcd。

7.不要在容器中掛載容器運(yùn)行時(shí)套接字

為什么要關(guān)心部署是否在容器中安裝了容器運(yùn)行時(shí)（CRI）套接字？docker.sock、container.sock和crio.sock增加了網(wǎng)絡(luò)攻擊者獲得主機(jī)和相應(yīng)容器運(yùn)行時(shí)的根訪問(wèn)權(quán)限的機(jī)會(huì)。要避免這種情況，需要?jiǎng)h除/var/run/.sock hostPath volume。

8.在沒(méi)有只讀根文件系統(tǒng)的情況下運(yùn)行容器？三思而后行

容器是否在沒(méi)有只讀根文件系統(tǒng)的情況下運(yùn)行？使用只讀文件系統(tǒng)可防止惡意二進(jìn)制文件寫(xiě)入系統(tǒng)或系統(tǒng)接管。通過(guò)在Pod securityContext定義中將readOnlyRootFilesystem設(shè)置為true，可以確保容器僅使用只讀文件系統(tǒng)。

9.確保安全然后訪問(wèn)Kubernetes控制平臺(tái)

要獲得額外的安全功能層，例如多因素身份驗(yàn)證，可以獲得第三方身份驗(yàn)證提供商的幫助。為了完全保護(hù)Kubernetes控制平臺(tái)訪問(wèn)，避免在API服務(wù)器級(jí)別管理用戶。與其相反，使用云計(jì)算提供商提供的解決方案，例如AWS身份和訪問(wèn)管理(IAM)。如果無(wú)法獲得云計(jì)算供應(yīng)商IAM，可以選擇OpenID Connect（OIDC）以及熟悉的單點(diǎn)登錄(SSO)提供商。

10.創(chuàng)建滾動(dòng)更新策略

為了確保EKS安全，需要制定滾動(dòng)更新策略。而滾動(dòng)更新允許部署更新，并最小化應(yīng)用程序停機(jī)時(shí)間，這要?dú)w功于增量pod更新。

另一點(diǎn)是在運(yùn)行時(shí)運(yùn)行漏洞掃描。用戶的集群面臨供應(yīng)鏈攻擊的風(fēng)險(xiǎn)。要處理它們，需要了解真正進(jìn)入集群的是什么，即使用戶在持續(xù)集成（CI）/持續(xù)交付（CD）期間掃描了所有部署構(gòu)件。基于代理的安全解決方案在這里運(yùn)行得很好，甚至比“無(wú)代理”還更好。

二、使用工具實(shí)現(xiàn)Kubernetes控制點(diǎn)安全

隨著Kubernetes生態(tài)系統(tǒng)的發(fā)展，其安全問(wèn)題也在不斷發(fā)展。不幸的是，跟上它們的變化是很耗時(shí)的，一旦漏洞累積起來(lái)，企業(yè)的安全人員就不得不同時(shí)對(duì)許多項(xiàng)目進(jìn)行優(yōu)先級(jí)排序。

Kubernetes安全工具根據(jù)行業(yè)最佳實(shí)踐、Kubernetes建議和CIS Kubernetes基準(zhǔn)檢查集群，然后自動(dòng)對(duì)它們進(jìn)行優(yōu)先級(jí)排序，以便使用戶從一開(kāi)始就處于正確的軌道上。

用戶可以根據(jù)配置和安全最佳實(shí)踐掃描Kubernetes集群，并了解如何優(yōu)化安全。

文章鏈接：https://dzone.com/articles/kubernetes-control-plane-10-tips-for-airtight-k8s

文章標(biāo)題：確保Kubernetes控制平臺(tái)安全的十個(gè)提示
文章出自：http://m.5511xx.com/article/cdppgee.html