警告
本文參考 CentOS，這是處於終止服務 (EOL) 狀態的 Linux 發行版。 請據此考慮您的使用方式和規劃。 如需詳細資訊，請參閱 CentOS 生命週期結束指導。
本文詳述適用於下列實作的 Docker 主機組態設定：
- [預覽]：Linux 機器應符合 Docker 主機的 Azure 安全性基準需求
- 應該在 Azure 資訊安全中心 中補救機器上安全性設定的弱點
如需詳細資訊，請參閱瞭解 Azure 原則 的來賓設定功能和 Azure 安全性效能評定概觀（V2）。
一般安全性控制
| 名稱 （CCEID） |
詳細資料 | 補救檢查 |
|---|---|---|
| Docker 清查資訊 (0.0) |
描述：無 | 無 |
| 確定已建立容器的個別分割區 (1.01) |
描述：Docker 相依於 /var/lib/docker 作為儲存所有 Docker 相關檔案的預設目錄，包括映像。 此目錄可能會快速填滿 Docker，而且主機可能會變成無法使用。 因此，建議您建立個別的分割區（邏輯磁碟區）來儲存 Docker 檔案。 | 針對新的安裝，請為 /var/lib/docker 裝入點建立個別的數據分割。 針對先前安裝的系統，請使用邏輯磁碟區管理員 （LVM） 來建立分割區。 |
| 確定 Docker 版本是最新的 (1.03) |
描述：使用最新的 Docker 版本會保護您的主機安全 | 請遵循 Docker 檔，以升級您的版本 |
| 確定已針對 Docker 精靈設定稽核 (1.05) |
描述：除了稽核一般 Linux 文件系統和系統呼叫之外，也會稽核 Docker 精靈。 Docker 精靈會以根許可權執行。 因此，必須稽核其活動和使用方式。 | 將這一行 -w /usr/bin/docker -k docker 新增至 /etc/audit/audit.rules 檔案。 然後，執行 命令來重新啟動稽核精靈： service auditd restart |
| 確定已針對 Docker 檔案和目錄設定稽核 - /var/lib/docker (1.06) |
描述：除了稽核一般 Linux 文件系統和系統呼叫之外，請稽核所有 Docker 相關檔案和目錄。 Docker 精靈會以根許可權執行。 其行為取決於某些主要檔案和目錄。 /var/lib/docker 是這類目錄之一。 它會保存容器的所有資訊。 它必須經過稽核。 | 將這一行 -w /var/lib/docker -k docker 新增至 /etc/audit/audit.rules 檔案。 然後，執行 命令來重新啟動稽核精靈： service auditd restart |
| 確定已針對 Docker 檔案和目錄設定稽核 - /etc/docker (1.07) |
描述：除了稽核一般 Linux 文件系統和系統呼叫之外，請稽核所有 Docker 相關檔案和目錄。 Docker 精靈會以根許可權執行。 其行為取決於某些主要檔案和目錄。 /etc/docker 是這類目錄之一。 它保存各種憑證和金鑰，用於 Docker 精靈與 Docker 用戶端之間的 TLS 通訊。 它必須經過稽核。 | 將這一行 -w /etc/docker -k docker 新增至 /etc/audit/audit.rules 檔案。 然後，執行 命令來重新啟動稽核精靈： service auditd restart |
| 確定已針對 Docker 檔案和目錄設定稽核 - docker.service (1.08) |
描述：除了稽核一般 Linux 文件系統和系統呼叫之外，請稽核所有 Docker 相關檔案和目錄。 Docker 精靈會以根許可權執行。 其行為取決於某些主要檔案和目錄。 Docker.service 是這類檔案之一。 如果系統管理員已變更精靈參數，則 docker.service 檔案可能會存在。 它會保存 Docker 精靈的各種參數。 如果適用，則必須稽核它。 | 執行 下列命令來找出 『docker.service』 檔案位置： systemctl show -p FragmentPath docker.service ，並將該行 -w {docker.service file location} -k docker 新增至 /etc/audit/audit.rules 檔案，其中 {docker.service file location} 是您稍早找到的檔案路徑。 執行 命令來重新啟動稽核精靈： service auditd restart |
| 確定已針對 Docker 檔案和目錄設定稽核 - docker.socket (1.09) |
描述：除了稽核一般 Linux 文件系統和系統呼叫之外，請稽核所有 Docker 相關檔案和目錄。 Docker 精靈會以根許可權執行。 其行為取決於某些主要檔案和目錄。 Docker.socket 是一個這類檔案。 它會保存 Docker 精靈套接字的各種參數。 如果適用，則必須稽核它。 | 執行下列命令來找出 『docker.socket』 檔案位置： systemctl show -p FragmentPath docker.socket ，並將該行 -w {docker.socket file location} -k docker 新增至 /etc/audit/audit.rules 檔案，其中 {docker.socket file location} 是您稍早找到的檔案路徑。 執行 命令來重新啟動稽核精靈： service auditd restart |
| 確定已針對 Docker 檔案和目錄設定稽核 - /etc/default/docker (1.10) |
描述：除了稽核一般 Linux 文件系統和系統呼叫之外，請稽核所有 Docker 相關檔案和目錄。 Docker 精靈會以根許可權執行。 其行為取決於某些主要檔案和目錄。 /etc/default/docker 是一個這類檔案。 它會保存 Docker 精靈的各種參數。 如果適用，則必須稽核它。 | 將這一行 -w /etc/default/docker -k docker 新增至 /etc/audit/audit.rules 檔案。 然後，執行 命令來重新啟動稽核精靈： service auditd restart |
| 確定已針對 Docker 檔案和目錄設定稽核 - /etc/docker/daemon.json (1.11) |
描述：除了稽核一般 Linux 文件系統和系統呼叫之外，請稽核所有 Docker 相關檔案和目錄。 Docker 精靈會以根許可權執行。 其行為取決於某些主要檔案和目錄。 /etc/docker/daemon.json是一個這類檔案。 它會保存 Docker 精靈的各種參數。 如果適用，則必須稽核它。 | 將這一行 -w /etc/docker/daemon.json -k docker 新增至 /etc/audit/audit.rules 檔案。 然後，執行 命令來重新啟動稽核精靈： service auditd restart |
| 確定已針對 Docker 檔案和目錄設定稽核 - /usr/bin/docker-containerd (1.12) |
描述：除了稽核一般 Linux 文件系統和系統呼叫之外，請稽核所有 Docker 相關檔案和目錄。 Docker 精靈會以根許可權執行。 其行為取決於某些主要檔案和目錄。 /usr/bin/docker-containerd 是一個這類檔案。 Docker 現在依賴容器化和 runC 來繁衍容器。 如果適用，則必須稽核它。 | 將這一行 -w /usr/bin/docker-containerd -k docker 新增至 /etc/audit/audit.rules 檔案。 然後，執行 命令來重新啟動稽核精靈： service auditd restart |
| 確定已針對 Docker 檔案和目錄設定稽核 - /usr/bin/docker-runc (1.13) |
描述：除了稽核一般 Linux 文件系統和系統呼叫之外，請稽核所有 Docker 相關檔案和目錄。 Docker 精靈會以根許可權執行。 其行為取決於某些主要檔案和目錄。 /usr/bin/docker-runc 是一個這類檔案。 Docker 現在依賴容器化和 runC 來繁衍容器。 如果適用，則必須稽核它。 | 將這一行 -w /usr/bin/docker-runc -k docker 新增至 /etc/audit/audit.rules 檔案。 然後，執行 命令來重新啟動稽核精靈： service auditd restart |
| 確定預設網橋上的容器之間限制網路流量 (2.01) |
描述：預設網路網橋上會停用容器間通訊。 如果需要在相同主機上的容器之間進行任何通訊，則必須使用容器連結或自定義網路來明確定義。 | 在精靈模式中執行 docker，並以自變數的形式傳遞 --icc=false ，或在 daemon.json 檔案中將 'icc' 設定設為 false。 或者，您可以遵循 Docker 檔並建立自定義網路，並只加入需要與該自定義網路通訊的容器。 --icc參數僅適用於預設 Docker 網橋，如果使用自定義網路，則應該改用區隔網路的方法。 |
| 確定記錄層級已設定為 「資訊」。 (2.02) |
描述：設定適當的記錄層級，將 Docker 精靈設定為記錄您想要稍後檢閱的事件。 和更新版本的基底記錄層級 info 會擷取偵錯記錄以外的所有記錄。 除非必要，否則您不應該在記錄層級執行 debug Docker 精靈。 |
執行 Docker 精靈，如下所示： dockerd --log-level info |
| 確定允許 Docker 對 iptable 進行變更 (2.03) |
描述：如果您選擇這麼做，Docker 永遠不會對您的系統 iptables 規則進行變更。 Docker 伺服器會根據您針對容器選擇網路選項的方式，自動對iptable進行所需的變更，如果允許的話。 建議讓 Docker 伺服器自動進行變更 iptables，以避免網路設定錯誤，這可能會妨礙容器與外部世界的通訊。 此外，每次您選擇執行容器或修改網路選項時，都會省下更新 iptable的麻煩。 |
請勿使用 --iptables=false 參數執行 Docker 精靈。 例如，請勿啟動 Docker 精靈，如下所示： dockerd --iptables=false |
| 確定未使用不安全的登錄 (2.04) |
描述：您不應該在生產環境中使用任何不安全的登錄。 不安全的登錄可能會遭到竄改，進而危害您的生產系統。 | 從 dockerd start 命令移除 --insecure-registry 旗標 |
| Docker 精靈不應該使用 'aufs' 記憶體驅動程式 (2.05) |
描述：『aufs』 記憶體驅動程式是最古老的記憶體驅動程式。 它是以不太可能合併到主要 Linux 核心的 Linux 核心修補程式集為基礎。 aufs 驅動程式也已知會導致一些嚴重的核心損毀。 aufs 只是有來自 Docker 的舊版支援。 最重要的是，aufs 不是許多使用最新 Linux 核心的 Linux 發行版中支援的驅動程式 | 'aufs' 記憶體驅動程序應該由不同的記憶體驅動程式取代，我們建議使用 'overlay2' |
| 確定已設定 Docker 精靈的 TLS 驗證 (2.06) |
描述：根據預設，Docker 精靈會系結至非網路 Unix 套接字，並使用 root 許可權執行。 如果您將預設 Docker 精靈系結變更為 TCP 連接埠或任何其他 Unix 套接字，則任何具有該埠或套接字存取權的人都可以完整存取 Docker 精靈，並接著存取主機系統。 因此，您不應該將 Docker 精靈系結至另一個 IP/埠或 Unix 套接字。 如果您必須透過網路套接字公開 Docker 精靈，請設定精靈和 Docker Swarm API 的 TLS 驗證（如果使用）。 這會將透過網路連線到 Docker 精靈的連線限制為少數可透過 TLS 進行驗證的用戶端。 |
請遵循 Docker 檔或其他參考中所述的步驟。 |
| 請確定已適當地設定預設ulimit (2.07) |
描述：如果未正確設定 ulimits，則可能無法達到所需的資源控制，甚至可能讓系統無法使用。 | 在精靈模式中執行 docker，並在您的環境中適當地傳遞 --default-ulimit 作為自變數與個別的 ulimit。 或者，您也可以在環境中適當地使用 --ulimit 具有個別 ulimits 的自變數，個別設定每個容器的特定資源限制。 |
| 啟用使用者命名空間支援 (2.08) |
描述：Docker 精靈中的 Linux 核心使用者命名空間支援可為 Docker 主機系統提供額外的安全性。 它可讓容器具有唯一範圍的使用者和群組標識碼，這些標識碼不在主機系統所使用的傳統使用者和群組範圍之外。 例如，根使用者在容器內會有預期的系統管理許可權，但可以有效地對應到主機系統上的不具特殊許可權 UID。 | 如需根據需求可設定的各種方式，請參閱 Docker 檔。 您的步驟可能也會根據平臺而有所不同 - 例如，Red Hat、子 UID 和子 GID 對應建立不會自動運作。 您可能必須建立自己的對應。 不過，高階步驟如下： 步驟 1： 確定檔案 /etc/subuid 和 /etc/subgid 存在。touch /etc/subuid /etc/subgid步驟 2： 使用 --userns-remap 旗標啟動 Docker 精靈 dockerd --userns-remap=default |
| 請確定基底裝置大小在需要之前不會變更 (2.10) |
描述：增加基底裝置大小可讓所有未來的映像和容器成為新的基底裝置大小，這可能會導致拒絕服務，因為文件系統已過度配置或已滿。 | 從 dockerd start 命令移除 --storage-opt dm.basesize 旗標，直到您需要它為止 |
| 確定已啟用 Docker 用戶端命令的授權 (2.11) |
描述：Docker 現用的授權模型是全部或全無的。 任何有權存取 Docker 精靈的使用者都可以執行任何 Docker 用戶端命令。 使用 Docker 的遠端 API 來連絡精靈的呼叫端也是如此。 如果您需要更高的訪問控制，您可以建立授權外掛程式，並將其新增至 Docker 精靈組態。 使用授權外掛程式，Docker 系統管理員可以設定細微的存取原則來管理 Docker 精靈的存取權。 Docker 的第三方整合可以實作自己的授權模型，以要求在 Docker 原生授權外掛程式之外使用 Docker 精靈進行授權（亦即 Kubernetes、Cloud Foundry、OpenShift）。 | 步驟 1： 安裝/建立授權外掛程式。 步驟 2： 視需要設定授權原則。 步驟 3： 啟動 Docker 精靈，如下所示： dockerd --authorization-plugin= |
| 確定已設定集中式和遠程記錄 (2.12) |
描述：集中式和遠端記錄可確保儘管發生重大事件，但所有重要的記錄檔記錄都是安全的。 Docker 現在支援各種這類記錄驅動程式。 使用最符合您環境的環境。 | 步驟 1： 依照其文件設定所需的記錄驅動程式。 步驟 2： 使用該記錄驅動程序啟動 Docker 精靈。 例如，dockerd --log-driver=syslog --log-opt syslog-address=tcp://192.xxx.xxx.xxx |
| 確定已啟用即時還原 (2.14) |
描述：其中一個重要的安全性三重奏是可用性。 Docker 精靈中的設定 --live-restore 旗標可確保當 Docker 精靈無法使用時，容器執行不會中斷。 這也表示現在更容易更新和修補 Docker 精靈，而不需要執行停機時間。 |
在精靈模式中執行 Docker，並以自變數的形式傳遞 --live-restore 。 例如dockerd --live-restore |
| 確定 Userland Proxy 已停用 (2.15) |
描述：Docker 引擎提供兩種機制，用於將埠從主機轉送至容器、發釘 NAT 和用戶蘭 Proxy。 在大部分情況下，建議使用髮夾 NAT 模式，因為它可改善效能，並使用原生 Linux iptables 功能，而不是額外的元件。 有毛釘 NAT 可供使用時，應該在啟動時停用 userland Proxy，以減少安裝的攻擊面。 | 執行 Docker 精靈，如下所示： dockerd --userland-proxy=false |
| 確保生產環境中避免實驗性功能 (2.17) |
描述：實驗性現在是運行時間 Docker 精靈旗標，而不是個別的組建。 以 --experimental 運行時間旗標的形式傳遞至 Docker 精靈，會啟動實驗性功能。 實驗性現在被視為穩定版本，但有幾個功能可能尚未測試及保證 API 穩定性。 |
請勿將 作為運行時間參數傳遞 --experimental 至 Docker 精靈。 |
| 請確定容器受限於取得新的許可權。 (2.18) |
描述：進程可以設定 no_new_priv 核心中的位。 它會跨分叉、複製和execve保存。 位 no_new_priv 可確保進程或其子進程不會透過suid或 sgid 位取得任何其他許可權。 如此一來，許多危險的作業就變得不那麼危險了，因為不可能顛覆特殊許可權的二進位檔。 在精靈層級設定此選項可確保預設會限制所有新的容器，而無法取得新的許可權。 |
執行 Docker 精靈，如下所示： dockerd --no-new-privileges |
| 確定 docker.service 檔案擁有權設定為 root：root。 (3.01) |
描述： docker.service 檔案包含可能會改變 Docker 精靈行為的敏感性參數。 因此，它應該由 擁有和群組擁有 root ，以維護檔案的完整性。 |
步驟 1： 瞭解檔案位置： systemctl show -p FragmentPath docker.service 步驟 2： 如果檔案不存在，則不適用此建議。 如果檔案存在，請使用正確的檔案路徑執行下列命令，將檔案的擁有權和群組擁有權設定為 root。 例如，chown root:root /usr/lib/systemd/system/docker.service |
| 確定 docker .service 檔案許可權設定為 644 或更嚴格 (3.02) |
描述： docker.service 檔案包含可能會改變 Docker 精靈行為的敏感性參數。 因此，除了維護檔案的完整性之外 root ，它不應該由任何其他使用者寫入。 |
步驟 1： 瞭解檔案位置： systemctl show -p FragmentPath docker.service 步驟 2： 如果檔案不存在，則不適用此建議。 如果檔案存在，請使用正確的檔案路徑執行下列命令，將檔案權限設定為 644。 例如，chmod 644 /usr/lib/systemd/system/docker.service |
| 確定 docker.socket 檔案擁有權設定為 root：root。 (3.03) |
描述： docker.socket 檔案包含可能會改變 Docker 遠端 API 行為的敏感性參數。 因此，它應該由 擁有和群組擁有 root ，以維護檔案的完整性。 |
步驟 1： 瞭解檔案位置： systemctl show -p FragmentPath docker.socket 步驟 2： 如果檔案不存在，則不適用此建議。 如果檔案存在，請使用正確的檔案路徑執行下列命令，將檔案的擁有權和群組擁有權設定為 root。 例如，chown root:root /usr/lib/systemd/system/docker.socket |
確定 docker.socket 檔案許可權設定為 644 或更嚴格(3.04) |
描述： docker.socket 檔案包含可能會改變 Docker 精靈行為的敏感性參數。 因此，除了維護檔案的完整性之外 root ，它不應該由任何其他使用者寫入。 |
步驟 1： 瞭解檔案位置： systemctl show -p FragmentPath docker.socket 步驟 2： 如果檔案不存在，則不適用此建議。 如果檔案存在，請使用正確的檔案路徑執行下列命令，將檔案權限設定為 644。 例如，chmod 644 /usr/lib/systemd/system/docker.service |
確定 /etc/docker 目錄擁有權設定為 root:root。(3.05) |
描述：/etc/docker 目錄除了各種敏感性檔案之外，還包含憑證和密鑰。 因此，它應該由 擁有和群組擁有 root ，以維護目錄的完整性。 |
chown root:root /etc/docker 這會將目錄的擁有權和群組擁有權設定為 root。 |
確定 /etc/docker 目錄許可權設定為 755 或更嚴格(3.06) |
描述：/etc/docker 目錄除了各種敏感性檔案之外，還包含憑證和密鑰。 因此，它應該只能由 寫入 root ，以維護目錄的完整性。 |
chmod 755 /etc/docker 這會將目錄的權限設定為 755。 |
| 確定登錄憑證檔案擁有權設定為 root：root (3.07) |
描述：/etc/docker/certs.d/ 目錄包含 Docker 登錄憑證。 這些憑證檔案必須由 擁有和群組擁有 root ，才能維護憑證的完整性。 |
chown root:root /etc/docker/certs.d//* 這會將登入憑證檔案的擁有權和群組擁有權設定為 root。 |
確定登錄憑證檔案許可權已設定為 444 或更嚴格(3.08) |
描述：/etc/docker/certs.d/ 目錄包含 Docker 登錄憑證。 這些憑證檔案必須具有 444 的許可權，才能維護憑證的完整性。 |
chmod 444 /etc/docker/certs.d//* 這會將登入憑證檔案的權限設定為 444。 |
| 確定 TLS CA 憑證檔案擁有權設定為 root：root (3.09) |
描述：TLS CA 憑證檔案應受到保護，以免遭到竄改。 它用來根據指定的 CA 憑證來驗證 Docker 伺服器。 因此，它必須擁有和群組擁有 root ，才能維護 CA 憑證的完整性。 |
chown root:root 這會將 TLS CA 憑證檔案的擁有權和群組擁有權設定為 root。 |
確定 TLS CA 憑證檔案許可權設定為 444 或更嚴格(3.10) |
描述：TLS CA 憑證檔案應受到保護，以免遭到竄改。 它用來根據指定的 CA 憑證來驗證 Docker 伺服器。 因此，它必須具有 444 的許可權，才能維護 CA 憑證的完整性。 |
chmod 444 這會將 TLS CA 檔案的檔案權限設定為 444。 |
| 確定 Docker 伺服器證書檔案擁有權設定為 root：root (3.11) |
描述：Docker 伺服器證書檔案應受到保護，以免遭到竄改。 它用來根據指定的伺服器證書來驗證 Docker 伺服器。 因此，它必須擁有和群組擁有 root ，才能維護憑證的完整性。 |
chown root:root 這會將 Docker 伺服器憑證檔案的擁有權和群組擁有權設定為 root。 |
確定 Docker 伺服器憑證檔案許可權已設定為 444 或更嚴格(3.12) |
描述：Docker 伺服器證書檔案應受到保護，以免遭到竄改。 它用來根據指定的伺服器證書來驗證 Docker 伺服器。 因此，它必須具有 維護憑證完整性的許可權 444 。 |
chmod 444 這會將 Docker 伺服器檔案的檔案權限設定為 444。 |
| 確定 Docker 伺服器證書金鑰檔案擁有權設定為 root：root (3.13) |
描述：Docker 伺服器證書密鑰檔案應受到保護，以免任何竄改或不需要的讀取。 它會保存 Docker 伺服器證書的私鑰。 因此，它必須擁有和群組擁有 root ，才能維護 Docker 伺服器證書的完整性。 |
chown root:root 這會將 Docker 伺服器憑證金鑰檔案的擁有權和群組擁有權設定為 root。 |
| 確定 Docker 伺服器憑證金鑰檔案權限設定為 400 (3.14) |
描述：Docker 伺服器證書密鑰檔案應受到保護，以免任何竄改或不需要的讀取。 它會保存 Docker 伺服器證書的私鑰。 因此，它必須具有 400 的許可權，才能維護 Docker 伺服器證書的完整性。 |
chmod 400 這會將 Docker 伺服器憑證金鑰檔案權限設定為 400。 |
| 確定 Docker 套接字檔案擁有權設定為 root：docker (3.15) |
描述：Docker 精靈會以 的形式執行 root。 因此，預設 Unix 套接字必須由 擁有 root。 如果任何其他使用者或進程擁有此套接字，則該非特殊許可權用戶或進程可能會與 Docker 精靈互動。 此外，這類非特殊許可權的用戶或進程可能會與容器互動。 這既不是安全的行為，也不是想要的行為。 此外，Docker 安裝程式會建立名為 docker的 Unix 群組。 您可以將使用者新增至此群組，然後這些使用者將能夠讀取和寫入預設的 Docker Unix 套接字。 群組的成員資格 docker 由系統管理員嚴格控制。 如果任何其他群組擁有此套接字，則該群組的成員可能會與 Docker 精靈互動。 此外，這類群組可能不會像群組 docker 一樣嚴格控制。 這既不是安全的行為，也不是想要的行為。 因此，預設的 Docker Unix 套接字檔案必須由 root 和 群組擁有 docker ，才能維護套接字檔案的完整性。 |
chown root:docker /var/run/docker.sock 這會將擁有權設定為 ， root 並將預設 Docker 套接字檔案的群組擁有權設定為 docker 。 |
確定 Docker 套接字檔案許可權已設定為 660 或更嚴格(3.16) |
描述：只 root 允許群組的成員 docker 讀取和寫入預設 Docker Unix 套接字。 因此，Docket 套接字檔案必須具有 或更嚴格的許可權 660 。 |
chmod 660 /var/run/docker.sock 這會將 Docker 套接字檔案的檔案權限設定為 660。 |
| 確定daemon.json檔案擁有權設定為 root：root (3.17) |
描述： daemon.json 檔案包含可能會改變 Docker 精靈行為的敏感性參數。 因此，它應該由 擁有和群組擁有 root ，以維護檔案的完整性。 |
chown root:root /etc/docker/daemon.json 這會將檔案的擁有權和群組擁有權設定為 root。 |
| 確定daemon.json檔案許可權設定為 644 或更嚴格 (3.18) |
描述： daemon.json 檔案包含可能會改變 Docker 精靈行為的敏感性參數。 因此，它應該只能藉由 root 維護檔案的完整性來寫入。 |
chmod 644 /etc/docker/daemon.json 這會將此檔案的檔案權限設定為 644。 |
| 確定 /etc/default/docker 檔案擁有權設定為 root：root (3.19) |
描述： /etc/default/docker 檔案包含可能會改變 Docker 精靈行為的敏感性參數。 因此，它應該由 擁有和群組擁有 root ，以維護檔案的完整性。 |
chown root:root /etc/default/docker 這會將檔案的擁有權和群組擁有權設定為 root。 |
| 確定 /etc/default/docker 檔案許可權設定為 644 或更嚴格 (3.20) |
描述：/etc/default/docker 檔案包含可能改變 Docker 精靈行為的敏感性參數。 因此，它應該只能藉由 root 維護檔案的完整性來寫入。 |
chmod 644 /etc/default/docker 這會將此檔案的檔案權限設定為 644。 |
| 確定已建立容器的使用者 (4.01) |
描述：最好盡可能以非根使用者身分執行容器。 雖然使用者命名空間對應現已可供使用，但如果已在容器映像中定義使用者，則容器預設會以該使用者身分執行，而且不需要特定的使用者命名空間重新對應。 | 請確定容器映像的 Dockerfile 包含： USER {username or ID} 其中使用者名稱或標識碼是指可在容器基底映射中找到的使用者。 如果沒有在容器基底映射中建立的特定使用者，請在USER指示之前新增useradd命令以新增特定使用者。 |
| 確定 HEALTHCHECK 指示已新增至容器映像 (4.06) |
描述：其中一個重要的安全性三重奏是可用性。 將指令新增 HEALTHCHECK 至容器映像可確保 Docker 引擎會定期針對該指令檢查執行中的容器實例，以確保實例仍在運作。 根據回報的健康情況狀態，Docker 引擎接著可以結束非運作的容器，並具現化新的容器。 |
請遵循 Docker 檔，並依照 HEALTHCHECK 指示重建容器映像。 |
| 請確定已適當地啟用 SELinux 或 AppArmor (5.01-2) |
描述：AppArmor 藉由強制執行也稱為 AppArmor 配置檔的安全策略，保護 Linux OS 和應用程式免於各種威脅。 您可以為容器建立自己的 AppArmor 配置檔，或使用 Docker 的預設 AppArmor 配置檔。 這會在配置檔中所定義的容器上強制執行安全策略。 SELinux 提供強制 存取控制 （MAC） 系統，可大幅增強預設的 Discretionary 存取控制 （DAC） 模型。 因此，您可以在 Linux 主機上啟用 SELinux，以增加額外的安全性層，如果適用的話。 | 為散發版本啟用相關的強制 存取控制 外掛程式之後，請針對 docker run --interactive --tty --security-opt="apparmor:PROFILENAME" centos /bin/bash AppArmor 或 docker run --interactive --tty --security-opt label=level:TopSecret centos /bin/bash SELinux 執行 docker 精靈。 |
| 確定容器內限制Linux核心功能 (5.03) |
描述：Docker 支援新增和移除功能，允許使用非預設配置檔。 這可讓 Docker 透過移除功能更安全，或透過新增功能較不安全。 因此，建議您移除容器程序明確需要的功能以外的所有功能。 例如，容器進程通常不需要下列功能： NET_ADMIN SYS_ADMIN SYS_MODULE |
執行下列命令以新增所需的功能：$> docker run --cap-add={"Capability 1","Capability 2"}例如，docker run --interactive --tty --cap-add={"NET_ADMIN","SYS_ADMIN"} centos:latest /bin/bash執行下列命令以卸除不必要的功能：例如，docker run --interactive --tty --cap-drop={"SETUID","SETGID"} centos:latest /bin/bash您也可以選擇卸除所有功能，並只新增所需的功能：$> docker run --cap-drop={"Capability 1","Capability 2"}$> docker run --cap-drop=all --cap-add={“Capability 1”，“Capability 2”} 例如，docker run --interactive --tty --cap-drop=all --cap-add={"NET_ADMIN","SYS_ADMIN"} centos:latest /bin/bash |
| 確定未使用具特殊許可權的容器 (5.04) |
描述：旗 --privileged 標會提供容器的所有功能，也會解除裝置 cgroup 控制器強制執行的所有限制。 換句話說，容器幾乎可以執行主機所能執行的一切。 此旗標存在以允許特殊使用案例，例如在 Docker 內執行 Docker。 |
請勿使用 --privileged 旗標執行容器。 例如，請勿啟動容器，如下所示： docker run --interactive --tty --privileged centos /bin/bash |
| 確定未在容器上掛接敏感性主機系統目錄 (5.05) |
描述：如果敏感性目錄以讀寫模式掛接，就有可能對這些敏感性目錄內的檔案進行變更。 這些變更可能會降低安全性影響，或可能使 Docker 主機處於遭入侵狀態的不必要變更。 | 請勿在容器上掛接主機敏感性目錄，特別是在讀寫模式中。 |
| 確定主機的網路命名空間未共用 (5.09) |
描述：這是潛在的危險。 它可讓容器進程像任何其他 root 進程一樣開啟低編號的埠。 它也允許容器存取 Docker 主機上的 D 總線之類的網路服務。 因此，容器進程可能會執行非預期的事情，例如關閉 Docker 主機。 您不應該使用此選項。 |
啟動容器時不要傳遞 --net=host 選項。 |
| 確定容器的記憶體使用量有限 (5.10) |
描述：根據預設，容器可以使用主機上的所有記憶體。 您可以使用記憶體限制機制來防止一個容器耗用所有主機資源的拒絕服務，讓相同主機上的其他容器無法執行其預期功能。 記憶體沒有限制可能會導致一個容器很容易使整個系統不穩定，因而無法使用的問題。 | 只執行具有所需記憶體的容器。 一律使用 --memory 自變數執行容器。 例如，您可以執行容器，如下所示： docker run --interactive --tty --memory 256m centos /bin/bash 在上述範例中，容器會以 256 MB 的記憶體限制啟動。 注意：請注意，如果記憶體限制已就緒，下列命令的輸出會傳回科學表示法中的值。 docker inspect --format='{{.Config.Memory}}' 7c5a2d4c7fe0 例如，如果上述容器實例的記憶體限制設定為 256 MB ，則上述命令的輸出會是 2.68435456e+08 和 NOT 256m。 您應該使用科學計算機或程式設計方法來轉換此值。 |
| 確定容器的根文件系統已掛接為唯讀 (5.12) |
描述：啟用此選項會強制容器在運行時間明確定義其數據寫入策略，以保存或不要保存其數據。 這也會減少安全性攻擊媒介，因為容器實例的文件系統無法遭到竄改或寫入，除非其文件系統資料夾和目錄具有明確的讀寫許可權。 | --read-only在容器的運行時間新增旗標，以強制將容器的根文件系統掛接為唯讀。docker run --read-only--read-only系統管理員應該使用在容器運行時間啟用 選項，強制容器的可執行程式只在容器運行時間期間將容器數據寫入明確儲存位置。 容器運行時間期間明確儲存位置的範例包括，但不限於：1。 --tmpfs使用 選項來掛接非持續性數據寫入的暫存文件系統。 docker run --interactive --tty --read-only --tmpfs "/run" --tmpfs "/tmp" centos /bin/bash 2. 在容器的運行時間啟用 Docker rw 掛接，以直接在 Docker 主機文件系統上保存容器數據。 docker run --interactive --tty --read-only -v /opt/app/data:/run/app/data:rw centos /bin/bash 3. 針對 Docker 數據磁碟區利用 Docker 共用記憶體磁碟區外掛程式來保存容器數據。 docker volume create -d convoy --opt o=size=20GB my-named-volume``````docker run --interactive --tty --read-only -v my-named-volume:/run/app/data centos /bin/bash 4. 在容器運行時間期間，在 Docker 外部傳輸容器數據，以保存容器數據。 範例包括裝載的資料庫、網路檔案共用和 API。 |
| 確定連入容器流量系結至特定主機介面 (5.13) |
描述：如果您的主計算機上有多個網路介面，容器可以接受任何網路介面上公開埠上的連線。 這可能不是想要的，而且可能不受保護。 特定介面經常在外部公開，且入侵檢測、入侵預防、防火牆、負載平衡等服務會在這些介面上執行，以篩選傳入的公用流量。 因此，您不應該在任何介面上接受連入連線。 您應該只允許來自特定外部介面的連入連線。 | 將容器埠系結至所需主機埠上的特定主機介面。 例如，docker run --detach --publish 10.2.3.4:49153:80 nginx在上述範例中，容器埠會系結至上的49153主機埠80，且只接受來自10.2.3.4外部介面的連入連線。 |
| 確定 [失敗時] 容器重新啟動原則設定為 『5』 或更低 (5.14) |
描述：如果您無限期地嘗試啟動容器，可能會導致主機上的阻斷服務。 您可以輕易地執行分散式阻斷服務攻擊，特別是如果您在相同主機上有許多容器。 此外，忽略容器的結束狀態，並 always 嘗試重新啟動容器會導致對容器終止的根本原因進行非調查。 如果容器終止，您應該調查其背後的原因，而不只是嘗試無限期地重新啟動它。 因此，建議使用 on-failure 重新啟動原則，並將它限製為重新啟動嘗試次數 5 上限。 |
如果容器需要自行重新啟動，例如，您可以如下所示啟動容器： docker run --detach --restart=on-failure:5 nginx |
| 確定主機的進程命名空間未共用 (5.15) |
描述：PID 命名空間提供程式分隔。 PID 命名空間會移除系統進程的檢視，並允許重複使用進程識別碼，包括 PID 1。 如果主機的 PID 命名空間與容器共用，基本上允許容器內的進程查看主機系統上的所有進程。 這會中斷主機與容器之間的進程等級隔離的優點。 擁有容器存取權的人員最終可以知道在主機系統上執行的所有進程，甚至可以從容器內終止主機系統進程。 這可能會是災難性的。 因此，請勿與容器共用主機的進程命名空間。 |
請勿使用 --pid=host 自變數啟動容器。 例如，請勿啟動容器，如下所示： docker run --interactive --tty --pid=host centos /bin/bash |
| 確定主機的 IPC 命名空間未共用 (5.16) |
描述：IPC 命名空間提供主機與容器之間的 IPC 區隔。 如果主機的 IPC 命名空間與容器共用，它基本上允許容器內的進程查看主機系統上的所有 IPC。 這會中斷主機與容器之間 IPC 層級隔離的優點。 有權存取容器的人員最終可以操作主機 IPC。 這可能會是災難性的。 因此，請勿與容器共用主機的 IPC 命名空間。 | 請勿使用 --ipc=host 自變數啟動容器。 例如，請勿啟動容器，如下所示： docker run --interactive --tty --ipc=host centos /bin/bas |
| 確定主機裝置不會直接公開至容器 (5.17) |
描述：選項 --device 會將主機裝置公開至容器，因此，容器可以直接存取這類主機裝置。 您不需要容器以 privileged 模式執行，即可存取及操作主機裝置。 根據預設，容器將能夠讀取、寫入和 mknod 這些裝置。 此外，容器也可以從主機移除封鎖裝置。 因此，請勿將主機裝置直接公開至容器。 如果完全想要將主機裝置公開至容器，請適當地使用共享許可權：- r - 只讀 - w - 可寫入 - m - 允許 mknod |
請勿將主機裝置直接公開至容器。 如果完全需要向容器公開主機裝置，請使用正確的許可權集合：例如，不要啟動容器，如下所示：例如，使用正確的許可權共用主機裝置： docker run --interactive --tty --device=/dev/tty0:/dev/tty0:rwm --device=/dev/temp_sda:/dev/temp_sda:rwm centos bashdocker run --interactive --tty --device=/dev/tty0:/dev/tty0:rw --device=/dev/temp_sda:/dev/temp_sda:r centos bash |
| 確定掛接傳播模式未設定為共用 (5.19) |
描述：共用掛接會在所有掛接上複寫，而且在任何裝入點所做的變更都會傳播到所有掛接。 在共用模式中掛接磁碟區並不會限制任何其他容器掛接並變更該磁碟區。 如果掛接的磁碟區對變更有敏感性，這可能是災難性的。 在需要之前，請勿將掛接傳播模式設定為共用。 | 請勿在共用模式傳播中掛接磁碟區。 例如，請勿啟動容器，如下所示： docker run --volume=/hostPath:/containerPath:shared |
| 確定主機的 UTS 命名空間未共用 (5.20) |
描述：與主機共用UTS命名空間會提供容器的完整許可權，以變更主機的主機名。 這是不安全的，不應允許。 | 請勿使用 --uts=host 自變數啟動容器。 例如，請勿啟動容器，如下所示： docker run --rm --interactive --tty --uts=host rhel7.2 |
| 確定已確認 cgroup 使用量 (5.24) |
描述：系統管理員通常會定義應該執行容器的 cgroup。 即使系統管理員未明確定義 cgroup，容器預設仍會在 cgroup 下 docker 執行。 在運行時間，可以附加至預期的 cgroup 以外的其他群組。 此使用方式應受到監視並確認。 藉由附加至與預期不同的 cgroup，可能會將多餘的許可權和資源授與容器，因此可能會證明不安全。 |
除非需要，否則請勿在 命令中使用 --cgroup-parent docker run 選項。 |
| 確定容器受到限制而無法取得其他許可權 (5.25) |
描述：進程可以設定 no_new_priv 核心中的位。 它會跨分叉、複製和execve保存。 位 no_new_priv 可確保進程或其子進程不會透過suid或 sgid 位取得任何其他許可權。 如此一來，許多危險的作業就變得不那麼危險了，因為不可能顛覆特殊許可權的二進位檔。 |
例如，您應該如下所示啟動容器： docker run --rm -it --security-opt=no-new-privileges ubuntu bash |
| 確定在運行時間檢查容器健康情況 (5.26) |
描述：其中一個重要的安全性三重奏是可用性。 如果您使用的容器映像沒有預先定義的 HEALTHCHECK 指示，請使用 --health-cmd 參數來檢查運行時間的容器健康情況。 根據回報的健康狀態，您可以採取必要的動作。 |
使用 --health-cmd 和其他參數執行容器。 例如，docker run -d --health-cmd='stat /etc/passwd || exit 1' nginx |
| 確定已使用 PID cgroup 限制 (5.28) |
描述：攻擊者可以使用容器內的單一命令來啟動分支炸彈。 這個分叉炸彈可能會毀掉整個系統，而且需要重新啟動主機，才能讓系統再次運作。 PID cgroup --pids-limit 會藉由限制在特定時間在容器內可能發生的分叉數目，來防止這類攻擊。 |
以適當的值啟動容器時，請使用 --pids-limit 旗標。 例如， docker run -it --pids-limit 100 在上述範例中，在任何指定時間允許執行的進程數目會設定為 100。 達到 100 個並行執行進程的限制之後，docker 會限制任何新的進程建立。 |
| 確定未使用 Docker 的預設網橋 docker0 (5.29) |
描述：Docker 會將在網橋模式中建立的虛擬介面連線到稱為 docker0的通用網橋。 此預設網路模型容易受到ARP詐騙和MAC洪水攻擊的影響，因為未套用任何篩選。 |
請遵循 Docker 檔並設定使用者定義的網路。 執行定義網路中的所有容器。 |
| 確定主機的使用者命名空間未共用 (5.30) |
描述：使用者命名空間可確保容器內的根進程會對應至容器外部的非根進程。 因此，與容器共用主機的使用者命名空間並不會隔離主機上的使用者與容器上的使用者。 | 請勿在主機和容器之間共用使用者命名空間。 例如，請勿執行容器，如下所示： docker run --rm -it --userns=host ubuntu bash |
| 確定 Docker 套接字未掛接在任何容器內 (5.31) |
描述：如果 Docker 套接字掛接在容器內，則允許容器內執行的進程執行 Docker 命令，以有效地完全控制主機。 | 確定沒有容器掛接 docker.sock 為磁碟區。 |
| 確定群集服務系結至特定的主機介面 (7.03) |
描述：當群集初始化時，旗標的 --listen-addr 預設值表示 0.0.0.0:2377 群集服務會在主機上的所有介面上接聽。 如果主機有多個網路介面，這可能是不想要的，因為它可能會向未參與群集作業的網路公開 Docker 群集服務。 藉由將特定IP位址傳遞至 --listen-addr，可以指定特定網路介面來限制此曝光。 |
補救此作業需要重新初始化群集，以指定 參數的特定介面 --listen-addr 。 |
| 確保容器之間交換的數據會在重疊網路上的不同節點上加密 (7.04) |
描述：根據預設，重迭網路上不同節點上的容器之間交換的數據不會加密。 這可能會公開容器節點之間的流量。 | 建立具有旗標的 --opt encrypted 重迭網路。 |
| 確定群集管理員以自動鎖定模式執行 (7.06) |
描述：當 Docker 重新啟動時，用來加密群集節點之間通訊的 TLS 金鑰，以及用來加密和解密磁碟上之 Raft 記錄的金鑰，都會載入到每個管理員節點的記憶體中。 您應該保護相互 TLS 加密金鑰，以及用來加密和解密待用的 Raft 記錄的金鑰。 您可以使用 旗標初始化群集 --autolock 來啟用此保護。 啟用時 --autolock ，當 Docker 重新啟動時，您必須先使用 Docker 初始化群集時所產生的金鑰加密金鑰來解除鎖定群集。 |
如果您要初始化群集，請使用下列命令。 docker swarm init --autolock 如果您想要在現有的群集管理員節點上設定 --autolock ，請使用下列命令。docker swarm update --autolock |
注意
特定 Azure 原則 客體組態設定的可用性可能會因 Azure Government 和其他國家雲端而異。
下一步
關於 Azure 原則和來賓設定的其他文章：
- [瞭解 Azure 原則 的來賓設定功能]瞭解 Azure Polic 的客體設定功能。/../machine-configuration/overview.md）。
- 法規合規性概觀。
- 在 Azure 原則範例檢閱其他範例。
- 檢閱了解原則效果。
- 了解如何補救不符合規範的資源。