容器正在改變軟件開發(fā)。作為CI/CD的新基礎(chǔ)，容器為你提供了一種快速，靈活的方式來部署應(yīng)用程序，API和微服務(wù)，而數(shù)字化成功與否取決于可擴(kuò)展性和性能。但是，容器和容器編排工具（例如Kubernetes）也是黑客們的熱門目標(biāo)，如果它們沒有得到有效的保護(hù)，它們可能會使你的整個環(huán)境面臨風(fēng)險。在本文中，我們將討論容器堆棧每一層安全的最佳實踐。

了解容器安全的含義很重要。作為依賴共享內(nèi)核的應(yīng)用程序?qū)訕?gòu)造，容器可以比VM更快地啟動。在配置方面，容器也比VM靈活得多，并且可以執(zhí)行掛載存儲卷到禁用安全功能的所有操作。

如果繞過容器隔離機(jī)制并在主機(jī)上獲得特權(quán)時，該容器甚至可以在黑客的控制下以root用戶身份運行，然后你就陷入了真正的麻煩。

你可以采取一些措施，將壞蛋拒之門外。

第0層–內(nèi)核

Kubernetes是一個開源平臺，旨在自動執(zhí)行容器的部署，擴(kuò)展和編排，正確配置它可以幫助你增強(qiáng)安全性。在內(nèi)核級別，你可以：

查看允許的系統(tǒng)調(diào)用，并刪除所有不必要或不需要的系統(tǒng)調(diào)用

使用gVisor或Kata Containers等容器沙箱進(jìn)一步限制系統(tǒng)調(diào)用

驗證你的內(nèi)核版本已打補(bǔ)丁并且不包含任何現(xiàn)有漏洞

第1層–容器

靜態(tài)

靜態(tài)的容器安全性側(cè)重于將用于構(gòu)建容器的Docker鏡像。首先，通過刪除不必要的組件，程序包和網(wǎng)絡(luò)實用程序來減少容器的攻擊面-精簡越多越好?？紤]使用僅包含應(yīng)用程序及其運行時依賴項的 distroless鏡像。

“Distroless （https://github.com/GoogleCloudPlatform/distroless） 是谷歌內(nèi)部使用的鏡像構(gòu)建文件，包括 Java 鏡像，Node，Python 等鏡像構(gòu)建文件，Distroless 僅僅只包含運行服務(wù)所需要的最小鏡像，不包含包管理工具，shell 命令行等其他功能。

接下來，確保僅從已知可信任的來源中提取鏡像，然后掃描它們中的漏洞和配置錯誤。在你的CI/CD流水線和構(gòu)建過程中檢查它們的完整性，并在運行之前進(jìn)行驗證和批準(zhǔn)，以確保黑客未安裝任何后門程序。

運行

打包鏡像后，就該進(jìn)行調(diào)試了。臨時容器將使你可以交互式地調(diào)試運行中的容器。監(jiān)視異常和可疑的系統(tǒng)級事件，這些事件可能是破壞的跡象，例如，產(chǎn)生了意外的子進(jìn)程，在容器內(nèi)運行的shell或意外讀取了敏感文件。

開源運行時安全工具Falco可以為你提供幫助，它通過以下方式使用系統(tǒng)調(diào)用來保護(hù)和監(jiān)視系統(tǒng)：

在運行時從內(nèi)核解析Linux系統(tǒng)調(diào)用

針對強(qiáng)大的規(guī)則引擎聲明流

違反規(guī)則時發(fā)出警報

第2層–工作負(fù)載（Pod）

Pod是Kubernetes內(nèi)的部署單位，是容器的集合，可以共享常見的安全定義和對安全敏感的配置。Pod安全上下文可以設(shè)置給定Pod的特權(quán)和訪問控制，例如：

容器內(nèi)的特權(quán)容器

進(jìn)程和卷的組和用戶ID

細(xì)粒度的Linux功能（刪除或添加），例如Sys.time

沙箱和強(qiáng)制訪問控制（seccomp，AppArmor，SELinux）

文件系統(tǒng)權(quán)限

特權(quán)升級

為了加強(qiáng)Pod級別的防御能力，你可以實施嚴(yán)格的Pod安全策略，以防止危險的工作負(fù)載在集群中運行。要獲得對Pod安全性的更大靈活性和更精細(xì)的控制，請考慮使用OPA Gatekeeper項目實施的開放策略代理（OPA）。

第3層–網(wǎng)絡(luò)

默認(rèn)情況下，所有Pod都可以不受限制地與集群中的所有其他Pod對話，這從攻擊者的角度來看非常有利。如果工作負(fù)載受到威脅，攻擊者可能會嘗試探測網(wǎng)絡(luò)并查看他們還可以訪問什么。Kubernetes API也可以從Pod內(nèi)部訪問，從而提供了另一個豐富的目標(biāo)。

嚴(yán)格的網(wǎng)絡(luò)控制是容器安全的關(guān)鍵部分-pod到pod，集群到集群，由內(nèi)而外和由內(nèi)而外。使用內(nèi)置的網(wǎng)絡(luò)策略來隔離工作負(fù)載通信并構(gòu)建精細(xì)的規(guī)則集。考慮實現(xiàn)服務(wù)網(wǎng)格以控制工作負(fù)載之間的流量以及入口/出口，例如通過定義namespace到namespace的流量。

應(yīng)用層（L7）攻擊–服務(wù)器端請求偽造（SSRF）

最近，我們已經(jīng)聽到很多關(guān)于SSRF攻擊的消息，這也就不足為奇了。在API與其他API對話的云原生環(huán)境中，SSRF尤其難以防御。webhooks尤其臭名昭著。一旦找到目標(biāo)，就可以使用SSRF升級特權(quán)并掃描本地Kubernetes網(wǎng)絡(luò)和組件，甚至在Kubernetes指標(biāo)端點上轉(zhuǎn)儲數(shù)據(jù)，以了解有關(guān)環(huán)境的有價值的信息-并有可能將其完全接管。

應(yīng)用層（L7）攻擊–遠(yuǎn)程執(zhí)行代碼（RCE）

RCE在云原生環(huán)境中也非常危險，這使得在容器內(nèi)運行系統(tǒng)級命令來抓取文件，訪問Kubernetes API，運行鏡像處理工具以及破壞整個機(jī)器成為可能。

應(yīng)用層（L7）防御

保護(hù)的第一條規(guī)則是遵守安全的編碼和體系結(jié)構(gòu)實踐，這可以減輕你的大部分風(fēng)險。除此之外，你還可以沿兩個方向?qū)W(wǎng)絡(luò)防御進(jìn)行分層：南北方向，以監(jiān)視和阻止針對你的應(yīng)用程序和API的惡意外部流量；東西方向，以監(jiān)視從一個容器到另一個容器，從一個集群到另一個集群以及從云到云的流量，以確保你不會受到受損的Pod的傷害。

第4層-節(jié)點

節(jié)點級安全性同樣重要。為防止容器在VM或其他節(jié)點上爆發(fā)，請限制對節(jié)點以及控制平面的外部管理訪問，并注意開放的端口和服務(wù)。使基本操作系統(tǒng)保持最少，并使用CIS基準(zhǔn)對其進(jìn)行加固。最后，確保像其他任何VM一樣掃描和修補(bǔ)節(jié)點。

第5層–集群組件

Kubernetes集群中發(fā)生了各種各樣的事情，并且沒有保護(hù)它的多合一工具或策略。在較高的級別上，你應(yīng)該專注于：

API服務(wù)器–檢查你的訪問控制和身份驗證機(jī)制，并對動態(tài)Webhooks，Pod安全策略以及對Kubernetes API的公共網(wǎng)絡(luò)訪問執(zhí)行其他安全檢查；

訪問控制-使用基于角色的訪問控制（RBAC）對API服務(wù)器和Kubernetes secret實施最低特權(quán)原則

服務(wù)帳戶令牌–為了防止未經(jīng)授權(quán)的訪問，請限制對服務(wù)帳戶以及存儲服務(wù)帳戶令牌的所有secret的權(quán)限

審核日志記錄-確保已啟用

第三方組件–注意帶入集群中的內(nèi)容，以便知道集群中正在運行的內(nèi)容以及原因

Kubernetes版本– Kubernetes可以像任何其他系統(tǒng)一樣具有漏洞，并且必須及時進(jìn)行更新和修補(bǔ)。

Kubelet配置錯誤–負(fù)責(zé)容器編排以及與容器運行時的交互，Kubelet可能會被濫用和攻擊，以試圖提升特權(quán)。

Kubernetes的安全性似乎令人望而生畏，但是通過在堆棧的每一層上遵循最佳實踐，可以使容器與環(huán)境達(dá)到相同的高級別保護(hù)。因此，你可以享受快速，敏捷的開發(fā)帶來的好處。

參考：https://www.kubernetes.org.cn/9231.html

文章轉(zhuǎn)載：K8S中文社區(qū)

（版權(quán)歸原作者所有，侵刪）

編輯：jq