Docker 容器化部署企业核心业务时，必须立刻修改的 5 个默认安全配置

「我们服务器被入侵了。运维查了一晚上发现：黑客通过暴露在公网的 Redis 容器拿到 shell，从 Redis 跳到 MySQL 容器，导出整库。」

这是典型的 Docker 默认配置受害案例。Docker 让部署变简单，但默认配置全是为「开发方便」设计的，直接拿来生产 = 裸奔。这篇拆开 5 个最致命的默认配置，给出加固方案。

---

一、Docker 默认配置的 5 大致命问题

| 配置项 | 默认 | 风险 | |---|---|---| | 容器用户 | root | 容器逃逸提权 | | 端口绑定 | 0.0.0.0 | 暴露公网 | | 镜像来源 | 任意 | 供应链投毒 | | 凭证管理 | env 明文 | 泄露 | | 日志驱动 | json-file 不限 | 磁盘爆盘 |

---

二、问题 1：容器以 root 用户运行

风险

• 容器内 root = 宿主机 root（如果发生逃逸）
• 攻击者拿到容器 shell → 直接修改系统文件、装木马、跳板攻击

默认行为

# 99% 的 Dockerfile 不指定 user → 默认 root
FROM nginx
COPY html /usr/share/nginx/html
# 容器内运行用户是 root

修复方法

方法 1：Dockerfile 加 USER 指令

FROM node:20-alpine

RUN addgroup -S app && adduser -S app -G app
WORKDIR /app
COPY --chown=app:app . .

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

方法 2：docker-compose 强制

services:
  app:
    image: your-image
    user: "1000:1000"
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE   # 仅在需要监听 < 1024 端口时
    security_opt:
      - no-new-privileges:true
    read_only: true
    tmpfs:
      - /tmp
      - /run

关键能力裁剪

cap_drop:
  - ALL              # 移除所有 capability
cap_add:
  - CHOWN            # 按需添加
  - NET_BIND_SERVICE

---

三、问题 2：端口暴露到 0.0.0.0

风险

• 默认 docker run -p 5432:5432 绑定到 0.0.0.0（公网可访问）
• 防火墙以为是「内部端口」，但 Docker 直接绕过 iptables
• 黑客扫描发现 → 弱密码 / 默认凭据破解

真实案例

• Redis（无密码）暴露在 6379 → 一周内 100% 被入侵
• MongoDB 27017 → 数据被勒索（删库 + 比特币赎金）
• Elasticsearch 9200 → 数据泄露

修复方法

必做：只绑定 127.0.0.1

services:
  postgres:
    image: postgres:16
    ports:
      - "127.0.0.1:5432:5432"   # ⭐ 只绑定本地

更好：用内部网络

services:
  app:
    image: your-app
    networks:
      - internal

  postgres:
    image: postgres:16
    networks:
      - internal
    # 不暴露端口

networks:
  internal:
    driver: bridge

防火墙补充

即使绑定 0.0.0.0，也用 iptables 限制：

# 仅允许 10.0.0.0/24 访问 5432
sudo iptables -I DOCKER-USER -p tcp --dport 5432 ! -s 10.0.0.0/24 -j DROP

---

四、问题 3：镜像安全（供应链投毒）

风险

• DockerHub 上有大量挂着官方名义的恶意镜像
• 知名镜像也可能被植入挖矿、后门
• 镜像里预装了过期组件（Log4j 老版本、OpenSSL 0day）

真实案例

• 2024 年 6 月：知名 npm 镜像被植入挖矿脚本，3 万企业受影响
• 2025 年 1 月：DockerHub 一个 1M+ 下载的 nginx 衍生镜像被发现含后门

修复方法

1. 只用官方镜像 / 大厂签名镜像

# ✅ 推荐
image: nginx:1.25-alpine-slim
image: postgres:16-alpine

# ❌ 避免
image: random_user/nginx-premium

2. 锁定 SHA256

image: nginx@sha256:abc123...

3. 用镜像扫描

• Trivy（开源 ⭐）：扫漏洞 + 凭证
• Snyk：商业，集成 CI
• Docker Scout：Docker 自带

# Trivy 一键扫描
trivy image nginx:1.25-alpine

4. 内网镜像仓库

• Harbor（开源 ⭐）/ AWS ECR / 阿里云 ACR
• 所有镜像先扫描 → 入库 → 容器只拉内网
• 防止供应链污染

---

五、问题 4：凭证管理（env 明文）

风险

• 数据库密码、API key 写在 docker-compose.yml 里
• git push 一下就泄露
• docker inspect 看到所有 env

默认错误用法

# ❌ 危险
services:
  app:
    image: your-app
    environment:
      - DB_PASSWORD=admin123
      - OPENAI_KEY=sk-xxx

修复方法

方法 1：Docker Secrets（推荐 ⭐）

services:
  app:
    image: your-app
    secrets:
      - db_password
      - openai_key
    environment:
      DB_PASSWORD_FILE: /run/secrets/db_password
      OPENAI_KEY_FILE: /run/secrets/openai_key

secrets:
  db_password:
    file: ./secrets/db_password.txt
  openai_key:
    file: ./secrets/openai_key.txt

应用读取：

db_password = open("/run/secrets/db_password").read().strip()

方法 2：HashiCorp Vault

• 容器启动时从 Vault 拉凭证
• 凭证自动轮换
• 适合大企业

方法 3：云厂商 KMS

• AWS Secrets Manager / 阿里云 KMS
• 应用启动时 API 拉取

通用规范

• .env.example 入库，.env gitignore
• secrets/ 目录 chmod 600
• 不要在日志里打印凭证

---

六、问题 5：日志驱动爆盘

风险

• 默认 json-file 日志驱动无大小限制
• 业务跑久了 / 出 bug 时刷错误 → 几天日志几十 GB
• 磁盘满了 → 服务挂、监控失灵、连日志都看不了

真实案例

某客户 Nginx 容器跑了 1 年 → 日志文件 200GB → 服务器磁盘 100%、所有服务挂

修复方法

docker-compose 配置

services:
  app:
    image: your-app
    logging:
      driver: "json-file"
      options:
        max-size: "100m"      # 单文件 100MB
        max-file: "5"         # 保留 5 个轮转

全局配置 /etc/docker/daemon.json

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

更好：集中日志

• ELK / Loki / 阿里云 SLS
• 容器日志推到日志中心
• 本地不存

---

七、企业级 docker-compose 模板

把上面 5 个加固组合到一个生产可用模板：

version: "3.8"

x-defaults: &defaults
  restart: unless-stopped
  logging:
    driver: "json-file"
    options:
      max-size: "100m"
      max-file: "5"
  security_opt:
    - no-new-privileges:true

services:
  app:
    <<: *defaults
    image: registry.your-company.com/app:1.2.3
    user: "1000:1000"
    ports:
      - "127.0.0.1:8080:8080"
    cap_drop: [ALL]
    cap_add: [NET_BIND_SERVICE]
    read_only: true
    tmpfs:
      - /tmp
    networks: [internal]
    secrets:
      - db_password
      - api_key
    environment:
      DB_HOST: postgres
      DB_PASSWORD_FILE: /run/secrets/db_password
      API_KEY_FILE: /run/secrets/api_key

  postgres:
    <<: *defaults
    image: postgres:16-alpine
    user: "70:70"
    networks: [internal]
    secrets:
      - db_password
    environment:
      POSTGRES_PASSWORD_FILE: /run/secrets/db_password
    volumes:
      - postgres-data:/var/lib/postgresql/data

networks:
  internal:
    driver: bridge
    internal: false

volumes:
  postgres-data:

secrets:
  db_password:
    file: ./secrets/db_password.txt
  api_key:
    file: ./secrets/api_key.txt

---

八、CIS Docker Benchmark 关键检查

CIS（Center for Internet Security）官方 Docker 安全 Benchmark 有 100+ 项，最重要的 10 个：

1. ✅ 容器不以 root 运行
2. ✅ 限制容器 capability
3. ✅ 限制端口暴露
4. ✅ 容器只读文件系统
5. ✅ 使用官方 / 签名镜像
6. ✅ 限制日志大小
7. ✅ 启用 user namespace
8. ✅ 限制内存 / CPU
9. ✅ 关闭 inter-container 通信（按需）
10. ✅ 加密敏感数据传输

工具：Docker Bench Security（开源）

docker run --rm --net host --pid host --userns host --cap-add audit_control \
    -v /etc:/etc:ro \
    -v /var/lib:/var/lib:ro \
    docker/docker-bench-security

---

写在最后

我们整理了一份 《企业级 Docker 安全合规基线检查清单（Checklist）》：

• 含 50+ 条 CIS 关键检查
• 配套自动化扫描脚本
• 配套企业级 docker-compose 模板
• 含 Kubernetes 安全延伸

📥 免费获取 → 联系销售取清单 →

或了解我们的 企业 IT 安全方案，含 Docker / K8s / 云原生全套安全咨询。