Docker 安全加固方案｜附源码

Docker 让应用交付变得更轻量、更标准，也让开发、测试、运维之间的协作效率大幅提升。但与此同时，容器并不等于天然安全。很多团队在使用 Docker 时，往往只关注“能不能跑起来”“镜像够不够小”“部署是否方便”，却忽略了容器运行时权限、镜像来源、宿主机隔离、网络访问控制、敏感信息管理等关键安全问题。

在真实生产环境中，Docker 安全问题可能导致镜像被植入后门、容器逃逸、宿主机文件被篡改、数据库凭据泄露、内网服务被横向攻击等严重后果。因此，Docker 安全加固不是可选项，而是容器化落地过程中必须建设的一部分。

本文将从镜像安全、容器运行安全、权限控制、网络隔离、日志审计、密钥管理、Docker Daemon 加固、CI/CD 安全等多个方面，系统梳理一套可落地的 Docker 安全加固方案，并附上可直接参考的配置和源码示例。

一、Docker 安全风险概览

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

1. 镜像来源不可信

很多开发者会直接从公共镜像仓库拉取镜像，例如：

docker pull some-user/some-image:latest

如果镜像维护者不可信，或者镜像长期无人维护，就可能存在恶意脚本、挖矿程序、漏洞组件、弱口令服务等风险。

2. 使用 latest 标签

latest 看似方便，实际上非常危险。因为它不是一个固定版本，镜像内容可能随时变化。今天部署和明天部署得到的镜像可能并不一致，导致不可控风险。

3. 容器以 root 用户运行

默认情况下，Docker 容器内的进程通常以 root 用户运行。如果容器被攻破，攻击者可能借助高权限进一步尝试逃逸或攻击宿主机资源。

4. 挂载宿主机敏感目录

例如：

docker run -v /:/host ubuntu

这种方式几乎等于把宿主机暴露给容器。一旦容器被入侵，攻击者就可以读取甚至修改宿主机文件。

5. 开放 Docker API

Docker Daemon 默认具有很高权限。如果 Docker API 被未授权访问，攻击者可以直接创建特权容器、挂载宿主机目录，最终控制宿主机。

6. 特权模式滥用

docker run --privileged nginx

--privileged 会给予容器几乎等同宿主机的权限。除非非常特殊的场景，否则生产环境应严格禁止。

二、镜像安全加固

镜像是容器运行的基础，镜像不安全，容器运行得再规范也难以保证安全。

1. 使用可信基础镜像

优先选择官方镜像、经过安全扫描的企业内部镜像，或者来自可信供应商的镜像。

推荐：

FROM nginx:1.26.2-alpine

不推荐：

FROM nginx:latest

固定版本可以提升部署可控性，也方便后续漏洞追踪和回滚。

2. 减少镜像体积

镜像越大，包含的软件包越多，潜在攻击面也越大。可以优先选择 Alpine、Distroless 等轻量镜像。

例如 Go 应用可以使用多阶段构建：

# 构建阶段
FROM golang:1.23-alpine AS builder

WORKDIR /app

COPY go.mod go.sum ./
RUN go mod download

COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -o server ./cmd/server

# 运行阶段
FROM gcr.io/distroless/static-debian12

WORKDIR /app

COPY --from=builder /app/server /app/server

USER 65532:65532

EXPOSE 8080

ENTRYPOINT ["/app/server"]

这个 Dockerfile 有几个优点：

• 构建环境和运行环境分离；
• 最终镜像不包含编译器和包管理器；
• 使用非 root 用户运行；
• 镜像体积更小，攻击面更低。

3. 禁止在镜像中写入敏感信息

错误示例：

ENV DB_PASSWORD=123456
ENV ACCESS_KEY=AKIAxxxxxx

镜像一旦构建完成，环境变量、构建历史和镜像层都可能被查看。敏感信息不应该写入 Dockerfile，也不应该提交到代码仓库。

可以通过运行时环境变量、Docker Secret、Kubernetes Secret 或外部密钥系统注入。

4. 镜像漏洞扫描

建议在 CI/CD 流程中加入镜像扫描，例如使用 Trivy。

trivy image --severity HIGH,CRITICAL nginx:1.26.2-alpine

如果要在流水线中强制阻断高危漏洞，可以这样写：

trivy image \
  --exit-code 1 \
  --severity CRITICAL \
  my-app:1.0.0

当发现严重漏洞时，流水线直接失败，避免高危镜像进入生产环境。

三、Dockerfile 安全规范

一个安全的 Dockerfile 应该尽量遵循以下原则：

• 固定基础镜像版本；
• 使用多阶段构建；
• 不安装无关工具；
• 不写入敏感信息；
• 使用非 root 用户；
• 清理缓存文件；
• 明确暴露端口；
• 使用只读文件系统时提前规划写入目录。

下面是一个相对规范的 Node.js 应用 Dockerfile：

FROM node:20-alpine AS deps

WORKDIR /app

COPY package.json package-lock.json ./
RUN npm ci --omit=dev

FROM node:20-alpine AS runner

WORKDIR /app

ENV NODE_ENV=production

RUN addgroup -S appgroup && adduser -S appuser -G appgroup

COPY --from=deps /app/node_modules ./node_modules
COPY . .

USER appuser

EXPOSE 3000

CMD ["node", "server.js"]

这个示例避免使用 root 用户运行 Node.js 进程，并且只安装生产依赖，减少潜在风险。

四、容器运行时安全加固

镜像安全只是第一步，容器启动参数同样重要。

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

可以在 Dockerfile 中声明：

USER 10001:10001

也可以在运行时指定：

docker run --user 10001:10001 my-app:1.0.0

这样即使应用被入侵，攻击者也无法直接获得容器内 root 权限。

2. 禁止特权模式

生产环境应禁止：

docker run --privileged my-app

除非容器需要管理内核模块、访问宿主机设备等极少数场景，否则不应开启。

3. 限制 Linux Capabilities

Docker 默认会给容器一组 Linux Capabilities。可以通过 --cap-drop 删除全部能力，再按需添加。

推荐：

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

这里仅允许容器绑定低端口，其他能力全部移除。

4. 使用只读根文件系统

如果应用不需要写入根文件系统，建议启用：

docker run \
  --read-only \
  --tmpfs /tmp \
  my-app:1.0.0

这样即使攻击者获得应用权限，也很难向容器文件系统写入后门文件。

5. 限制资源使用

避免单个容器耗尽宿主机资源。

docker run \
  --memory=512m \
  --cpus=1.0 \
  --pids-limit=256 \
  my-app:1.0.0

常见限制项包括：

• --memory：限制内存；
• --cpus：限制 CPU；
• --pids-limit：限制进程数量；
• --ulimit：限制文件句柄等系统资源。

6. 启用安全配置

可以使用 Docker 默认的 seccomp 配置，也可以自定义 seccomp profile。

docker run \
  --security-opt no-new-privileges:true \
  my-app:1.0.0

no-new-privileges 可以防止进程通过 setuid 等方式获得额外权限。

五、Docker Compose 安全配置示例

下面给出一个加固后的 docker-compose.yml 示例。

version: "3.9"

services:
  web:
    image: my-app:1.0.0
    container_name: my-app-web
    user: "10001:10001"
    read_only: true
    tmpfs:
      - /tmp
    ports:
      - "127.0.0.1:8080:8080"
    environment:
      NODE_ENV: production
    cap_drop:
      - ALL
    security_opt:
      - no-new-privileges:true
    mem_limit: 512m
    cpus: "1.0"
    pids_limit: 256
    restart: unless-stopped
    networks:
      - app_net
    volumes:
      - app_logs:/app/logs

networks:
  app_net:
    driver: bridge

volumes:
  app_logs:

这个配置体现了多个安全原则：

• 使用非 root 用户；
• 根文件系统只读；
• 删除所有 Linux Capabilities；
• 禁止权限提升；
• 限制 CPU、内存和进程数；
• 仅绑定本地地址，避免服务直接暴露到公网；
• 使用独立网络隔离服务。

六、网络安全加固

Docker 默认会创建 bridge 网络，容器之间可能可以互相访问。如果没有合理规划网络，攻击者入侵一个容器后，可能继续扫描和攻击其他容器。

1. 使用自定义网络

不要所有服务都使用默认 bridge 网络。

docker network create app_net

启动容器时指定网络：

docker run --network app_net my-app:1.0.0

2. 最小化端口暴露

如果服务只需要被本机反向代理访问，可以绑定到 127.0.0.1：

docker run -p 127.0.0.1:8080:8080 my-app:1.0.0

不推荐直接暴露数据库端口：

docker run -p 3306:3306 mysql

数据库应尽量只在内部网络中访问。

3. 按服务拆分网络

例如 Web 服务需要访问 API，但不需要访问数据库；API 需要访问数据库。可以通过多个网络隔离。

services:
  web:
    image: web:1.0.0
    networks:
      - frontend

  api:
    image: api:1.0.0
    networks:
      - frontend
      - backend

  db:
    image: mysql:8.4
    networks:
      - backend

networks:
  frontend:
  backend:

这样 Web 容器无法直接访问数据库，降低横向移动风险。

七、敏感信息管理

敏感信息包括数据库密码、JWT 密钥、API Token、云厂商密钥、证书私钥等。

1. 不要写入镜像

不要在 Dockerfile、源码、Compose 文件中硬编码密码。

错误示例：

environment:
  MYSQL_ROOT_PASSWORD: root123456

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

.env 可以用于开发环境，但生产环境仍建议使用更安全的密钥系统。

DB_HOST=db
DB_USER=app
DB_PASSWORD=change_me

权限建议：

chmod 600 .env

同时应确保 .env 不进入 Git：

.env
.env.*

3. 使用 Docker Secrets

Swarm 模式下可以使用 Docker Secrets：

echo "strong_password" | docker secret create db_password -

在 Compose 中引用：

services:
  app:
    image: my-app:1.0.0
    secrets:
      - db_password

secrets:
  db_password:
    external: true

应用读取路径：

/run/secrets/db_password

八、Docker Daemon 安全加固

Docker Daemon 拥有非常高的权限，因此必须重点保护。

1. 禁止未授权远程访问

危险配置：

dockerd -H tcp://0.0.0.0:2375

2375 是未加密端口，如果暴露到公网，风险极高。

推荐使用 Unix Socket：

unix:///var/run/docker.sock

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

2. 保护 Docker Socket

/var/run/docker.sock 等同于宿主机 root 权限入口。不要随意挂载给容器。

危险示例：

docker run -v /var/run/docker.sock:/var/run/docker.sock some-image

如果确实需要访问 Docker API，应使用权限受限的代理，或通过独立的运维服务进行封装。

3. 配置 Docker Daemon

可以编辑 /etc/docker/daemon.json：

{
  "icc": false,
  "no-new-privileges": true,
  "live-restore": true,
  "userland-proxy": false,
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "100m",
    "max-file": "3"
  }
}

字段说明：

• icc: false：关闭默认容器间通信；
• no-new-privileges: true：默认禁止权限提升；
• live-restore: true：Docker Daemon 重启时保持容器运行；
• userland-proxy: false：减少额外代理进程；
• log-opts：限制日志大小，避免磁盘被打满。

修改后重启 Docker：

systemctl restart docker

九、日志与审计

安全加固不仅是防御，也包括发现和追踪。

1. 限制容器日志大小

如果不限制日志，攻击者可能通过大量输出日志打满磁盘。

docker run \
  --log-driver json-file \
  --log-opt max-size=100m \
  --log-opt max-file=3 \
  my-app:1.0.0

2. 记录关键操作

应重点关注：

• 镜像拉取和推送；
• 容器创建和删除；
• 特权容器启动；
• Docker Socket 访问；
• 异常端口暴露；
• 宿主机敏感目录挂载；
• 容器内异常进程和网络连接。

3. 使用审计工具

可以结合 Linux Auditd 监控 Docker 相关文件：

auditctl -w /usr/bin/docker -p x -k docker
auditctl -w /var/run/docker.sock -p rwxa -k docker_sock
auditctl -w /etc/docker/daemon.json -p wa -k docker_config

查询审计日志：

ausearch -k docker_sock

十、CI/CD 中的 Docker 安全实践

安全应该前置到研发流程，而不是等到生产事故发生后再补救。

推荐在流水线中加入以下步骤：

1. Dockerfile 静态扫描；
2. 依赖漏洞扫描；
3. 镜像漏洞扫描；
4. 镜像签名；
5. 禁止使用 latest；
6. 禁止 root 用户运行；
7. 阻断高危漏洞镜像发布。

下面是一个 GitHub Actions 示例：

name: Docker Security Check

on:
  push:
    branches:
      - main

jobs:
  docker-security:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout source
        uses: actions/checkout@v4

      - name: Build image
        run: docker build -t my-app:${{ github.sha }} .

      - name: Scan image with Trivy
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: my-app:${{ github.sha }}
          severity: CRITICAL,HIGH
          exit-code: "1"

      - name: Check image user
        run: |
          USER_NAME=$(docker inspect my-app:${{ github.sha }} --format '{{.Config.User}}')
          if [ -z "$USER_NAME" ] || [ "$USER_NAME" = "root" ]; then
            echo "Image must not run as root"
            exit 1
          fi

这个流程可以自动阻断高危镜像和 root 用户镜像。

十一、容器安全检测脚本源码

下面提供一个简单的 Shell 脚本，用于检查当前宿主机中运行容器的部分高风险配置。

文件名可以保存为 docker-security-check.sh。

#!/usr/bin/env bash

set -euo pipefail

echo "Docker Security Check"
echo "====================="

containers=$(docker ps -q)

if [ -z "$containers" ]; then
  echo "No running containers found."
  exit 0
fi

for container in $containers; do
  name=$(docker inspect "$container" --format '{{.Name}}' | sed 's#^/##')
  privileged=$(docker inspect "$container" --format '{{.HostConfig.Privileged}}')
  user=$(docker inspect "$container" --format '{{.Config.User}}')
  readonly=$(docker inspect "$container" --format '{{.HostConfig.ReadonlyRootfs}}')
  pid_limit=$(docker inspect "$container" --format '{{.HostConfig.PidsLimit}}')
  cap_add=$(docker inspect "$container" --format '{{json .HostConfig.CapAdd}}')
  binds=$(docker inspect "$container" --format '{{json .HostConfig.Binds}}')

  echo
  echo "Container: $name"
  echo "ID: $container"

  if [ "$privileged" = "true" ]; then
    echo "[HIGH] Privileged mode is enabled."
  else
    echo "[OK] Privileged mode is disabled."
  fi

  if [ -z "$user" ] || [ "$user" = "root" ] || [ "$user" = "0" ]; then
    echo "[WARN] Container may be running as root."
  else
    echo "[OK] Container user: $user"
  fi

  if [ "$readonly" = "true" ]; then
    echo "[OK] Root filesystem is read-only."
  else
    echo "[WARN] Root filesystem is writable."
  fi

  if [ "$pid_limit" = "0" ] || [ "$pid_limit" = "-1" ]; then
    echo "[WARN] PID limit is not configured."
  else
    echo "[OK] PID limit: $pid_limit"
  fi

  if echo "$cap_add" | grep -q "null"; then
    echo "[OK] No extra capabilities added."
  else
    echo "[WARN] Extra capabilities: $cap_add"
  fi

  if echo "$binds" | grep -q "/var/run/docker.sock"; then
    echo "[HIGH] Docker socket is mounted."
  fi

  if echo "$binds" | grep -q '"/:'; then
    echo "[HIGH] Host root directory may be mounted."
  fi
done

使用方式：

chmod +x docker-security-check.sh
./docker-security-check.sh

这个脚本不能替代专业安全扫描工具，但可以作为基础巡检手段，帮助快速发现明显风险。

十二、生产环境推荐基线

生产环境可以参考以下 Docker 安全基线：

十三、常见错误配置清单

以下配置在生产环境中应重点避免：

docker run --privileged app
docker run -v /:/host app
docker run -v /var/run/docker.sock:/var/run/docker.sock app
docker run -p 0.0.0.0:3306:3306 mysql
docker run app:latest
docker run --user root app

这些配置并不一定在所有场景下都会立刻造成安全事故，但它们显著扩大了攻击面。一旦应用存在漏洞，攻击者就更容易利用这些配置进一步扩大影响。

十四、总结

Docker 安全加固不是单一配置项，而是一套贯穿镜像构建、容器运行、网络隔离、权限控制、日志审计、密钥管理和 CI/CD 流程的系统工程。

一个相对安全的 Docker 生产实践，应至少做到以下几点：

• 镜像来源可信，版本固定；
• Dockerfile 不包含敏感信息；
• 应用容器不以 root 用户运行；
• 禁止特权模式和不必要的 Capabilities；
• 限制 CPU、内存、PID 等资源；
• 避免挂载宿主机敏感目录；
• 不把 Docker Socket 暴露给业务容器；
• 网络按服务边界进行隔离；
• CI/CD 阶段进行漏洞扫描和策略阻断；
• 对 Docker Daemon、容器日志和关键操作进行审计。

容器安全的核心原则是“最小权限、最小暴露、可审计、可回滚”。只要围绕这几个原则持续建设，Docker 不仅可以提升交付效率，也可以成为稳定、安全、可控的基础设施能力。