2022容器最佳安全實踐白皮書

Docker容器最佳安全實踐白皮書PAGEPAGE2目錄主機安全配置 6為容器創(chuàng)建一個單獨的分區(qū) 6加固容器宿主機 7更新docker到最新版本 8只有受信任的用戶才能控制docker守護進程 9審計docker守護進程 10審計docker文件和目錄-/var/lib/docker 11審計docker文件和目錄-/etc/docker 12審計docker文件和目錄-docker.service 13審計docker文件和目錄-docker.socket 14審計docker文件和目錄-/etc/default/docker 15審計docker文件和目錄-/etc/docker/daemon.json 16審計docker文件和目錄-/usr/bin/docker-containerd 17審計docker文件和目錄-/usr/bin/docker-runc 18docker守護進程配置 19限制默認網(wǎng)橋上容器之間的網(wǎng)絡流量 19設置日志級別為info 20允許docker更改IPtables 21不使用不安全的鏡像倉庫 22不使用aufs存儲驅(qū)動程序 23docker守護進程配置TLS身份認證 24配置合適的ulimit 25啟用用戶命名空間 26使用默認cgroup 28設置容器的默認空間大小 29啟用docker客戶端命令的授權 30配置集中和遠程日志記錄 31禁用舊倉庫版本（v1）上的操作 32啟用實時恢復 33禁用userland代理 34應用守護進程范圍的自定義seccomp配置文件 35生產(chǎn)環(huán)境中避免實驗性功能 36限制容器獲取新的權限 37docker守護程序文件配置 38設置docker.service文件的所有權為root:root 38設置docker.service文件權限為644或更多限制性 39設置docker.socket文件所有權為root:root 40設置docker.socket文件權限為644或更多限制性 41設置/etc/docker目錄所有權為root:root 42設置/etc/docker目錄權限為755或更多限制性 43設置倉庫證書文件所有權為root：root 44設置倉庫證書文件權限為444或更多限制性 45設置TLSCA證書文件所有權為root：root 46設置TLSCA證書文件權限為444或更多限制性 47設置docker服務器證書文件所有權為root：root 48設置docker服務器證書文件權限為444或更多限制 49設置docker服務器證書密鑰文件所有權為root：root 50設置docker服務器證書密鑰文件權限為400 51設置docker.sock文件所有權為root：docker 52設置docker.sock文件權限為660或更多限制性 53設置daemon.json文件所有權為root：root 54設置daemon.json文件權限為644或更多限制性 55設置/etc/default/docker文件所有權為root：root 56設置/etc/default/docker文件權限為644或更多限制性 57容器鏡像和構建文件 58創(chuàng)建容器的用戶 58容器使用可信的基礎鏡像 59容器中不安裝沒有必要的軟件包 59掃描鏡像漏洞并且構建包含安全補丁的鏡像 61啟用docker內(nèi)容信任 62將HEALTHCHECK說明添加到容器鏡像 63不在dockerfile中單獨使用更新命令 64鏡像中刪除setuid和setgid權限 65在dockerfile中使用copy而不是add 66涉密信息不存儲在dockerfile 67僅安裝已經(jīng)驗證的軟件包 68容器運行時保護 69啟用AppArmor配置文件 69設置SElinux安全選項 71linux內(nèi)核功能在容器內(nèi)受限 73不使用特權容器 75敏感的主機系統(tǒng)目錄未掛載在容器上 76SSH不在容器中運行 77特權端口禁止映射到容器內(nèi) 78只映射必要的端口 79不共享主機的網(wǎng)絡命名空間 80確保容器的內(nèi)存使用合理 81正確設置容器上的CPU優(yōu)先級 82設置容器的根文件系統(tǒng)為只讀 84確保進入容器的流量綁定到特定的主機接口 86容器重啟策略on-failure設置為5 87確保主機的進程命名空間不共享 88主機的IPC命令空間不共享 89主機設備不直接共享給容器 90設置默認的ulimit配置（在需要時） 92設置裝載傳播模式不共享 93設置主機的UTS命令空間不共享 94默認的seccomp配置文件未禁用 95dockerexec命令不能使用特權選項 95dockerexec命令不能與user選項一起使用 97確保cgroug安全使用 98限制容器獲得額外的權限 99檢查容器運行時狀態(tài) 100確保docker命令始終獲取最新版本的鏡像 101限制使用PIDcgroup 102不要使用docker的默認網(wǎng)橋docker0 103不共享主機的用戶命名空間 104任何容器內(nèi)不能安裝docker套接字 105docker安全操作 106避免鏡像泛濫 106避免容器泛濫 108docker集群配置 109不啟用群集模式 109在群集中最小數(shù)量創(chuàng)建管理器節(jié)點 110群集服務綁定到特定的主機接口 111數(shù)據(jù)在的不同節(jié)點上進行加密 112管理Swarm集群中的涉密信息 113swarmmanager在自動鎖定模式下運行 114swarmmanager自動鎖定秘鑰周期性輪換 115節(jié)點證書適當輪換 116CA根證書根據(jù)需要進行輪換 117Docker容器最佳安全實踐白皮書（V1.0）Docker容器最佳安全實踐白皮書（V1.0）PAGEPAGE100主機安全配置為容器創(chuàng)建一個單獨的分區(qū)描述所有Docker容器及數(shù)據(jù)和元數(shù)據(jù)都存儲在/var/lib/docker目錄下。默認情況下，/var/lib/docker將根據(jù)可用性掛載在/或/var分區(qū)下。安全出發(fā)點Docker依賴于/var/lib/docker作為默認目錄，其存儲所有Docker相關文件，包括鏡像文件。該目錄可能會被惡意的寫滿，導致Docker、甚至主機可能無法使用。因此，建議為存儲Docker文件創(chuàng)建一個單獨的分區(qū)（邏輯卷）。審計方法grep/var/lib/docker/etc/fstab結(jié)果判定應該返回/var/lib/docker掛載點的分區(qū)詳細信息。修復措施新安裝docker時，為/var/lib/docker掛載點創(chuàng)建一個單獨的分區(qū)。對于先前安裝的系統(tǒng)，請使用邏輯卷管理器（LVM）創(chuàng)建分區(qū)。影響None默認值默認情況下，/var/lib/docker將根據(jù)可用性掛載在/或/var分區(qū)下。加固容器宿主機描述容器在Linux主機上運行。容器主機可以運行一個或多個容器。加強主機以緩解主機安全配置錯誤是非常重要的安全出發(fā)點應該遵循基礎架構安全最佳實踐并加強宿主機操作系統(tǒng)。保證主機系統(tǒng)的安全可以確保主機漏洞得控制。若不加固主機系統(tǒng)可能導致安全問題。審計方法確保遵守主機的安全規(guī)范。詢問系統(tǒng)管理員當前主機系統(tǒng)符合哪個安全標準。確保主機系統(tǒng)實際符合主機制定的安全規(guī)范。結(jié)果判定查看主機加固記錄修復措施使用主機安全標準加固主機影響None默認值默認情況下，主機只有默認設置，沒有加固。docker描述Docker軟件頻繁發(fā)布更新，舊版本可能存在安全漏洞。安全出發(fā)點通過及時了解Docker更新，Docker軟件中的漏洞可以得到修復。攻擊者可能會嘗試獲得訪問權限或提升權限時利用已知的漏洞。不安裝常規(guī)的Docker更新可能會讓現(xiàn)有的Docker軟件受到攻擊?？赡軙е绿嵘龣嘞?，未經(jīng)授權的訪問或其他安全漏洞。所以需要跟蹤新版本并根據(jù)需要進行更新。審計方法執(zhí)行以下命令并驗證Docker版本是否為必要的最新版本。Dockerversion結(jié)果判定和最新版本進行比對，查看是否為最新修復措施跟蹤Docker發(fā)布并根據(jù)需要進行更新。影響對Docker版本更新進行風險評估，了解它們可能會如何影響Docker操作。請注意，有些使用Docker的第三方產(chǎn)品可能需要支持較老版本的Docker。默認值不適用docker描述Docker守護進程需要'root'權限。對于添加到“docker”組的用戶為提供了完整的“root”訪問權限。安全出發(fā)點Docker允許在Docker主機和訪客容器之間共享目錄，而不會限制容器的訪問權限。這意味著可以啟動容器并將主機上的/目錄映射到容器。容器將能夠不受任何限制地更改您的主機文件系統(tǒng)。簡而言之，這意味著您只需作為“docker”組的成員即可獲得較高的權限，然后在主機上啟動具有映射/目錄的容器。審計方法在docker主機上執(zhí)行以下命令，并確保只有可信用戶是docker組的成員。getentgroupdocker結(jié)果判定判斷是否必須要加入docker組的用戶修復措施從'docker'組中刪除任何不受信任的用戶。另外，請勿在主機上創(chuàng)建敏感目錄到容器卷的映射。影響作為普通用戶構建和執(zhí)行容器的權限將受到限制默認值不適用docker描述審計所有活動的Docker守護進程安全出發(fā)點除了審核常規(guī)的Linux文件系統(tǒng)和系統(tǒng)調(diào)用外，還要審計Docker守護進程。Docker守護進程以'root'特權運行。因此有必要審核其活動和使用情況。審計方法驗證是否存在Docker守護程序的審核規(guī)則。例如，執(zhí)行以下命令：auditctl-l|grep/usr/bin/docker結(jié)果判定應該列出Docker守護程序的規(guī)則修復措施為Docker守護進程添加一條規(guī)則，例如，在/etc/audit/audit.rules文件中將該行添加到以下行中或者運行命令直接添加：auditctl-w/usr/bin/docker-kdocker然后，重新啟動審計守護進程。例如serverauditdrestart影響審計生成相當大的日志文件。確保定期歸檔它們。另外，創(chuàng)建一個單獨的審計分區(qū)以避免寫滿根文件系統(tǒng)。默認值默認，Docker守護進程沒有審計參考文獻1./documentation/enUS/Red_Hat_Enterprise_Linux/6/html/Security_Guide/chap-system_auditing.htmldocker-/var/lib/docker描述審計以下目錄：/var/lib/docker.安全出發(fā)點除了審核常規(guī)的Linux文件系統(tǒng)和系統(tǒng)調(diào)用外，還要審核所有Docker相關的文件和目錄。Docker守護進程以'root'特權運行。它的運行取決于一些關鍵文件和目錄。/var/lib/docker就是這樣一個目錄。它包含有關docker的所有信息。審計方法驗證是否存在與/var/lib/docker目錄相對應的審計規(guī)則。例如，執(zhí)行以下命令：auditctl-l|grep/var/lib/docker結(jié)果判定這應該列出/var/lib/docker目錄的規(guī)則。修復措施為/var/lib/docker目錄添加一條規(guī)則。例如，將以下行添加到/etc/audit/audit.rules文件中：-w/var/lib/docker-kdocker然后，重新啟動審計守護進程。例如serviceauditdrestart影響審計生成相當大的日志文件。確保定期歸檔它們。另外，創(chuàng)建一個單獨的審計分區(qū)以避寫滿根文件系統(tǒng)。默認值默認情況下，Docker相關的文件和目錄不被審計參考文獻1./documentation/enUS/Red_Hat_Enterprise_Linux/6/html/Security_Guide/chap-system_auditing.htmldocker-/etc/docker描述審計以下目錄/etc/docker安全出發(fā)點除了審核常規(guī)的Linux文件系統(tǒng)和系統(tǒng)調(diào)用外，還要審核所有Docker相關的文件和目錄。Docker守護進程以'root'特權運行。它的行為取決于一些關鍵文件和目錄。/etc/docker就是這樣一個目錄。它包含用于Docker守護進程和Docker客戶端之間的TLS通信的各種證書和密鑰。審計方法驗證是否存在與/etc/docker目錄相對應的審計規(guī)則。例如，執(zhí)行以下命令：auditctl-l|grep/etc/docker結(jié)果判定這應該列出/etc/docker目錄的規(guī)則。修復措施為/etc/docker目錄添加一條規(guī)則。例如，在/etc/audit/audit.rules文件中添加如下所示的行-w/etc/docker-kdocker然后，重新啟動審計守護進程。例如serviseauditdrestart影響審計生成相當大的日志文件。確保定期歸檔它們。另外，創(chuàng)建一個單獨的審計分區(qū)以避免寫滿根文件系統(tǒng)默認值默認情況下，Docker相關的文件和目錄不被審計參考文獻1./documentation/enUS/Red_Hat_Enterprise_Linux/6/html/Security_Guide/chap-system_auditing.htmldocker-docker.service描述審核docker.service（如果適用）。安全出發(fā)點除了正常的Linux文件系統(tǒng)和系統(tǒng)調(diào)用審核外，還可以審核所有與Docker相關的文件和目錄。Docker守護程序以“root”權限運行。它的行為取決于一些關鍵文件和目錄。docker.service是一個這樣的文件。如果管理員更改了守護程序參數(shù)，則docker.service文件可能會出現(xiàn)問題。它支持Docker守護進程的各種參數(shù)。審計方法步驟1：找出文件位置：systemctlshow-pFragmentPathdocker.service步驟2：如果文件不存在，則此建議不適用。如果該文件存在，請驗證是否存在與該文件相對應的審核規(guī)則：例如，執(zhí)行以下命令：auditctl-l|grepdocker.service結(jié)果判定應該根據(jù)其位置列出docker.service的規(guī)則。修復措施如果該文件存在，請為其添加規(guī)則。例如，在/etc/audit/audit.rules文件中添加以下行：-w/usr/lib/systemd/system/docker.service-kdocker然后，重新啟動審計守護進程。例如，serviseauditdrestart影響審核會生成相當大的日志文件。確保定期歸檔。另外，創(chuàng)建一個單獨的審計分區(qū)，以避免填寫根文件系統(tǒng)。默認值默認情況下，Docker相關的文件和目錄不會被審計。文件docker.service可能在系統(tǒng)上不可用參考文獻1./documentation/enUS/Red_Hat_Enterprise_Linux/6/html/Security_Guide/chap-system_auditing.htmldocker-docker.socket描述審核docker.socket（如果適用）。安全出發(fā)點除了正常的Linux文件系統(tǒng)和系統(tǒng)調(diào)用審核外，還可以審核所有與Docker相關的文件和目錄。Docker守護程序以“root”權限運行。它的行為取決于一些關鍵文件和目錄。docker.socket就是一個這樣的文件。如果管理員更改了守護程序參數(shù)，則docker.socket文件可能會出現(xiàn)問題。它支持Docker守護進程的各種參數(shù)。審計方法步驟1：找出文件位置：systemctlshow-pFragmentPathdocker.socket步驟2：如果文件不存在，則此建議不適用。如果該文件存在，請驗證是否存在與該文件相對應的審核規(guī)則：例如，執(zhí)行以下命令：auditctl-l|grepdocker.socket結(jié)果判定這應該根據(jù)其位置列出docker.socket的規(guī)則修復措施如果文件存在，為其添加審計策略：.在/etc/audit/audit.rules文件添加一行:-w/usr/lib/systemd/system/docker.socket-kdocker然后重啟審計進程：serviceauditdrestart影響審核會生成相當大的日志文件。確保定期歸檔。另外，創(chuàng)建一個單獨的審計分區(qū)，以避免填寫根文件系統(tǒng)。默認值默認情況下，Docker相關的文件和目錄不被審計。文件docker.socket可能在系統(tǒng)上不可用，在這種情況下，此建議不適用。參考文獻1./documentation/enUS/Red_Hat_Enterprise_Linux/6/html/Security_Guide/chap-system_auditing.htmldocker-/etc/default/docker描述審核/etc/default/docker,（如果適用）安全出發(fā)點除了正常的Linux文件系統(tǒng)和系統(tǒng)調(diào)用審核外，還可以審核所有與Docker相關的文件和目錄。Docker守護程序以“root”權限運行。它的行為取決于一些關鍵文件和目錄。/etc/default/docker是一個這樣的文件。它支持Docker守護進程的各種參數(shù)。審計方法驗證是否存在與/etc/default/docker文件相對應的審計規(guī)則。例如，執(zhí)行以下命令：auditctl-l|grep/etc/default/docker結(jié)果判定這應該列出/etc/default/docker文件的規(guī)則。修復措施如果文件存在，為其添加審計策略：.在/etc/audit/audit.rules文件添加一行:-w/etc/default/docker-kdocker然后重啟審計進程：serviceauditdrestart影響審核會生成相當大的日志文件。確保定期歸檔。另外，創(chuàng)建一個單獨的審計分區(qū)，以避免填寫根文件系統(tǒng)。默認值默認情況下，Docker相關的文件和目錄不被審計。文件/etc/default/docker可能不可用。在這種情況下，此建議不適用。參考文獻1./documentation/enUS/Red_Hat_Enterprise_Linux/6/html/Security_Guide/chap-system_auditing.htmldocker-/etc/docker/daemon.json描述審計/etc/docker/daemon.json,如適用的話安全出發(fā)點除了正常的Linux文件系統(tǒng)和系統(tǒng)調(diào)用審核外，還可以審核所有與Docker相關的文件和目錄。Docker守護程序以“root”權限運行。它的行為取決于一些關鍵文件和目錄。/etc/docker/daemon.json是一個這樣的文件。它支持Docker守護進程的各種參數(shù)。審計方法驗證是否存在與/etc/docker/daemon.json文件相對應的審計規(guī)則。例如，執(zhí)行以下命令：auditctl-l|grep/etc/docker/daemon.json結(jié)果判定這應該列出/etc/docker/daemon.json文件的規(guī)則。修復措施添加/etc/docker/daemon.json文件的規(guī)則例如，在/etc/audit/audit.rules文件中添加如下行：-w/etc/docker/daemon.json-kdocker然后，重新啟動審計守護程序。例如serviceauditdrestart影響審核會生成相當大的日志文件。確保定期歸檔。另外，創(chuàng)建一個單獨的審計分區(qū)，以避免填寫根文件系統(tǒng)。默認值默認情況下，Docker相關的文件和目錄不被審計。.文件/etc/docker/daemon.json可能在系統(tǒng)上可用。在這種情況下，此建議不適用。參考文獻1./documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/chapsystem_auditing.html2./engine/reference/commandline/dockerd/#daemon-configuration-filedocker-/usr/bin/docker-containerd描述審計/usr/bin/docker-containerd,如果適用的話安全出發(fā)點除了正常的Linux文件系統(tǒng)和系統(tǒng)調(diào)用審核外，還可以審核所有與Docker相關的文件和目錄。Docker守護程序以“root”權限運行。它的行為取決于一些關鍵文件和目錄。/usr/bin/docker-containerd就是這樣的文件.Docker現(xiàn)在依賴于containerd和runC來生成容器。審計方法驗證是否存在與/usr/bin/docker-containerd文件相對應的審計規(guī)則。例如，執(zhí)行以下命令：auditctl-l|grep/usr/bin/docker-containerd結(jié)果判定這應該列出/usr/bin/docker-containerd文件的規(guī)則。修復措施添加/usr/bin/docker-containerd文件的規(guī)則例如，在/etc/audit/audit.rules文件中添加如下行：:-w/usr/bin/docker-containerd-kdocker然后，重新啟動審計守護程序。例如serviceauditdrestart影響審核會生成相當大的日志文件。確保定期歸檔。另外，創(chuàng)建一個單獨的審計分區(qū)，以避免填寫根文件系統(tǒng)。默認值默認情況下，Docker相關的文件和目錄不被審計。.文件/usr/bin/dockercontainerd可能在系統(tǒng)上可用。在這種情況下，此建議不適用。參考文獻1./documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/chap-system_auditing.html/docker/docker/pull/20662https:/containerd.tools/docker-/usr/bin/docker-runc描述審計/usr/bin/docker-runc,如果適用的話.安全出發(fā)點除了正常的Linux文件系統(tǒng)和系統(tǒng)調(diào)用審核外，還可以審核所有與Docker相關的文件和目錄。Docker守護程序以“root”權限運行。它的行為取決于一些關鍵文件和目錄。/usr/bin/docker-runc是一個這樣的文件。Docker現(xiàn)在依賴于containerd和runC來生成容器。審計方法驗證是否存在與/usr/bin/docker-runc文件相對應的審核規(guī)則。例如，執(zhí)行以下命令：auditctl-l|grep/usr/bin/docker-runc結(jié)果判定這應該列出/usr/bin/docker-runc文件的規(guī)則。修復措施添加/usr/bin/docker-runc文件的規(guī)則。例如，在/etc/audit/audit.rules文件中添加如下行：-w/usr/bin/docker-runc-kdocker然后，重新啟動審計守護程序。例如serviceauditdrestart影響審核會生成相當大的日志文件。確保定期歸檔。另外，創(chuàng)建一個單獨的審計分區(qū)，以避免填寫根文件系統(tǒng)。默認值默認情況下，Docker相關的文件和目錄不被審計。文件/usr/bin/dockerrunc可能在系統(tǒng)上可用。在這種情況下，此建議不適用。參考文獻1./documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/chap-system_auditing.html2./docker/docker/pull/206623.https://containerd.tools/4./opencontainers/runcdocker限制默認網(wǎng)橋上容器之間的網(wǎng)絡流量描述默認情況下，默認網(wǎng)橋上同一主機上的容器之間允許所有網(wǎng)絡通信。如果不需要，限制所有的容器間通信。將需要通信的特定容器鏈接在一起?；蛘邉?chuàng)建自定義網(wǎng)絡，并只加入需要與該自定義網(wǎng)絡通信的容器。安全出發(fā)點默認情況下，默認網(wǎng)橋上同一主機上的所有容器之間啟用不受限制的網(wǎng)絡通信。因此，每個容器都有可能讀取同一主機上容器網(wǎng)絡上的所有數(shù)據(jù)包。這可能會導致意外和不必要的信息泄露給其他容器。因此，限制默認網(wǎng)橋上的容器間通信。審計方法運行以下命令并確認默認網(wǎng)橋已被配置為限制集裝箱間通信。dockernetworkls--quiet|xargsdockernetworkinspect--format'{{.Name}}：{{.Options}}'結(jié)果判定它應該返回默認網(wǎng)橋的work.bridge.enable_icc：false。修復措施在守護進程模式下運行docker并傳遞--icc=false作為參數(shù)。例如，dockerd--icc=false或者可以遵循Docker文檔并創(chuàng)建自定義網(wǎng)絡，并只加入需要與該自定義網(wǎng)絡通信的容器。--icc參數(shù)僅適用于默認泊塢橋，如果使用自定義網(wǎng)絡，則應采用分段網(wǎng)絡的方法。影響默認網(wǎng)橋上的容器間通信將被禁用。如果需要在同一主機上的容器之間進行通信，則需要使用容器鏈接來明確定義它，或者必須定義自定義網(wǎng)絡。默認值默認情況下，默認網(wǎng)橋上允許所有容器間通信。參考文獻/engine/userguide/networking//engine/userguide/networking/default_network/container-communication/#communication-between-containersinfo描述將Docker守護程序日志級別設置為“info”。安全出發(fā)點設置適當?shù)娜罩炯墑e，配置Docker守護程序以記錄需要查看的事件?！癷nfo”及以上的基準日志級別將捕獲除調(diào)試日志之外的所有日志。若無必須，不應該在'debug'日志級別運行Docker守護進程審計方法ps-ef|grepdockerd結(jié)果判定確保--log-level參數(shù)不存在或存在，然后將其設置為info。修復措施運行Docker守護進程如下：dockerd--log-level=“info”影響None.默認值默認情況下，Docker守護程序設置為“info”的日志級別。參考文獻1./edge/engine/reference/commandline/dockerd/dockerIPtables描述Iptables用于建立，維護和檢查Linux內(nèi)核中的IP包過濾規(guī)則表。允許Docker守護程序更改iptables安全出發(fā)點Docker會根據(jù)用戶為容器選擇網(wǎng)絡選項的方式自動對iptables進行必要的更改（如果允許的話）。建議讓Docker服務器自動更改iptables，以避免可能妨礙容器與外界通信的網(wǎng)絡配置錯誤。另外，當每次選擇運行容器或修改網(wǎng)絡選項時，可以自動更新iptables的配置。審計方法ps-ef|grepdockerd結(jié)果判定確保'--iptables'參數(shù)不存在或不設置為'false'修復措施不要使用'--iptables=false'參數(shù)運行Docker守護程序。例如，不要像下面那樣啟動Docker守護進程：dockerd--iptables=false影響Docker守護進程服務需要在啟動之前啟用iptables規(guī)則。在Docker守護進程操作期間任何重新啟動iptables都可能導致丟失docker創(chuàng)建的規(guī)則。使用iptables-persistent持久iptables規(guī)則可以幫助減輕這種影響。默認值默認情況下，'iptables'設置為'true'。參考文獻/engine/userguide/networking/default_network/container-communication/https://fralef.me/docker-and-iptables.html不使用不安全的鏡像倉庫描述Docker在默認情況下，私有倉庫被認為是安全的安全出發(fā)點一個安全的鏡像倉庫建議使用TLS。在/etc/docker/certs.d/<registry-name>/目錄下，將鏡像倉庫的CA證書副本放置在Docker主機上。不安全的鏡像倉庫是沒有有效的鏡像倉庫證書或不使用TLS的鏡像倉庫。不應該在生產(chǎn)環(huán)境中使用任何不安全的鏡像倉庫。不安全的鏡像倉庫中的鏡像可能會被篡改，從而導致生產(chǎn)系統(tǒng)可能受到損害。此外，如果鏡像倉庫被標記為不安全，則“dockerpull”，“dockerpush”和“dockersearch”命令并不能發(fā)現(xiàn)，那樣用戶可能無限期地使用不安全的鏡像倉庫而不會發(fā)現(xiàn)。審計方法執(zhí)行以下命令，了解是否使用不安全的倉庫：ps-ef|grepdockerd結(jié)果判定確?！?-insecure-registry”參數(shù)不存在修復措施不要使用任何不安全的鏡像倉庫。例如，不要像下面那樣啟動Docker守護進程：dockerd-insecure-registry/16影響None.默認值默認情況下，Docker假定所有的本地鏡像倉庫都是安全的。參考文獻1./registry/insecure/aufs描述不要使用'aufs'作為Docker實例的存儲驅(qū)動安全出發(fā)點‘a(chǎn)ufs'存儲驅(qū)動程序是較舊的存儲驅(qū)動程序。它基于Linux內(nèi)核補丁集，不Linuxaufs'驅(qū)動會導致一些嚴重的內(nèi)核崩潰。'aufsDockeroverlay2而且最重要的是，在許多使用最新Linux'aufs'不再被支持。審計方法執(zhí)行以下命令并驗證'aufs'不被用作存儲驅(qū)動程序：dockerinfo|grep-e"^StorageDriver:\s*aufs\s*$"結(jié)果判定上面的命令不應該返回任何東西修復措施不要刻意的使用'aufs'作為存儲驅(qū)動。例如，不要啟動Docker守護程序，如下所示：dockerd--storage-driveraufs影響aufs'是允許容器共享可執(zhí)行文件和共享庫內(nèi)存的存儲驅(qū)動程序。如果使用相同的程序或庫運行數(shù)千個容器，可以選用。默認值默認情況下，Docker在大多數(shù)平臺上使用“overlay2”和“devicemapper”作為存儲驅(qū)動程序。默認存儲驅(qū)動程序可能因操作系統(tǒng)而異。應該首選操作系統(tǒng)最佳支持的存儲驅(qū)動程序。參考文獻/engine/userguide/storagedriver/selectadriver/#supported-backing-filesystems/posts/switching-docker-from-aufs-to-devicemapper/3.http://jpetazzo.github.io/assets/2015-03-05-deep-dive-into-docker-storage-drivers.html#14./engine/userguide/storagedriver/dockerTLS描述可以讓Docker守護進程監(jiān)聽特定的IP和端口以及除默認Unix套接字以外的任何其他Unix套接字。配置TLS身份驗證以限制通過IP和端口訪問Docker守護進程。安全出發(fā)點默認情況下，Docker守護程序綁定到非聯(lián)網(wǎng)的Unix套接字，并以“root”權限運行。如果將默認的docker守護程序更改為綁定到TCP端口或任何其他Unix套接字，那么任何有權訪問該端口或套接字的人都可以完全訪問Docker守護程序，進而可以訪問主機系統(tǒng)。因此，不應該將Docker守護程序綁定到另一個IP/端口或Unix套接字。如果必須通過網(wǎng)絡套接字暴露Docker守護程序，請為守護程序和DockerSwarmAPI配置TLS身份驗證。審計方法ps-ef|grepdockerd結(jié)果判定確保存在以下參數(shù)：·'--tlsverify'·'--tlscacert'·'--tlscert'·'--tlskey'修復措施按照Docker文檔或其他參考中提到的步驟進行操作影響您需要管理和保護Docker守護程序和Docker客戶端的證書和密鑰。默認值默認情況下，未配置TLS認證參考文獻1./engine/security/https/ulimit描述根據(jù)您的環(huán)境設置默認的ulimit選項安全出發(fā)點ulimit提供對shell可用資源的控制。設置系統(tǒng)資源控制可以防止資源耗盡帶來的問題，如fork炸彈。有時候合法的用戶和進程也可能過度使用系統(tǒng)資源，導致系統(tǒng)資源耗盡。為Docker守護程序設置默認ulimit將強制執(zhí)行所有容器的ulimit。不需要單獨為每個容器設置ulimit。但默認的ulimit可能在容器運行時被覆蓋。因此，要控制系統(tǒng)資源，需要自定義默認的ulimit。審計方法ps-ef|grepdockerd結(jié)果判定確保根據(jù)需要設置'--default-ulimit'參數(shù)修復措施在守護進程模式下運行docker，并根據(jù)相應的ulimits傳遞'--default-ulimit'作為參數(shù)。例如：dockerd--default-ulimitnproc=1024：2408--default-ulimitnofile=100：200影響如果ulimits未正確設置，則可能無法實現(xiàn)所需的資源控制，甚至可能導致系統(tǒng)無法使用默認值默認情況下，不設置ulimit參考文獻1./edge/engine/reference/commandline/dockerd/#default-ulimits啟用用戶命名空間描述在Docker守護程序中啟用用戶命名空間支持，可對用戶進行重新映射。該建議對鏡像中沒有指定用戶是有幫助的。如果在容器鏡像中已經(jīng)定義了非root運行，可跳過此建議，因為該功能比較新，可能會給帶來不可預測的問題。安全出發(fā)點Docker守護程序中對Linux內(nèi)核用戶命名空間支持為Docker主機系統(tǒng)提供了額外的安全性。它允許容器具有獨特的用戶和組ID，這些用戶和組ID在主機系統(tǒng)所使用的傳統(tǒng)用戶和組范圍之外。例如，root用戶希望有容器內(nèi)的管理權限，可映射到主機系統(tǒng)上的非root的UID上。審計方法ps-p$(dockerinspect--format='{{.State.Pid}}'<CONTAINERID>)-opid,user例如：ps-p$(dockerinspect--format='{{.State.Pid}}'a4723347b65b)-opid,user結(jié)果判定上述命令將查找容器的PID，然后列出與容器進程關聯(lián)的主機用戶。如果容器進程以root身份運行，則不符合安全要求。也運行docker info以確保用戶在安全選項下：dockerinfo--format='{{.SecurityOptions}}'修復措施可參考Docke文檔了解具體的配置方式。操作可能因平臺而異例如，在RedHat上，子UID和子GID映射創(chuàng)建不會自動工作。必須手動創(chuàng)建映射。步驟如下：第1步：確保文件/etc/subuid和/etc/subgid存在touch/etc/subuid/etc/subgid第2步：使用--userns-remap標志啟動docker守護進程dockerddockerd--userns-remap=default影響注意用戶命名空間重新映射使得不少Docker功能不兼容，可查看Docker文檔和參考鏈接以獲取詳細信息。默認值默認情況下，用戶命名空間不會重新映射。參考文獻/linux/mans/man7/user_namespaces.7.html/engine/reference/commandline/dockerd/#daemon-user-namespace-options3./sites/events/files/slides/User%20Namespaces%20-%20ContainerCon%202015%20-%2016-9-final_0.pdfcgroup描述查看--cgroup-parent選項允許設置用于所有容器的默認cgroupparent。如果沒有特定用例,則該設置應保留默認值。安全出發(fā)點系統(tǒng)管理員可定義容器應運行的cgroup。若系統(tǒng)管理員沒有明確定義cgroup，容器也會在dockercgroup下運行。應該監(jiān)測和確認使用情況。通過加到與默認不同的cgroup，導致不合理地共享資源，從而可能會主機資源耗盡。審計方法ps-ef|grepdockerd結(jié)果判定確保'--cgroup-parent'參數(shù)未設置或設置為適當?shù)姆悄Jcgroup。修復措施默認設置夠用的話，可保留。如果要特別設置非默認cgroup，在啟動時將-cgroup-parent參數(shù)傳遞給docker守護程序。例如，dockerd--cgroup-parent=/foobar影響None默認值默認情況下，docker守護程序使用/dockerforfscgroupdriver和system.sliceforsystemdcgroup驅(qū)動程序。參考文獻1./engine/reference/commandline/dockerd/#default-cgroup-parent設置容器的默認空間大小描述在某些情況下，可能需要大于10G的容器空間。需要仔細選擇空間的大小。安全出發(fā)點守護進程重啟時可以增加容器空間的大小。用戶可以通過設置默認容器空間值來進行擴大，但不允許縮小。設立該值的時候需要謹慎，防止設置不當帶來空間耗盡的情況。審計方法ps-ef|grepdockerd結(jié)果判定執(zhí)行上述命令，它不應顯示任何--storage-optdm.basesize參數(shù)修復措施如無需要，不要設置--storage-optdm.basesize影響None默認值默認空間大小為10G參考文獻1./engine/reference/commandline/dockerd/#storage-driver-optionsdocker描述使用本機Docker授權插件或第三方授權機制與Docker守護程序來管理對Docker客戶端命令的訪問。安全出發(fā)點Docker默認是沒有對客戶端命令進行授權管理的功能。任何有權訪問Docker守護程序的用戶都可以運行任何Docker客戶端命令。對于使用Docker遠程API來調(diào)用守護進程的調(diào)用者也是如此。如果需要細粒度的訪問控制，可以使用授權插件并將其添加到Docker守護程序配置中。使用授權插件，Docker管理員可以配置更細粒度訪問策略來管理對Docker守護進程的訪問。Docker的第三方集成可以實現(xiàn)他們自己的授權模型，以要求Docker的本地授權插件（即Kubernetes，CloudFoundry，Openshift）之外的Docker守護進程的授權。審計方法ps-ef|grepdockerd結(jié)果判定如果使用docker本地授權，可使用--authorization-plugin參數(shù)加載授權插件。修復措施第1步：安裝/創(chuàng)建授權插件。第2步：根據(jù)需要配置授權策略。第3步：重啟docker守護進程，如下所示：dockerd--authorization-plugin=<PLUGIN_ID>影響使用授權插件可能會導致性能下降。默認值默認情況下，未設置授權插件。參考文獻1./engine/reference/commandline/dockerd/#access-authorization2./engine/extend/plugins_authorization/3./twistlock/authz配置集中和遠程日志記錄描述Docker現(xiàn)在支持各種日志驅(qū)動程序。存儲日志的最佳方式是支持集中式和遠程日志記錄。安全出發(fā)點集中和遠程日志確保所有重要的日志記錄都是安全的，以滿足容災的要求。Docker支持多種類型的日志驅(qū)動程序，可根據(jù)自身情況選取。審計方法運行dockerinfo并確保日志記錄驅(qū)動程序?qū)傩员辉O置為適當?shù)?。dockerinfo--format'{{.LoggingDriver}}'結(jié)果判定可通過如下命令查看--log-driver的設置。ps-ef|grepdockerd修復措施第1步：按照其文檔設置所需的日志驅(qū)動程序。第2步：使用該日志記錄驅(qū)動程序啟動docker守護進程。例如，dockerd--log-driver=syslog--log-optsyslog-address=tcp：//192.xxx.xxx.xxx影響None.默認值默認情況下，容器日志為json文件格式參考文獻1./engine/admin/logging/overview/禁用舊倉庫版本（v1）上的操作描述最新的Docker鏡像倉庫是v2。遺留鏡像倉庫版本（v1）上的所有操作都應受到限制安全出發(fā)點Docker鏡像倉庫v2在v1中引入了許多性能和安全性改進。它支持容器鏡像來源驗證和其他安全功能。因此，對DockerV1倉庫的操作應該受到限制審計方法ps-ef|grepdockerd結(jié)果判定上面的命令應該列出--disable-legacy-registry作為傳遞給docker守護進程的選項。修復措施啟動docker守護進程如下dockerd--disable-legacy-registry影響舊版鏡像倉庫操作將受到限制默認值默認情況下，允許舊版鏡像倉庫操作參考文獻/edge/engine/reference/commandline/dockerd/#legacy-registries/registry/spec/api/3./creating-private-docker-registry-2-0-with-token-authentication-service//2015/07/new-tool-v1-registry-docker-trusted-registry-v2-open-source//Docker/docker-registry-v2啟用實時恢復描述-live-restore參數(shù)可以支持無守護程序的容器運行。它確保Dockerdaemon在關閉或恢復時不會停止容器，并在重新啟動后重新連接到容器。安全出發(fā)點可用性作為安全一個重要的屬性。在Docker守護進程中設置'--live-restore'標志可確保當docker守護進程不可用時容器執(zhí)行不會中斷。這也意味著當更新和修復docker守護進程而不會導致容器停止工作。審計方法運行dockerinfo并確保LiveRestoreEnabled屬性設置為true。dockerinfo--format'{{.LiveRestoreEnabled}}'結(jié)果判定或者，運行以下命令并確保使用--live-restore。ps-ef|grepdockerd修復措施在守護進程模式下運行docker并傳遞'--live-restore'作為參數(shù)。例如，dockerd--live-restore影響None默認值默認情況下，--live-restore不啟用參考文獻1./engine/admin/live-restore/userland描述當容器端口需要被映射時，docker守護進程都會啟動用于端口轉(zhuǎn)發(fā)的userland-proxyDNAT安全出發(fā)點Docker引擎提供了兩種機制將主機端口轉(zhuǎn)發(fā)到容器,DNAT和userland-proxy。在大多數(shù)情況下，DNAT模式是首選，因為它提高了性能，并使用本地Linuxiptables功能而需要附加組件。如果DNAT可用，則應在啟動時禁用userland-proxy以減少安全風險。審計方法ps-ef|grepdockerd結(jié)果判定確保--userland-proxy參數(shù)設置為false。修復措施運行Docker守護進程如下：dockerd--userland-proxy=false影響某些舊版Linux內(nèi)核的系統(tǒng)可能無法支持DNAT，因此需要userland-prox服務。此外，某些網(wǎng)絡設置可能會因刪除userland-prox而受到影響。默認值默認情況下，userland-prox已啟用。參考文獻1.http://windsock.io/the-docker-proxy/2./docker/docker/issues/148563/docker/docker/issues/227414./engine/userguide/networking/default_network/binding/seccomp描述如果需要，您可以選擇在守護進程級別自定義seccomp配置文件，并覆蓋Docker的默認seccomp配置文件。安全出發(fā)點大量系統(tǒng)調(diào)用暴露于每個用戶級進程，其中許多系統(tǒng)調(diào)用在整個生命周期中都未被使用。大多數(shù)應用程序不需要所有的系統(tǒng)調(diào)用，因此可以通過減少可用的系統(tǒng)調(diào)用來增加安全性?？勺远xseccomp配置文件，而不是使用Docker的默認seccomp配置文件。如果Docker的默認配置文件夠用的話，則可以選擇忽略此建議。審計方法運行以下命令并查看“SecurityOptions”部分中列出的seccomp配置文件。如果它是默認，那就意味著，應用了Docker的默認seccomp配置文件。dockerinfo–format='{{.SecurityOptions}}'結(jié)果判定查看是否有非默認的seccomp配置文件修復措施默認情況下，Docker使用默認seccomp配置文件。如果這對當前環(huán)境有益，則不需要采取任何行動。當然，也可以選擇應用自己的seccomp配置文件，需在守護進程啟動時使用--seccomp-profile標志，或?qū)⑵浞湃胧刈o程序運行時參數(shù)文件中。dockerd--seccomp-profile</path/to/seccomp/profile>影響錯誤配置的seccomp配置文件可能會中斷的容器運行。Docker默認的策略兼容性很好，可以解決一些基本的安全問題。所以，在重寫默認值時，你應該非常小心。默認值默認情況下，Docker應用seccomp配置文件。參考文獻/engine/security/seccomp//docker/docker/pull/26276生產(chǎn)環(huán)境中避免實驗性功能描述避免生產(chǎn)環(huán)境中的實驗性功-Experimental。安全出發(fā)點docker實驗功能現(xiàn)在是一個運行時docker守護進程標志,其作為運行時標志傳遞給docker守護進程，激活實驗性功能。實驗性功能現(xiàn)在雖然比較穩(wěn)定，但是一些功能可能沒有大規(guī)模經(jīng)使用，并不能保證API的穩(wěn)定性，所以不建議在生產(chǎn)環(huán)境中使用。審計方法運行下面的命令，并確保在Server部分將Experimental屬性設置為false。dockerversion–format='{{.Server.Experimental}}'結(jié)果判定應該返回false修復措施不要將--experimental作為運行時參數(shù)傳遞給docker守護進程。影響None默認值默認情況下，docker守護進程不會激活實驗功能。參考文獻1./edge/engine/reference/commandline/dockerd/#options限制容器獲取新的權限描述默認情況下，限制容器通過suid或sgid位獲取附加權限。安全出發(fā)點一個進程可以在內(nèi)核中設置no_new_priv。它支持fork，clone。no_new_privsuidsgid得任何其他特權。這樣，很多危險的操作就降低安全風險。在守護程序級別進行設置可確保默認情況下，所有新容器不能獲取新的權限。審計方法ps-ef|grepdockerd結(jié)果判定確保--no-new-privileges參數(shù)存在且未設置為false。修復措施運行Docker守護進程如下：dockerd--no-new-privileges影響no_new_priv會阻止像SELinux這樣的LSM訪問當前進程的進程標簽。默認值默認情況下，容器不會獲得新的權限。參考文獻/moby/moby/pull/29984/moby/moby/pull/20727dockerdocker.serviceroot:root描述驗證'docker.service'文件所有權和組所有權是否正確設置為“root”。安全出發(fā)點docker.service'文件包含可能會改變Docker守護進程行為的敏感參數(shù)。因此，它應該由“root”擁有和歸屬，以保持文件的完整性。審計方法第1步：找出文件位置：systemctlshow-pFragmentPathdocker.service步驟2：如果文件不存在，則此建議不適用。如果該文件存在，請使用正確的文件路徑執(zhí)行以下命令，以驗證文件是由root擁有還是屬于群組。例如，stat-c%U:%G/lib/systemd/system/docker.service|grep-vroot:root結(jié)果判定上述命令不應該返回任何內(nèi)容。修復措施步驟1：找出文件位置：systemctlshow-pFragmentPathdocker.service步驟2：如果該文件不存在，則此建議不適用。如果文件存在，請使用正確的文件路徑執(zhí)行以下命令，將文件的所有權和組所有權設置為“root”。例如，chownroot:root/usr/lib/systemd/system/docker.service影響None.默認值該文件可能不存在于系統(tǒng)上。在這種情況下，此建議不適用。默認情況下，如果文件存在，則該文件的所有權和組所有權正確設置為“root”。參考文獻1./engine/admin/systemd/docker.service644描述驗證'docker.service'文件權限是否正確設置為'644'或更多限制。安全出發(fā)點docker.service'文件包含可能會改變Docker守護程序行為的敏感參數(shù)。因此，除“root”之外的任何其他用戶不應該保留文件的完整性。審計方法第1步：找出文件位置：systemctlshow-pFragmentPathdocker.service步驟2：如果文件不存在，則此建議不適用。如果文件存在，請使用正確的文件路徑執(zhí)行以下命令，以驗證文件權限是否設置為644或更多限制。例如，stat-c%a/etc/systemd/system/docker.service結(jié)果判定返回是否為644修復措施步驟1：找出文件位置：systemctlshow-pFragmentPathdocker.service步驟2：如果該文件不存在，則此建議不適用。如果文件存在，請使用正確的文件路徑執(zhí)行以下命令，將文件權限設置為'644'。例如，chmod644/usr/lib/systemd/system/docker.service影響None.默認值該文件可能不存在于系統(tǒng)上。在這種情況下，此建議不適用。默認情況下，如果文件存在，則文件權限正確設置為'644'。參考文獻1./articles/systemd/docker.socketroot:root描述驗證'docker.socket'文件所有權和組所有權是否正確設置為“root”。安全出發(fā)點docker.socket文件包含可能會改變Docker遠程API行為的敏感參數(shù)。因此，它應該擁有“root”權限，以保持文件的完整性。審計方法步驟1：查找文件位置：systemctlshow-pFragmentPathdocker.socket2root”擁有和歸屬的。例如，stat-c%U:%G/lib/systemd/system/docker.service|grep-vroot:root結(jié)果判定上述命令不應該返回任何內(nèi)容。修復措施1：找出文件位置：systemctlshow-pFragmentPathdocker.socket2：如果該文件不存在，則此建議不適用。如果文件存在，請使用正確的文件路徑執(zhí)行以下命令，將文件的所有權和組所有權設置為“root”。例如，chownroot：root/usr/lib/systemd/system/docker.socket影響None.默認值該文件可能不存在于系統(tǒng)上。在這種情況下，此建議不適用。默認情況下，如果文件存在，則該文件的所有權和組所有權正確設置為“root”。參考文獻/engine/reference/commandline/dockerd/#daemon-socket-option/docker/docker-ce/blob/master/components/packaging/deb/systemd/docker.socketdocker.socket644描述驗證'docker.socket'文件權限是否正確設置為'644'或更多限制。安全出發(fā)點docker.socket'文件包含可能會改變Docker遠程API行為的敏感參數(shù)。因此，它應該只能通過'root'來保持文件的完整性。審計方法1：找出文件位置：systemctlshowpFragmentPathdocker.socket2正確的文件路徑執(zhí)行以下命令，以驗證文件權限是否設置為“644”或更多限制。例如，stat–c%a/usr/lib/systemd/system/docker.socket結(jié)果判定應該返回644修復措施步驟1：找出文件位置：systemctlshow-pFragmentPathdocker.socket步驟2：如果該文件不存在，則此建議不適用。如果文件存在，請使用正確的文件路徑執(zhí)行以下命令，將文件權限設置為'644'。例如，chmod644/usr/lib/systemd/system/docker.socket影響None.默認值該文件可能不存在于系統(tǒng)上。在這種情況下，此建議不適用。默認情況下，如果文件存在，則該文件的文件權限正確設置為'644'。參考文獻1./engine/reference/commandline/dockerd/#bind-docker-to-another-hostport-or-a-unix-socket2./YungSang/fedora-atomic-packer/blob/master/oem/docker.socket3./2014/12/14/centos-7rhel-7-and-docker-containers-on-boot/設置/etc/dockerroot:root描述驗證/etc/docker目錄所有權和組所有權是否正確設置為“root”。安全出發(fā)點除了各種敏感文件之外，'/etc/docker'目錄還包含證書和密鑰。因此，它應該由“root”擁有和歸組來維護目錄的完整性。審計方法執(zhí)行以下命令以驗證該目錄是由“root”擁有和歸屬的：stat-c%U:%G/etc/docker|grep-vroot:root結(jié)果判定以上命令不應該返回任何東西修復措施chownroot：root/etc/docker這將將目錄的所有權和組所有權設置為“root”。影響None.默認值默認情況下，此目錄的所有權和組所有權正確設置為“root”。參考文獻1./engine/security/https/設置/etc/docker755描述驗證/etc/docker目錄權限是否正確設置為'755'或更多限制。安全出發(fā)點/etc/docker'目錄除了各種敏感文件外還包含證書和密鑰。因此，它只能由'root'寫入以維護目錄的完整性。審計方法執(zhí)行以下命令以驗證目錄具有“755”或更多限制的權限：stat-c%a/etc/docker|grep-vroot:root結(jié)果判定應該顯示為755修復措施chmod755/etc/docker這將把目錄的權限設置為'755'。影響None.默認值默認情況下，此目錄的權限正確設置為'755'。參考文獻1./engine/security/https/root：root描述驗證所有倉庫證書文件（通常位于/etc/docker/certs.d/<registry-name>目錄下）均由“root”擁有并歸組所有。安全出發(fā)點/etc/docker/certs.d/<registry-name>目錄包含Docker鏡像倉庫證書。這些證書文件必須由“root”和其組擁有，以維護證書的完整性審計方法執(zhí)行以下命令以驗證鏡像倉庫證書文件是由“root”擁有并由Group-owned擁有的：stat-c%U:%G/etc/docker/certs.d/*|grep-vroot:root結(jié)果判定上面的命令不應該返回任何東西。修復措施chownroot：root/etc/docker/certs.d/<registry-name>/*這將將鏡像倉庫證書文件的所有權和組所有權設置為“root”。影響None.默認值默認情況下，鏡像倉庫證書文件的所有權和組所有權正確設置為“root”。參考文獻1./registry/insecure/444描述驗證所有鏡像倉庫證書文件（通常位于/etc/docker/certs.d/<registry-name>目錄下）具有“444”或更多限制的權限。安全出發(fā)點/etc/docker/certs.d/<registry-name>目錄包含Docker鏡像倉庫證書。這些證書文件必須具有“444”權限，以維護證書的完整性。審計方法執(zhí)行以下命令以驗證鏡像倉庫證書文件是否具有“444”或更多限制的權限：stat–c%a/etc/docker/certs.d/<registry-name>/*結(jié)果判定將返回444修復措施“chmod444/etc/docker/certs.d/<registry-name>/*這會將鏡像倉庫證書文件的權限設置為'444'。影響None.默認值默認情況下，鏡像倉庫證書文件的權限可能不是“444”。默認文件權限由系統(tǒng)或用戶特定的umask值控制。參考文獻1./registry/insecure/TLSCAroot：root描述驗證TLSCA證書文件（與--tlscacert'參數(shù)一起傳遞的文件）是由“root”擁有和分組擁有的。安全出發(fā)點TLSCA證書文件應受到保護，不受任何篡改。它用于指定的CA證書驗證。因此，它必須由“root”擁有，以維護CA證書的完整性。審計方法執(zhí)行以下命令以驗證TLSCA證書文件是否由“root”和其組擁有：stat–c%U:%G<路徑到TLSCA證書文件>|grep-vroot:root結(jié)果判定上面的命令不應該返回任何東西。修復措施chownroot：root<路徑到TLSCA證書文件>這將TLSCA證書文件的所有權和組所有權設置為“root”。影響None.默認值默認情況下，TLSCA證書文件的所有權和組屬性正確設置為“root”。參考文獻/registry/insecure//engine/security/https/TLSCA444描述驗證TLSCA證書文件（與--tlscacert'參數(shù)一起傳遞的文件）具有“444”或更多限制的權限。安全出發(fā)點TLSCA證書文件應受到保護，不受任何篡改。因此，它必須具有“444”的權限以維護CA證書的完整性。審計方法執(zhí)行以下命令以驗證TLSCA證書文件是否具有“444”或更多限制的權限：stat–c%a<路徑到TLSCA證書文件>結(jié)果判定應返回444修復措施chmod444<路徑到TLSCA證書文件>這將把TLSCA文件的文件權限設置為'444'。影響None.默認值默認情況下，TLSCA證書文件的權限可能不是“444”。默認文件權限由系統(tǒng)或用戶特定的umask值控制。參考文獻/registry/insecure//engine/security/https/dockerroot：root描述驗證Docker服務器證書文件（與--tlscert'參數(shù)一起傳遞的文件）是否由“root”和其組擁有。安全出發(fā)點Docker服務器證書文件應受到保護，不受任何篡改。它用于驗證Docker服務器。因此，它必須由“root”擁有以維護證書的完整性。審計方法執(zhí)行以下命令以驗證Docker服務器證書文件是否由“root”擁有和分組擁有：stat–c%U:%G<路徑到Docker服務器證書文件>|grep-vroot:root結(jié)果判定上面的命令不應該返回任何東西。修復措施“chownroot:root<路徑到Docker服務器證書文件>這將Docker服務器證書文件的所有權和組所有權設置為“root”。影響None.默認值默認情況下，Docker服務器證書文件的所有權和組所有權正確設置為“root”。參考文獻/registry/insecure//engine/security/https/docker444描述驗證Docker服務器證書文件（與--tlscert'參數(shù)一起傳遞的文件）具有“444”或更多限制的權限。安全出發(fā)點Docker服務器證書文件應受到保護，不受任何篡改。因此，它必須具有“444”的權限以維護證書的完整性。審計方法執(zhí)行以下命令以驗證Docker服務器證書文件是否具有“444”或更多限制的權限：stat–c%a<Docker服務器證書文件的路徑>結(jié)果判定應返回444修復措施chmod444<路徑到Docker服務器證書文件>這將把Docker服務器文件的文件權限設置為'444'。影響None.默認值默認情況下，Docker服務器證書文件的權限可能不是“444”。默認文件權限由系統(tǒng)或用戶特定的umask值控制。參考文獻/registry/insecure//engine/security/https/dockerroot：root描述驗證Docker服務器證書密鑰文件（與--tlskey'參數(shù)一起傳遞的文件）是由由“root”擁有。安全出發(fā)點D