Docker容器安全的8大風(fēng)險(xiǎn)和33個(gè)最佳實(shí)踐丨IDCF
作者：StackRox
譯者：冬哥
原文：https://www.stackrox.io/blog/docker-security-101/
容器以及例如Kubernetes等編排器開(kāi)啟了應(yīng)用程序開(kāi)發(fā)方法的新時(shí)代，支持微服務(wù)架構(gòu)以及持續(xù)開(kāi)發(fā)和交付。根據(jù)我們最新的容器狀態(tài)和 Kubernetes 安全報(bào)告，Docker 是迄今為止最主要的容器運(yùn)行時(shí)引擎，滲透率為 91% 。
容器化有諸多的好處，因此得到了廣泛的采用。據(jù) Gartner 稱(chēng)，到 2020 年，超過(guò) 50% 的全球組織將在生產(chǎn)環(huán)境中運(yùn)行容器化應(yīng)用程序。然而，使用 Docker 容器構(gòu)建應(yīng)用程序也帶來(lái)了新的安全挑戰(zhàn)和風(fēng)險(xiǎn)。單個(gè)受損的 Docker 容器就可能會(huì)威脅到所有其他容器以及底層主機(jī)，這凸顯了Docker安全防護(hù)的重要性。
Docker安全防護(hù)大致可以分為兩個(gè)方面：防護(hù)和加固主機(jī)，使容器泄露不會(huì)導(dǎo)致主機(jī)泄露，以及防護(hù)Docker 容器。本文重點(diǎn)關(guān)注容器安全，重點(diǎn)介紹 Docker 容器安全風(fēng)險(xiǎn)和挑戰(zhàn)，并提供在構(gòu)建和部署階段強(qiáng)化環(huán)境以及在運(yùn)行時(shí)保護(hù) Docker 容器的最佳實(shí)踐。
鑒于 Kubernetes 的廣泛采用和在編排容器中的關(guān)鍵作用，我們還分享了保護(hù) Kubernetes 的最佳實(shí)踐。最后，我們提供了容器安全平臺(tái)應(yīng)該能夠回答的 11 個(gè)關(guān)鍵安全問(wèn)題，為你提供在生產(chǎn)環(huán)境中安全運(yùn)行容器和 Kubernetes 所需的洞察力和保護(hù)。
Docker 必須解決的 8 個(gè)容器安全挑戰(zhàn)
企業(yè)長(zhǎng)期以來(lái)一直在虛機(jī) (VM) 或裸機(jī)服務(wù)器上部署應(yīng)用程序。此類(lèi)基礎(chǔ)設(shè)施的安全性涉及保護(hù)你的應(yīng)用程序及其運(yùn)行的主機(jī)，然后在應(yīng)用程序運(yùn)行時(shí)加以保護(hù)。容器化引入了新的挑戰(zhàn)，亟需解決。
容器支持微服務(wù)，這增加了數(shù)據(jù)流量以及網(wǎng)絡(luò)和訪(fǎng)問(wèn)控制的復(fù)雜性。
容器依賴(lài)于基礎(chǔ)鏡像，想要了解鏡像的來(lái)源安全與否可能具有挑戰(zhàn)性。鏡像還可能包含漏洞，這些漏洞可以傳播到所有使用到此鏡像的所有容器。
容器的生命周期很短，因此監(jiān)控它們，尤其是在運(yùn)行時(shí)，可能非常困難。另一個(gè)安全風(fēng)險(xiǎn)來(lái)自對(duì)不斷變化的容器環(huán)境缺乏可見(jiàn)性。
與 VM 不同，容器不一定彼此隔離。一個(gè)不達(dá)標(biāo)的容器可能導(dǎo)致其他容器受損。
與傳統(tǒng) VM 相比，容器化環(huán)境具有更多組件，包括 Kubernetes，它本身就存在一系列安全挑戰(zhàn)。你能分辨出哪些部署或集群受到高嚴(yán)重性漏洞的影響嗎？有沒(méi)有暴露到互聯(lián)網(wǎng)？如果利用給定的漏洞，爆炸半徑是多少？容器是在生產(chǎn)環(huán)境還是開(kāi)發(fā)/測(cè)試環(huán)境中運(yùn)行？
容器配置是另一個(gè)帶來(lái)安全風(fēng)險(xiǎn)的領(lǐng)域。容器是否在不應(yīng)該的更高權(quán)限運(yùn)行？圖像是否啟動(dòng)了增加攻擊面的不必要服務(wù)？圖像中是否存儲(chǔ)有秘密？
作為最大的安全驅(qū)動(dòng)因素之一，鑒于容器環(huán)境的快速發(fā)展，合規(guī)性可能是一項(xiàng)特殊挑戰(zhàn)。許多有助于證明合規(guī)性的傳統(tǒng)組件（例如防火墻規(guī)則）在 Docker 環(huán)境中采用的形式非常不同。
最后，現(xiàn)有的服務(wù)器工作負(fù)載安全解決方案不足以應(yīng)對(duì)容器安全挑戰(zhàn)和風(fēng)險(xiǎn)。
26 個(gè) Docker 安全最佳實(shí)踐
以下是來(lái)自行業(yè)標(biāo)準(zhǔn)和 StackRox 客戶(hù)的最佳實(shí)踐列表，用于安全地配置你的 Docker 容器和鏡像。
始終使用最新版本的 Docker。例如，今年早些時(shí)候的runC漏洞在 Docker 版本18.09.2發(fā)布后很快就被修補(bǔ)了。
確保只有受信任的用戶(hù)加入到Docker 組成員，以便于只允許受信任的用戶(hù)控制 Docker 守護(hù)程序。查看這篇文章，了解有關(guān)減少 Docker 守護(hù)程序攻擊面的更多信息。
確保適當(dāng)?shù)囊?guī)則，可以提供審計(jì)跟蹤：
Docker 守護(hù)進(jìn)程
Docker 文件和目錄：
/var/lib/docker
/etc/docker
Docker.service
Docker.socket
/etc/default/docker
/etc/docker/daemon.json
/etc/sysconfig/docker
/usr/bin/containerd
/usr/sbin/runc
確保所有 Docker 文件和目錄由適當(dāng)?shù)挠脩?hù)（通常是 root 用戶(hù)）擁有，并且它們的文件權(quán)限設(shè)置為限制性值（參見(jiàn)Docker 守護(hù)程序配置文件的CIS 基準(zhǔn)部分），從而保護(hù)所有 Docker 文件和目錄。
使用具有有效注冊(cè)表證書(shū)的注冊(cè)表或使用 TLS 的注冊(cè)表，以最大程度地降低流量攔截的風(fēng)險(xiǎn)。
如果使用的容器沒(méi)有在鏡像中定義明確的容器用戶(hù)，你應(yīng)該啟用用戶(hù)命名空間支持，這將允許你將容器用戶(hù)重新映射到主機(jī)用戶(hù)。
禁止容器獲取新權(quán)限，（默認(rèn)情況下，容器允許獲取新權(quán)限），因此必須明確設(shè)置此配置。可以采取的另一個(gè)減少權(quán)限提升攻擊的步驟是刪除鏡像中的 setuid 和 setgid 權(quán)限。
作為最佳實(shí)踐，應(yīng)該以非 root 用戶(hù)身份運(yùn)行容器（UID 不是 0）。（默認(rèn)情況是，容器以root 用戶(hù)身份在容器內(nèi)以 root 用戶(hù)身份運(yùn)行。）
構(gòu)建容器時(shí)僅使用受信任的基礎(chǔ)鏡像。這個(gè)提示可能看起來(lái)顯而易見(jiàn)，但第三方注冊(cè)中心通常沒(méi)有針對(duì)存儲(chǔ)在其中的鏡像做任何治理策略。了解哪些鏡像可在 Docker 主機(jī)上使用、了解它們的出處、并查看其中的內(nèi)容非常重要。你還應(yīng)該為Docker 啟用內(nèi)容信任以進(jìn)行鏡像驗(yàn)證，并僅將經(jīng)過(guò)驗(yàn)證的包安裝到鏡像中。
使用不包含可能導(dǎo)致更大攻擊面的不必要軟件包的最小基礎(chǔ)鏡像。容器中的組件越少，可用攻擊向量的數(shù)量就越少，而且最小的鏡像也會(huì)產(chǎn)生更好的性能，因?yàn)榇疟P(pán)上的字節(jié)更少，復(fù)制鏡像的網(wǎng)絡(luò)流量也更少。BusyBox 和 Apline 是構(gòu)建最小基礎(chǔ)鏡像的兩個(gè)選項(xiàng)。
實(shí)施強(qiáng)有力的治理策略，強(qiáng)制執(zhí)行頻繁的鏡像掃描。在進(jìn)入構(gòu)建階段之前，應(yīng)拒絕陳舊鏡像,或重新掃描最近未掃描的鏡像。
構(gòu)建一個(gè)工作流，定期識(shí)別并從主機(jī)中刪除陳舊或未使用的鏡像和容器。
不要將機(jī)密存儲(chǔ)在鏡像/Dockerfile 中。默認(rèn)情況下，你可以將機(jī)密存儲(chǔ)在 Dockerfile 中，但將機(jī)密存儲(chǔ)在鏡像中會(huì)使該鏡像的任何用戶(hù)都可以訪(fǎng)問(wèn)機(jī)密。需要密文時(shí)，請(qǐng)使用密文管理工具。
運(yùn)行容器時(shí)，刪除容器運(yùn)行所需的所有功能?？梢允褂?Docker 的 CAP DROP 功能刪除特定容器的功能（也稱(chēng)為 Linux 功能），并使用 CAP ADD 僅添加容器正常運(yùn)行所需的那些功能。
不要運(yùn)行帶有--privileged標(biāo)志的容器，因?yàn)檫@種類(lèi)型的容器將具有底層主機(jī)可用的大部分功能。此標(biāo)志還會(huì)覆蓋你使用 CAP DROP 或 CAP ADD 設(shè)置的任何規(guī)則。
不要在容器上掛載敏感的主機(jī)系統(tǒng)目錄，尤其是在可寫(xiě)模式下，這可能會(huì)使它們暴露在被惡意更改的情況下，從而可能導(dǎo)致主機(jī)受損。
不要在容器中運(yùn)行 sshd。默認(rèn)情況下，ssh 守護(hù)進(jìn)程不會(huì)在容器中運(yùn)行，不應(yīng)該安裝 ssh 守護(hù)進(jìn)程以簡(jiǎn)化 SSH 服務(wù)器的安全管理。
不要在容器內(nèi)映射任何低于 1024 的端口，因?yàn)樗鼈儽徽J(rèn)為是特權(quán)端口，會(huì)傳輸敏感數(shù)據(jù)。默認(rèn)情況下，Docker 將容器端口映射到 49153–65525 范圍內(nèi)的端口，但它允許將容器映射到特權(quán)端口。作為一般經(jīng)驗(yàn)法則，確保容器上只打開(kāi)需要的端口。
除非必要，否則不要共享主機(jī)的網(wǎng)絡(luò)命名空間、進(jìn)程命名空間、IPC 命名空間、用戶(hù)命名空間或 UTS 命名空間，以確保 Docker 容器和底層主機(jī)之間的適當(dāng)隔離。
指定容器按設(shè)計(jì)運(yùn)行所需的內(nèi)存和 CPU 數(shù)量，而不是依賴(lài)于任意數(shù)量。默認(rèn)情況下，Docker 容器無(wú)限制地平等共享其資源。
將容器的根文件系統(tǒng)設(shè)置為只讀。一旦運(yùn)行，容器不需要更改根文件系統(tǒng)。對(duì)根文件系統(tǒng)所做的任何更改都可能是出于惡意目的。為了保持容器的不可變特性——新容器不會(huì)被打補(bǔ)丁而是從新鏡像中重新創(chuàng)建——你不應(yīng)該使根文件系統(tǒng)可寫(xiě)。
施加 PID 限制。容器的優(yōu)點(diǎn)之一是嚴(yán)格的進(jìn)程標(biāo)識(shí)符 (PID) 控制。內(nèi)核中的每個(gè)進(jìn)程都有一個(gè)唯一的 PID，容器利用 Linux PID 命名空間為每個(gè)容器提供一個(gè)單獨(dú)的 PID 層次結(jié)構(gòu)視圖。對(duì) PID 進(jìn)行限制有效地限制了每個(gè)容器中運(yùn)行的進(jìn)程數(shù)量。限制容器中的進(jìn)程數(shù)量可以防止過(guò)度產(chǎn)生新進(jìn)程和潛在的惡意橫向移動(dòng)。施加 PID 限制還可以防止分叉炸彈（不斷自我復(fù)制的進(jìn)程）和異常進(jìn)程。大多數(shù)情況下，如果你的服務(wù)始終運(yùn)行特定數(shù)量的進(jìn)程，那么將PID 限制設(shè)置為該確切數(shù)量可以減輕許多惡意行為，包括反向 shell 和遠(yuǎn)程代碼注入。
不要將掛載傳播規(guī)則配置為共享。共享掛載傳播意味著對(duì)掛載所做的任何更改都將傳播到該掛載的所有實(shí)例。應(yīng)該將掛載傳播設(shè)置為從屬或私有模式，以便對(duì)卷所做的必要更改不會(huì)與不需要該更改的容器共享（或傳播到）。
不要使用帶有特權(quán)或 user=root 選項(xiàng)的 docker exec 命令，因?yàn)榇嗽O(shè)置可以為容器提供擴(kuò)展的 Linux 功能。
不要使用默認(rèn)網(wǎng)橋“docker0”。使用默認(rèn)網(wǎng)橋會(huì)使你面臨 ARP 欺騙和 MAC 泛洪攻擊。相反，容器應(yīng)該在用戶(hù)定義的網(wǎng)絡(luò)上，而不是默認(rèn)的“docker0”網(wǎng)橋。
不要在容器內(nèi)掛載 Docker 套接字，因?yàn)檫@種方法將允許容器內(nèi)的進(jìn)程執(zhí)行命令，使其完全控制主機(jī)。
Kubernetes 安全的7個(gè)最佳實(shí)踐
作為容器編排的事實(shí)標(biāo)準(zhǔn)，Kubernetes 在確保應(yīng)用程序安全方面發(fā)揮著關(guān)鍵作用。為了有效保護(hù)容器化應(yīng)用程序，你必須利用來(lái)自 Kubernetes 的上下文信息及其原生策略執(zhí)行功能。例如，Kubernetes 有幾個(gè)內(nèi)置的安全功能，可以更輕松地操作整個(gè)生命周期的容器安全性，包括 Kubernetes RBAC、網(wǎng)絡(luò)策略和準(zhǔn)入控制器。利用 Kubernetes 中這些固有控制功能的強(qiáng)大功能來(lái)保護(hù)你的容器化環(huán)境。
以下是一些 Kubernetes 安全最佳實(shí)踐，可幫助實(shí)現(xiàn)整個(gè)生命周期的容器安全性。
對(duì)于 RBAC，將角色和 ClusterRoles 指定給特定用戶(hù)或用戶(hù)組，而不是向任何用戶(hù)或用戶(hù)組授予集群管理員權(quán)限。
使用 Kubernetes RBAC 時(shí)避免重復(fù)權(quán)限，因?yàn)檫@樣做可能會(huì)產(chǎn)生操作問(wèn)題。
刪除未使用或非活動(dòng)的 RBAC 角色，以便在故障排除或調(diào)查安全事件時(shí)將注意力集中在活動(dòng)角色上。
使用 Kubernetes 網(wǎng)絡(luò)策略來(lái)隔離Pod，并明確地只允許應(yīng)用程序運(yùn)行所需的通信路徑。否則，將面臨橫向和南北威脅。
如果pod 需要Internet 訪(fǎng)問(wèn)（入口或出口），請(qǐng)創(chuàng)建適當(dāng)?shù)木W(wǎng)絡(luò)策略來(lái)強(qiáng)制執(zhí)行正確的網(wǎng)絡(luò)分段/防火墻規(guī)則，然后創(chuàng)建所述網(wǎng)絡(luò)策略所針對(duì)的標(biāo)簽，最后將pod 與該標(biāo)簽相關(guān)聯(lián)。
使用 PodSecurityPolicy 準(zhǔn)入控制器來(lái)確保執(zhí)行適當(dāng)?shù)闹卫聿呗?。PodSecurityPolicy 控制器可以阻止容器以 root 身份運(yùn)行或確保容器的根文件系統(tǒng)以只讀方式掛載（這些建議聽(tīng)起來(lái)應(yīng)該很熟悉，因?yàn)樗鼈兌荚谇懊娴?Docker 措施列表中）。
使用 Kubernetes 準(zhǔn)入控制器強(qiáng)制執(zhí)行鏡像注冊(cè)表治理策略，以便自動(dòng)拒絕從不受信任的注冊(cè)表中獲取的所有鏡像。
最后的想法——確保你能回答這 11 個(gè)關(guān)于 Docker 容器環(huán)境的安全問(wèn)題
為了幫助快速評(píng)估你的安全狀況，如果你的云原生堆棧已采用適當(dāng)?shù)陌踩胧?gòu)建，我們編制了安全、DevSecOps 或 DevOps 團(tuán)隊(duì)?wèi)?yīng)該能夠輕松回答的問(wèn)題列表。
上次掃描日期超過(guò) 60 天的主機(jī)上有多少個(gè)鏡像？
有多少鏡像/容器具有高嚴(yán)重性漏洞？
這些高嚴(yán)重性易受攻擊的容器會(huì)影響哪些部署？
受影響的部署中是否有任何容器存儲(chǔ)了機(jī)密？
是否有任何易受攻擊的容器以 root 或特權(quán)標(biāo)志運(yùn)行？
Pod 中是否有任何易受攻擊的容器沒(méi)有與之關(guān)聯(lián)的網(wǎng)絡(luò)策略（意味著它允許所有通信）？
生產(chǎn)中運(yùn)行的任何容器是否受此漏洞影響？
我們使用的鏡像來(lái)自哪里？
我們?nèi)绾巫柚箯牟皇苄湃蔚淖?cè)表中提取的鏡像？
我們是否能夠在容器運(yùn)行時(shí)看到哪些進(jìn)程正在執(zhí)行？
哪些集群、命名空間和節(jié)點(diǎn)不符合 Docker 和 Kubernetes 的 CIS 基準(zhǔn)？
遵循列表中匯編的這些最佳實(shí)踐，你將可以采取最重要的步驟來(lái)成功強(qiáng)化Docker 和 Kubernetes 環(huán)境并保護(hù)你的關(guān)鍵業(yè)務(wù)應(yīng)用程序。
#規(guī)?；艚萋?lián)合作戰(zhàn)沙盤(pán)之「烏托邦計(jì)劃」，玩樂(lè)高，學(xué)敏捷，將“多團(tuán)隊(duì)敏捷協(xié)同”基因內(nèi)化在研發(fā)流程中，為規(guī)?；嵘邪l(fā)效能保駕護(hù)航！!??
2022年社區(qū)開(kāi)年賦能計(jì)劃，#DevOps黑客馬拉松?和?#規(guī)模化敏捷聯(lián)合作戰(zhàn)沙盤(pán)之「烏托邦計(jì)劃」兩大公開(kāi)課，將在北京、上海、深圳、大連、成都等多個(gè)城市開(kāi)啟
企業(yè)組隊(duì)參賽&個(gè)人參賽均可，趕緊上車(chē)~??
