Docker 安全加固方案｜附配置文件

Docker 作为当前最常用的容器化技术之一，已经广泛应用于开发、测试、持续集成、微服务部署以及生产环境交付中。它通过镜像、容器、仓库、网络和存储等机制，大幅提升了应用交付效率。然而，Docker 并不是天然安全的运行环境。如果镜像来源不可信、容器权限过高、宿主机配置不当，攻击者就可能通过容器逃逸、敏感文件挂载、恶意镜像、网络横向移动等方式影响业务系统，甚至控制宿主机。

因此，Docker 安全加固不能只关注某一个配置项，而应从宿主机、Docker Daemon、镜像、容器运行时、网络、存储、日志审计、权限控制和持续运维等多个层面构建完整防护体系。本文将给出一套较为系统的 Docker 安全加固方案，并附上可参考的配置文件示例，适合企业内部安全基线建设、生产环境上线前检查以及日常安全整改使用。

一、Docker 安全风险概述

在讨论加固方案之前，需要先明确 Docker 常见风险来源。

1. 容器与宿主机共享内核

Docker 容器并不是传统意义上的虚拟机。多个容器共享同一个宿主机 Linux 内核，只是通过 Namespace、Cgroups、Capabilities、Seccomp、AppArmor 或 SELinux 等机制实现隔离。如果隔离配置不严，容器内进程可能借助内核漏洞或错误配置影响宿主机。

2. Docker Daemon 权限过高

Docker Daemon 通常以 root 权限运行。拥有 Docker Socket 访问权限的用户，基本等同于拥有宿主机 root 权限。例如，攻击者如果能够访问 /var/run/docker.sock，就可以创建高权限容器并挂载宿主机根目录，从而读取或修改宿主机文件。

3. 镜像供应链风险

镜像中可能包含恶意程序、后门、弱口令、敏感凭据、过期依赖或高危漏洞。如果生产环境直接使用未验证的公共镜像，将增加供应链攻击风险。

4. 容器默认权限过大

如果容器以 root 用户运行，并且开启了 --privileged、挂载了敏感目录、开放了过多 Capability 或使用宿主机网络，那么容器隔离能力会显著下降。

5. 网络暴露与横向移动

Docker 默认会创建桥接网络。如果没有合理限制容器间通信、端口暴露和访问控制，攻击者可能利用一个被入侵容器继续扫描和攻击其他容器或内网服务。

二、宿主机安全加固

Docker 的安全基础首先取决于宿主机。宿主机如果存在漏洞、弱口令或权限混乱，Docker 层面的加固效果会大打折扣。

1. 使用最小化操作系统

生产环境建议使用精简版 Linux 发行版，例如 Ubuntu Server、Debian、Rocky Linux、AlmaLinux 或专门的容器宿主系统。避免在宿主机上安装无关软件，例如编译工具、数据库客户端、办公软件、调试工具等。

推荐原则：

• 宿主机只运行 Docker、监控、安全代理和必要运维组件；
• 不在宿主机上直接部署业务应用；
• 不允许普通用户长期登录宿主机；
• 定期清理无用账户、无用服务和无用端口。

2. 及时更新系统补丁

Docker 容器共享宿主机内核，因此内核漏洞对容器安全影响极大。应建立定期补丁机制，重点关注：

• Linux Kernel 安全补丁；
• Docker Engine 安全更新；
• containerd、runc 等运行时组件更新；
• OpenSSL、glibc、systemd 等基础组件漏洞。

可以使用如下命令检查系统更新：

sudo apt update && sudo apt list --upgradable

或在 RHEL 系发行版中使用：

sudo dnf check-update

3. 限制 Docker 用户组

Docker 安装后通常会创建 docker 用户组。加入该组的用户可以直接执行 Docker 命令，而无需 sudo。这虽然方便，但安全风险很高。

应遵循以下原则：

• 不随意将普通用户加入 docker 组；
• 对 Docker 管理操作使用 sudo 审计；
• 定期检查 docker 组成员；
• 对自动化平台使用最小权限账户。

检查 Docker 用户组：

getent group docker

如发现不必要用户，应及时移除：

sudo gpasswd -d username docker

三、Docker Daemon 安全配置

Docker Daemon 是 Docker 的核心管理进程。加固 Daemon 配置可以显著降低整体风险。

Docker Daemon 配置文件通常位于：

/etc/docker/daemon.json

如果文件不存在，可以手动创建。

1. 禁止暴露未加密 TCP API

Docker API 如果监听在 0.0.0.0:2375，并且没有 TLS 认证，风险极高。攻击者可以远程控制 Docker Daemon。

应避免如下配置：

{
  "hosts": ["tcp://0.0.0.0:2375", "unix:///var/run/docker.sock"]
}

如果必须远程管理 Docker，应使用 TLS 双向认证，并限制访问来源。

2. 启用用户命名空间隔离

User Namespace 可以将容器内 root 用户映射为宿主机上的非特权用户，从而降低容器逃逸后的影响范围。

推荐在 daemon.json 中开启：

{
  "userns-remap": "default"
}

启用后 Docker 会自动创建类似 dockremap 的用户和用户组。需要注意的是，开启该功能可能影响已有容器的数据卷权限，因此建议在新环境或测试验证后逐步上线。

3. 配置日志限制

容器日志如果不加限制，可能导致宿主机磁盘被写满，进而造成服务不可用。建议为 Docker 默认日志驱动设置大小和文件数量限制。

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "100m",
    "max-file": "5"
  }
}

4. 禁止容器间默认通信

Docker 默认桥接网络中，容器之间可以互相通信。对于安全要求较高的环境，可以关闭默认容器间通信，并通过自定义网络精确控制访问关系。

{
  "icc": false
}

5. 启用 Live Restore

live-restore 可以在 Docker Daemon 重启时保持容器继续运行，减少维护窗口中的业务中断风险。虽然它不是直接安全配置，但有助于提升生产稳定性。

{
  "live-restore": true
}

四、推荐 Docker Daemon 配置文件

下面是一份较为通用的 Docker 安全加固配置示例，可根据实际环境调整：

{
  "icc": false,
  "live-restore": true,
  "userns-remap": "default",
  "no-new-privileges": true,
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "100m",
    "max-file": "5"
  },
  "default-ulimits": {
    "nofile": {
      "Name": "nofile",
      "Hard": 65535,
      "Soft": 65535
    },
    "nproc": {
      "Name": "nproc",
      "Hard": 4096,
      "Soft": 2048
    }
  },
  "storage-driver": "overlay2"
}

配置完成后，重启 Docker：

sudo systemctl daemon-reload
sudo systemctl restart docker

验证配置是否生效：

docker info

需要注意的是，不同 Docker 版本对配置项支持情况可能不同。上线前应在测试环境验证，避免影响现有业务容器。

五、镜像安全加固

镜像是容器运行的基础。镜像安全直接决定容器运行时的初始安全状态。

1. 使用可信基础镜像

建议优先使用官方镜像、企业内部镜像仓库或经过安全团队审核的镜像。不要随意使用来源不明的第三方镜像。

基础镜像选择建议：

• 使用 alpine、debian:slim、ubuntu 最小化版本；
• 避免使用长期未维护的镜像；
• 固定镜像版本，不使用浮动的 latest 标签；
• 对核心镜像进行漏洞扫描和签名校验。

不推荐：

FROM ubuntu:latest

推荐：

FROM ubuntu:22.04

2. 镜像构建时避免写入敏感信息

不要在 Dockerfile 中写入密码、Token、SSH 私钥、数据库连接串等敏感信息。即使后续通过 rm 删除，敏感信息也可能仍然存在于镜像历史层中。

错误示例：

RUN echo "password=123456" > /app/config.ini

推荐做法：

• 使用环境变量注入非敏感配置；
• 使用 Kubernetes Secret、Docker Secret 或外部密钥管理系统；
• 构建阶段和运行阶段分离；
• 使用 .dockerignore 排除敏感文件。

3. 使用多阶段构建

多阶段构建可以避免将编译工具、源码、缓存文件带入最终运行镜像，从而减小攻击面。

FROM golang:1.22 AS builder
WORKDIR /src
COPY . .
RUN go build -o app

FROM debian:12-slim
WORKDIR /app
COPY --from=builder /src/app /app/app
USER 10001
CMD ["/app/app"]

4. 镜像漏洞扫描

建议在 CI/CD 流水线中加入镜像扫描，例如使用 Trivy、Grype、Clair 或企业级镜像安全平台。

Trivy 示例：

trivy image your-registry/example-app:1.0.0

对于高危和严重漏洞，应制定阻断策略。例如：

• 严重漏洞禁止上线；
• 高危漏洞需要安全审批；
• 中低危漏洞纳入周期性修复；
• 对无法修复漏洞记录风险接受说明。

六、容器运行时安全加固

容器运行参数是 Docker 安全的关键环节。很多严重风险并不是 Docker 本身导致的，而是运行容器时授予了过高权限。

1. 避免使用 privileged 模式

--privileged 会赋予容器几乎等同宿主机的权限，应严格禁止在生产环境使用。

高风险示例：

docker run --privileged -d nginx

如确实需要某些能力，应只添加必要 Capability，而不是直接开启 privileged。

2. 限制 Linux Capabilities

Docker 默认会授予容器一组 Capability。可以先删除全部 Capability，再按需添加。

推荐示例：

docker run \
  --cap-drop=ALL \
  --cap-add=NET_BIND_SERVICE \
  nginx:1.25

常见建议：

• Web 服务通常只需要绑定低端口能力；
• 不授予 SYS_ADMIN，它权限范围极大；
• 不授予 NET_ADMIN，除非容器确实负责网络管理；
• 不授予 SYS_PTRACE，避免调试和进程窥探风险。

3. 禁止权限提升

使用 no-new-privileges 可以阻止容器内进程通过 setuid 或 file capabilities 获取额外权限。

docker run \
  --security-opt no-new-privileges:true \
  nginx:1.25

4. 使用非 root 用户运行容器

容器内应用应尽量使用非 root 用户运行。可以在 Dockerfile 中指定：

RUN useradd -r -u 10001 appuser
USER 10001

运行时也可以指定：

docker run --user 10001:10001 nginx:1.25

5. 设置只读根文件系统

如果应用不需要写入根文件系统，可以启用只读模式，并将必要写入目录挂载为临时目录或数据卷。

docker run \
  --read-only \
  --tmpfs /tmp:rw,noexec,nosuid,size=64m \
  nginx:1.25

这样可以降低恶意文件落地、篡改系统文件和持久化攻击的风险。

6. 限制资源使用

通过 CPU、内存、进程数限制，可以防止单个容器耗尽宿主机资源。

docker run \
  --memory=512m \
  --memory-swap=512m \
  --cpus=1.0 \
  --pids-limit=256 \
  nginx:1.25

七、推荐 Docker Compose 安全配置

在实际项目中，Docker Compose 使用非常普遍。下面给出一份安全加固后的 docker-compose.yml 示例：

version: "3.9"

services:
  web:
    image: nginx:1.25
    container_name: secure-nginx
    restart: unless-stopped

    user: "10001:10001"
    read_only: true

    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE

    security_opt:
      - no-new-privileges:true

    tmpfs:
      - /tmp:rw,noexec,nosuid,size=64m
      - /var/cache/nginx:rw,noexec,nosuid,size=64m
      - /var/run:rw,noexec,nosuid,size=16m

    ports:
      - "8080:80"

    networks:
      - web_net

    mem_limit: 512m
    cpus: "1.0"
    pids_limit: 256

    logging:
      driver: json-file
      options:
        max-size: "100m"
        max-file: "5"

networks:
  web_net:
    driver: bridge
    internal: false

这份配置体现了几个关键原则：

• 使用非 root 用户运行；
• 开启只读根文件系统；
• 删除默认 Capability，仅保留必要能力；
• 禁止权限提升；
• 限制 CPU、内存和进程数；
• 限制日志大小；
• 使用独立网络隔离服务。

如果是后端服务、数据库或消息队列，应根据实际写入目录、端口和权限需求进一步调整。

八、网络安全加固

Docker 网络安全的核心是：最小暴露、按需互通、边界清晰。

1. 减少端口映射

不要将容器端口无差别暴露到宿主机公网。只暴露必要端口，并尽量绑定到指定 IP。

不推荐：

ports:
  - "0.0.0.0:3306:3306"

推荐：

ports:
  - "127.0.0.1:3306:3306"

对于只需容器内部访问的服务，例如 Redis、MySQL、Elasticsearch，通常不应直接暴露到公网。

2. 使用自定义网络

不要所有容器都使用默认 bridge 网络。应按业务系统、环境和访问关系划分网络。

例如：

docker network create app_frontend
docker network create app_backend

前端服务连接 app_frontend，后端服务连接 app_backend，数据库只允许后端访问。

3. 使用防火墙限制访问

宿主机层面应使用 iptables、nftables、安全组或云防火墙限制访问来源。即使 Docker 暴露了端口，也应通过网络边界控制访问范围。

例如只允许指定 IP 访问 8080：

sudo ufw allow from 192.168.1.10 to any port 8080

九、数据卷与文件挂载安全

数据卷和挂载目录是容器访问宿主机文件系统的重要通道，也是常见高风险点。

1. 避免挂载敏感目录

生产环境应禁止将以下路径挂载进容器：

/
 /etc
 /root
 /var/run/docker.sock
 /proc
 /sys
 /dev

尤其是 /var/run/docker.sock，一旦被容器访问，容器内进程就可以控制 Docker Daemon。

高风险示例：

docker run -v /var/run/docker.sock:/var/run/docker.sock app

2. 使用只读挂载

如果容器只需要读取配置文件，应使用只读挂载。

docker run \
  -v /opt/app/config:/app/config:ro \
  app:1.0.0

3. 控制数据目录权限

宿主机上的数据目录应设置最小权限，并与容器运行用户 UID/GID 对齐，避免使用 777 权限。

sudo chown -R 10001:10001 /data/app
sudo chmod -R 750 /data/app

十、审计、监控与基线检查

安全加固不是一次性工作，而是持续过程。建议建立 Docker 安全审计机制。

1. 容器运行状态审计

定期检查高风险容器：

docker ps --format "table {{.Names}}\t{{.Image}}\t{{.Ports}}\t{{.Status}}"

检查是否存在 privileged 容器：

docker inspect $(docker ps -q) --format '{{.Name}} {{.HostConfig.Privileged}}'

检查容器挂载：

docker inspect container_name --format '{{json .Mounts}}'

2. 使用 Docker Bench for Security

Docker Bench for Security 是 Docker 官方安全基线检查工具之一，可以快速发现常见不安全配置。

运行示例：

docker run --rm --net host --pid host --userns host --cap-add audit_control \
  -v /etc:/etc:ro \
  -v /usr/bin/containerd:/usr/bin/containerd:ro \
  -v /usr/bin/runc:/usr/bin/runc:ro \
  -v /usr/lib/systemd:/usr/lib/systemd:ro \
  -v /var/lib:/var/lib:ro \
  -v /var/run/docker.sock:/var/run/docker.sock:ro \
  docker/docker-bench-security

该工具适合辅助检查，但不应完全替代企业自身安全基线。对于检查结果，需要结合业务实际判断是否整改。

3. 日志集中化

建议将 Docker 日志、系统日志、安全审计日志统一采集到日志平台，例如 ELK、OpenSearch、Loki、Splunk 或云厂商日志服务。

重点关注：

• 容器异常重启；
• 镜像拉取和启动记录；
• Docker Daemon 配置变更；
• 高权限容器启动；
• 异常端口暴露；
• 容器内可疑命令执行。

十一、生产环境 Docker 安全检查清单

以下清单可用于上线前检查：

• [ ] 宿主机系统已更新安全补丁；
• [ ] Docker Engine、containerd、runc 已升级到安全版本；
• [ ] 普通用户未加入 docker 组；
• [ ] Docker API 未暴露未加密 TCP 端口；
• [ ] 已配置日志大小和日志轮转；
• [ ] 容器未使用 --privileged；
• [ ] 容器未挂载 /var/run/docker.sock；
• [ ] 容器使用非 root 用户运行；
• [ ] 已启用 no-new-privileges；
• [ ] 已按需限制 Capabilities；
• [ ] 已设置 CPU、内存和进程数限制；
• [ ] 数据卷权限符合最小权限原则；
• [ ] 数据库、缓存等服务未直接暴露公网；
• [ ] 镜像来自可信仓库；
• [ ] 镜像已完成漏洞扫描；
• [ ] 敏感信息未写入镜像或环境变量明文；
• [ ] 已配置日志采集和安全监控；
• [ ] 已建立定期审计和漏洞修复流程。

十二、总结

Docker 安全加固的核心思想是最小权限、最小暴露、可信来源、持续审计。在宿主机层面，需要保持系统和内核及时更新，严格控制 Docker 管理权限；在 Docker Daemon 层面，应关闭不必要的网络通信、限制日志、启用用户命名空间和安全选项；在镜像层面，应使用可信基础镜像、多阶段构建、漏洞扫描和敏感信息治理；在容器运行时层面，应避免 privileged 模式，限制 Capability，使用非 root 用户、只读文件系统和资源限制；在网络和存储层面，应减少端口暴露，隔离网络，避免挂载敏感目录。

需要强调的是，安全配置并不是越严格越好，而是要在业务可用性和风险控制之间取得平衡。对于生产环境，建议先建立统一 Docker 安全基线，再通过测试环境验证兼容性，最后逐步推广到业务系统。同时，应将镜像扫描、配置检查、日志监控和漏洞修复纳入 DevSecOps 流程，使 Docker 安全从“上线前检查”变成“持续安全治理”。

只要企业能够坚持标准化配置、自动化检查和持续化运营，Docker 就不仅可以提升交付效率，也可以在可控风险下稳定支撑生产业务运行。