在傳統(tǒng)的研發(fā)中，我們經(jīng)常關(guān)注的「安全」包括代碼安全、機(jī)器(運(yùn)行環(huán)境)安全、網(wǎng)絡(luò)運(yùn)維安全，而隨著云原生時(shí)代的到來(lái)，如果還按原有的幾個(gè)維度切分的話(huà)，顯然容易忽略很多云原生環(huán)境引入的新挑戰(zhàn)，我們需要基于網(wǎng)絡(luò)安全好實(shí)踐——縱深防御原則，來(lái)逐步剖析「云原生的安全」，并且對(duì)不同層次的防御手段有所了解，從而建立自己的云原生安全理念，真正搭建一個(gè)內(nèi)核安全的云原生系統(tǒng)。

注：“縱深防御”，指在計(jì)算機(jī)系統(tǒng)中的多個(gè)層面使用多種網(wǎng)絡(luò)安全技術(shù)，從而減少攻擊者利用關(guān)鍵業(yè)務(wù)資源或信息泄露到系統(tǒng)外部的總體可能性。在消息傳遞和協(xié)作環(huán)境中，縱深防御體系可以確保惡意攻擊活動(dòng)被阻止在基礎(chǔ)結(jié)構(gòu)內(nèi)的多個(gè)檢查點(diǎn)，降低了威脅進(jìn)入內(nèi)部網(wǎng)絡(luò)的可能性。

以某IDaaS系統(tǒng)為例，我們把一個(gè)云原生系統(tǒng)安全模型分為 4 個(gè)層面，由外至內(nèi)分別是：云/數(shù)據(jù)中心/網(wǎng)絡(luò)層、集群層、容器層、代碼層，如下圖所示：

對(duì)于這里安全模型的每一層，都是單向依賴(lài)于外層的。也就是說(shuō)，外層的云、集群、容器安全如果做得好，代碼層的安全就可以受益，而反過(guò)來(lái)，我們是無(wú)法通過(guò)提高代碼層的安全性來(lái)彌補(bǔ)外層中存在的安全漏洞或問(wèn)題?；谏鲜鲞@一點(diǎn)原理，我們的縱深防御策略是「自外而內(nèi)」地進(jìn)行“設(shè)防”。

一、云/數(shù)據(jù)中心/網(wǎng)絡(luò)層安全

這一層也可以稱(chēng)之為基礎(chǔ)設(shè)施安全，不管從何角度，公有或私有云或企業(yè)數(shù)據(jù)中心以及對(duì)應(yīng)的網(wǎng)絡(luò)安全，是 K8s 集群最根本的安全基礎(chǔ)，如果這一層存在安全漏洞或者過(guò)于脆弱，則整個(gè)系統(tǒng)都不能在此基礎(chǔ)上保證組件的安全。

我們除了需要防御傳統(tǒng)的攻擊，如 ARP 偽裝、DDOS、網(wǎng)絡(luò)層各類(lèi)報(bào)文等攻擊，應(yīng)該針對(duì) Kubernetes 集群采取以下保護(hù)措施：

不允許在 Internet 上公開(kāi)對(duì) Kubernetes 管理平臺(tái)(Control Plane)的所有訪(fǎng)問(wèn)，同時(shí)僅開(kāi)放部分可信 IP 可以訪(fǎng)問(wèn) Kubernetes 管理 API。

所有節(jié)點(diǎn)只暴露指定的端口，包括對(duì)管理平臺(tái)的內(nèi)部端口和來(lái)自 NodePort 和 LoadBalancer 類(lèi)型的 Kubernetes 服務(wù)的連接，并且不應(yīng)該直接暴露到 Internet。

通過(guò)云提供商或機(jī)房的網(wǎng)絡(luò)層安全組(例如 AWS 的 Security Group)對(duì)管理平臺(tái)以及節(jié)點(diǎn)授予最小權(quán)限控制：

對(duì)etcd(Kubernetes 的基礎(chǔ)存儲(chǔ))的訪(fǎng)問(wèn)進(jìn)行嚴(yán)格控制(僅允許來(lái)自集群管理平臺(tái)的訪(fǎng)問(wèn))，應(yīng)強(qiáng)制所有連接都使用TLS，并確保所有信息都是在持久化層被加密的(Encryption at rest)。

二、集群層

保護(hù) Kubernetes 集群有兩個(gè)主體需要關(guān)注：

集群與組件

運(yùn)行的服務(wù)或應(yīng)用

保護(hù) Kubernetes 集群組件與服務(wù)或應(yīng)用：

針對(duì)這兩個(gè)主體的保護(hù)，我們的保護(hù)可以分為 4 大塊：管理 API 的訪(fǎng)問(wèn)控制、Kubelet 的訪(fǎng)問(wèn)控制、Runtime(運(yùn)行時(shí))工作負(fù)載或用戶(hù)功能的訪(fǎng)問(wèn)控制、集群組件的安全漏洞防護(hù)，如下圖所示。

(1) 管理 API 的訪(fǎng)問(wèn)控制

強(qiáng)制 TLS 保護(hù)傳輸層

強(qiáng)制 API 認(rèn)證

強(qiáng)制 API 授權(quán)機(jī)制(RBAC)

(2) Kubelet 的訪(fǎng)問(wèn)控制

生產(chǎn)環(huán)境啟用身份驗(yàn)證

身份授權(quán)(RBAC)

強(qiáng)制 TLS 保護(hù)傳輸層

(3) Runtime(運(yùn)行時(shí))工作負(fù)載或用戶(hù)功能的訪(fǎng)問(wèn)控制

限制使用特權(quán)容器

合理限制資源負(fù)載

防止加載非必要內(nèi)核模塊

限制 Pod 越權(quán)訪(fǎng)問(wèn)其他節(jié)點(diǎn)

基礎(chǔ)數(shù)據(jù)憑證的訪(fǎng)問(wèn)控制

(4) 集群組件的安全漏洞防護(hù)

禁止未授權(quán)訪(fǎng)問(wèn) etcd

啟用審核日志記錄

定期輪換基礎(chǔ)架構(gòu)憑證

定期升級(jí)修復(fù)漏洞

三、容器層

到了這一層，由于跟 Kubernetes 特性不是強(qiáng)相關(guān)，我們能提供一些通用的安全措施和建議：

四、代碼層

程序代碼層是最容易受攻擊，但也是最可控的部分之一。雖然一般負(fù)責(zé)這塊安全的人員不一定是運(yùn)維開(kāi)發(fā)(DevOps)，可能是專(zhuān)門(mén)的安全工程師(Sec Eng)，但有一些基本共性理念和建議是可以互相借鑒的。

總體來(lái)說(shuō)，云原生時(shí)代的這四層架構(gòu)：云/數(shù)據(jù)中心/網(wǎng)絡(luò)層、集群層、容器層、代碼層，與傳統(tǒng)架構(gòu)比起來(lái)更加細(xì)化和更易受攻擊。自外而內(nèi)地踐行每一層的安全好實(shí)踐，我們的縱深防御才能算是成功的，每個(gè)在云原生技術(shù)上想長(zhǎng)期獲益的團(tuán)隊(duì)需要對(duì)此有共識(shí)。

參考資料：

https://baike.baidu.com/item/%E7%BA%B5%E6%B7%B1%E9%98%B2%E5%BE%A1/8282191?fr=aladdin

https://kubernetes.io/docs/concepts/security/overview/

https://www.stackrox.com/post/2020/09/protecting-against-kubernetes-threats-chapter-8-lateral-movement/

當(dāng)前名稱(chēng)：云原生安全模型與實(shí)踐
鏈接地址：http://m.newbst.com/news1/202501.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站導(dǎo)航、網(wǎng)站改版、外貿(mào)網(wǎng)站建設(shè)、企業(yè)網(wǎng)站制作、網(wǎng)站營(yíng)銷(xiāo)、外貿(mào)建站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶(hù)投稿、用戶(hù)轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀(guān)點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話(huà)：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)