Docker 安全加固方案｜一键部署

引言

Docker 让应用交付变得更轻量、更标准，也让开发、测试、生产环境之间的差异大幅减少。但与此同时，容器并不等于天然安全。很多团队在使用 Docker 时，往往只关注“能不能跑起来”“部署是否方便”，却忽略了镜像来源、容器权限、网络暴露、宿主机防护、日志审计、运行时限制等关键安全问题。

如果 Docker 容器配置不当，攻击者可能通过漏洞镜像、弱口令服务、危险挂载、特权容器、Docker Socket 暴露等方式突破容器边界，进一步控制宿主机，甚至横向移动到内网其他系统。因此，Docker 安全加固不是可选项，而是生产环境上线前必须完成的基础工作。

本文将围绕 Docker 的实际部署场景，提供一套可落地的安全加固方案，并给出“一键部署”思路，帮助企业或个人用户快速建立更安全的容器运行环境。

一、Docker 安全面临的主要风险

在制定安全加固方案之前，必须先理解 Docker 常见风险来源。

1. 镜像来源不可信

很多用户习惯直接从公共镜像仓库拉取镜像，例如：

docker pull nginx
docker pull mysql
docker pull redis

公共镜像虽然方便，但如果没有固定版本、没有校验来源、没有漏洞扫描，就可能引入恶意文件、过期组件或高危漏洞。例如旧版本 OpenSSL、glibc、bash、curl 等基础组件都可能成为攻击入口。

2. 容器权限过高

部分用户为了省事，会使用如下参数启动容器：

docker run --privileged ...

--privileged 会赋予容器几乎等同于宿主机的权限，容器可以访问宿主机设备、加载内核模块、修改系统参数，极大增加逃逸风险。

3. 敏感目录危险挂载

常见危险挂载包括：

-v /:/host
-v /var/run/docker.sock:/var/run/docker.sock
-v /etc:/host/etc

尤其是挂载 Docker Socket，如果容器内部被攻破，攻击者就可以通过 Docker API 创建新容器、挂载宿主机根目录，最终接管宿主机。

4. 网络端口暴露过多

有些部署习惯会把数据库、缓存、管理后台全部映射到公网，例如：

-p 3306:3306
-p 6379:6379
-p 8080:8080

如果服务本身存在弱口令、未授权访问或漏洞，公网暴露就会迅速变成入侵入口。

5. 缺少资源限制

如果容器没有 CPU、内存、进程数限制，一旦应用异常、遭受攻击或出现死循环，可能耗尽宿主机资源，导致整台服务器不可用。

6. 日志和审计不足

安全事件发生后，如果没有容器日志、Docker 守护进程日志、系统审计日志，就很难判断攻击来源、影响范围和恢复路径。

二、Docker 安全加固总体思路

Docker 安全加固应遵循以下原则：

1. 最小权限原则：容器只拥有完成任务所必需的权限。
2. 最小暴露原则：只开放必要端口，只挂载必要目录。
3. 镜像可信原则：使用可信来源、固定版本、定期扫描。
4. 隔离优先原则：容器之间、容器与宿主机之间尽量隔离。
5. 可审计原则：关键操作、异常行为、日志事件可追踪。
6. 自动化原则：安全配置应脚本化、模板化，避免人工遗漏。

三、宿主机基础安全加固

Docker 的安全基础首先取决于宿主机。如果宿主机本身不安全，容器层面的加固效果也会大打折扣。

1. 使用最小化系统

生产环境建议使用精简稳定的 Linux 发行版，例如 Ubuntu Server LTS、Debian Stable、Rocky Linux、AlmaLinux 等。不要在 Docker 宿主机上安装无关服务，如桌面环境、FTP、Telnet、测试数据库等。

2. 及时更新系统补丁

定期更新系统组件：

apt update && apt upgrade -y

或：

dnf update -y

尤其要关注内核、containerd、runc、openssl、glibc 等组件的安全公告。

3. 禁止 root 远程登录

修改 SSH 配置：

PermitRootLogin no
PasswordAuthentication no

推荐使用普通用户加 SSH Key 登录，再通过 sudo 执行管理操作。

4. 配置防火墙

只开放必要端口，例如 SSH、HTTP、HTTPS：

ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

数据库、Redis、Elasticsearch、Prometheus 等服务不应直接暴露公网，应该放在内网或 Docker 私有网络中。

四、Docker Daemon 安全配置

Docker Daemon 是容器运行的核心组件，必须重点保护。

1. 禁止未加密远程 API

不要开放如下形式的 Docker API：

-H tcp://0.0.0.0:2375

2375 是未加密 Docker API，一旦暴露，攻击者可以直接远程控制 Docker。若必须远程管理，应使用 TLS 认证或通过 SSH 隧道。

2. 配置 daemon.json

推荐创建或修改：

/etc/docker/daemon.json

示例配置：

{
  "icc": false,
  "live-restore": true,
  "no-new-privileges": true,
  "userland-proxy": false,
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "100m",
    "max-file": "3"
  },
  "default-ulimits": {
    "nofile": {
      "Name": "nofile",
      "Hard": 65535,
      "Soft": 65535
    }
  }
}

配置说明：

• icc: false：限制默认 bridge 网络中容器间通信。
• live-restore: true：Docker Daemon 重启时尽量不影响正在运行的容器。
• no-new-privileges: true：阻止容器进程获取额外权限。
• userland-proxy: false：减少不必要的代理进程。
• log-opts：限制日志大小，避免日志打满磁盘。

修改后重启 Docker：

systemctl restart docker

五、容器运行安全规范

1. 避免使用特权容器

除非确有必要，不要使用：

--privileged

如果应用需要特定能力，应使用 --cap-add 精确添加，而不是一次性放开全部能力。

2. 删除不必要的 Linux Capability

推荐默认删除所有能力，再按需添加：

--cap-drop=ALL

例如 Nginx 通常不需要大量系统能力，可以结合非 root 用户运行。

3. 启用只读根文件系统

对不需要写入系统目录的容器，推荐启用：

--read-only

如果应用需要写临时文件，可以额外挂载临时目录：

--tmpfs /tmp

4. 限制容器资源

启动容器时设置 CPU、内存、进程数限制：

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

这样可以防止单个容器耗尽宿主机资源。

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

Dockerfile 中应尽量指定普通用户：

RUN adduser --disabled-password --gecos "" appuser
USER appuser

运行时也可以指定用户：

docker run --user 1000:1000 ...

即使容器被攻破，攻击者获得的权限也会受到限制。

六、镜像安全加固

1. 固定镜像版本

不要在生产环境使用 latest：

docker pull nginx:latest

应明确版本：

docker pull nginx:1.25.5

这样可以避免镜像自动变化导致不可控风险。

2. 使用轻量基础镜像

优先选择更小、更可控的基础镜像，例如：

FROM alpine:3.20

或使用 distroless 镜像，减少 shell、包管理器和调试工具，从而降低攻击面。

3. 构建时清理缓存

Dockerfile 中安装软件后应清理缓存，减少镜像体积和残留文件：

RUN apt-get update \
    && apt-get install -y --no-install-recommends curl \
    && rm -rf /var/lib/apt/lists/*

4. 定期漏洞扫描

可使用 Trivy 扫描镜像：

trivy image nginx:1.25.5

建议在 CI/CD 流水线中加入漏洞扫描步骤，对高危漏洞进行拦截。

七、网络安全加固

1. 使用自定义网络

不要让所有容器都运行在默认 bridge 网络中。推荐为不同业务创建不同网络：

docker network create app-net
docker network create db-net

前端服务、后端服务、数据库服务应根据访问关系分别加入对应网络。

2. 数据库不暴露公网

数据库容器不要使用 -p 3306:3306 暴露到公网。应用容器可以通过 Docker 内部网络访问数据库：

services:
  app:
    networks:
      - app-net
      - db-net

  mysql:
    networks:
      - db-net

这样外部无法直接访问数据库端口。

3. 使用反向代理统一入口

推荐只暴露 Nginx、Traefik、Caddy 等入口服务的 80 和 443 端口，内部服务不直接对外暴露。这样便于统一配置 HTTPS、访问控制、限流和日志。

八、敏感信息管理

1. 不要把密码写进镜像

错误示例：

ENV MYSQL_PASSWORD=123456

镜像层是可追溯的，敏感信息可能被导出或查看。应通过环境变量文件、Secret 管理系统或部署平台注入。

2. 使用 .env 文件并限制权限

chmod 600 .env

.env 文件不应提交到 Git 仓库，应加入 .gitignore。

3. Docker Compose 中引用变量

environment:
  MYSQL_PASSWORD: ${MYSQL_PASSWORD}

这样可以将配置和代码分离，降低泄露风险。

九、日志、监控与审计

1. 限制容器日志大小

如果不限制日志，容器持续输出可能打满磁盘。推荐在 daemon.json 或 Compose 中配置日志轮转：

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

2. 监控容器状态

可以使用 Prometheus、cAdvisor、Grafana 监控容器 CPU、内存、网络、磁盘等指标。至少应关注：

• 容器异常重启次数
• CPU 和内存持续高占用
• 磁盘使用率
• 对外连接异常增长
• 未知端口监听

3. 审计 Docker 操作

建议关注以下日志：

journalctl -u docker

以及系统登录、sudo、SSH、iptables 等日志。对于高安全要求环境，可以结合 auditd 监控 Docker Socket、容器配置文件和关键目录访问行为。

十、一键部署安全加固脚本示例

以下脚本适用于 Ubuntu / Debian 系统，可用于初始化 Docker 安全配置。实际生产环境中，请根据业务情况调整端口、网络和镜像策略。

#!/usr/bin/env bash
set -euo pipefail

echo "[1/6] 更新系统软件包"
apt update
apt upgrade -y

echo "[2/6] 安装基础安全工具"
apt install -y ufw curl ca-certificates gnupg lsb-release

echo "[3/6] 配置防火墙"
ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw --force enable

echo "[4/6] 创建 Docker Daemon 安全配置"
mkdir -p /etc/docker

cat > /etc/docker/daemon.json <<'EOF'
{
  "icc": false,
  "live-restore": true,
  "no-new-privileges": true,
  "userland-proxy": false,
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "100m",
    "max-file": "3"
  },
  "default-ulimits": {
    "nofile": {
      "Name": "nofile",
      "Hard": 65535,
      "Soft": 65535
    }
  }
}
EOF

echo "[5/6] 重启 Docker 服务"
systemctl daemon-reload
systemctl restart docker
systemctl enable docker

echo "[6/6] 创建安全隔离网络"
docker network create app-net || true
docker network create db-net || true

echo "Docker 基础安全加固完成"

执行方式：

chmod +x docker-hardening.sh
sudo ./docker-hardening.sh

该脚本完成了系统更新、防火墙配置、Docker Daemon 安全参数设置、日志轮转和基础网络隔离创建。它不能替代完整的安全体系，但可以作为生产环境 Docker 初始化的安全基线。

十一、安全版 Docker Compose 示例

下面是一个较安全的 Compose 配置示例：

version: "3.9"

services:
  web:
    image: nginx:1.25.5
    container_name: secure-nginx
    restart: unless-stopped
    read_only: true
    cap_drop:
      - ALL
    security_opt:
      - no-new-privileges:true
    tmpfs:
      - /tmp
      - /var/cache/nginx
      - /var/run
    ports:
      - "80:80"
    networks:
      - app-net
    pids_limit: 256
    mem_limit: 256m
    cpus: "0.5"
    logging:
      driver: json-file
      options:
        max-size: "50m"
        max-file: "3"

networks:
  app-net:
    external: true

该示例体现了几个关键安全点：

• 固定镜像版本，不使用 latest。
• 启用只读文件系统。
• 删除默认 Capability。
• 开启 no-new-privileges。
• 设置资源限制。
• 配置日志轮转。
• 使用外部自定义网络。

十二、上线前安全检查清单

在 Docker 服务上线前，建议逐项检查：

• 是否禁止使用 --privileged。
• 是否避免挂载 /var/run/docker.sock。
• 是否避免挂载宿主机根目录 /。
• 是否固定镜像版本。
• 是否完成镜像漏洞扫描。
• 是否关闭不必要的公网端口。
• 是否配置防火墙规则。
• 是否限制容器 CPU、内存和进程数。
• 是否配置日志轮转。
• 是否使用非 root 用户运行应用。
• 是否将敏感信息从镜像和代码中剥离。
• 是否启用监控和告警。
• 是否定期更新宿主机和 Docker 组件。

十三、常见错误做法

1. 为了方便直接开放 Docker API

将 Docker API 暴露在公网是非常危险的行为。攻击者一旦访问成功，就可以直接创建容器、挂载宿主机目录并执行命令。

2. 所有服务都映射公网端口

数据库、Redis、消息队列等基础服务通常只应供内部应用访问，不应直接暴露给公网。

3. 使用 latest 镜像上线

latest 不代表最新安全版本，也不代表稳定版本。它只是一个标签，可能随时变化。

4. 不限制日志大小

容器日志持续增长会导致磁盘被写满，进而影响业务和系统稳定性。

5. 把安全配置留给人工操作

人工操作容易遗漏。安全基线应尽量脚本化、模板化，并纳入自动化部署流程。

结语

Docker 安全加固并不是单一配置项，而是一套完整的安全工程实践。它覆盖宿主机安全、Docker Daemon 配置、镜像安全、容器权限、网络隔离、敏感信息管理、日志审计和监控告警等多个层面。

对于生产环境而言，最重要的原则是：不要默认信任镜像，不要给容器过高权限，不要暴露不必要端口，不要把敏感信息写死在镜像或代码里，不要忽视日志和监控。

本文提供的一键部署脚本和 Docker Compose 示例，可以作为 Docker 安全加固的基础模板。实际落地时，还应结合业务架构、合规要求、云平台安全组、CI/CD 流水线、漏洞扫描系统和运维审计体系进一步完善。只有将安全基线固化到日常部署流程中，Docker 才能真正成为既高效又可靠的生产基础设施。