使用 Docker Compose + Ubuntu 的安全部署
在硅谷的创业公司中，Docker Compose 是快速部署和管理容器化应用的首选工具之一。然而，便利往往伴随安全风险。作为站点可靠性工程师（SRE），我深知安全漏洞可能导致灾难性后果。本文将分享我在实际工作中结合 Docker Compose 与 Ubuntu 系统总结的最佳安全实践，帮助你在享受 Docker Compose 便利的同时，确保系统安全。
I. 加固 Ubuntu 系统安全
在部署容器之前，确保 Ubuntu 主机本身的安全至关重要。以下是关键步骤：
1. 定期更新 Ubuntu 和 Docker
确保系统和 Docker 均保持最新，以修复已知漏洞：
sudo apt update && sudo apt upgrade -y
sudo apt install docker-ce docker-compose-plugin
2. 限制 Docker 管理权限
严格控制 Docker 管理权限，防止特权提升攻击：
sudo usermod -aG docker deployuser
# 防止普通用户轻易获取 Docker 管理权限
3. 配置 Ubuntu 防火墙 (UFW)
合理限制网络访问，防止未授权访问：
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose
4. 正确配置 Docker 与 UFW 的交互
默认情况下，Docker 会绕过 UFW 直接配置 iptables，建议手动控制：
修改 Docker 配置文件：
sudo nano /etc/docker/daemon.json
添加以下内容：
{
"iptables": false,
"ip-forward": true,
"userland-proxy": false
}
重启 Docker 服务：
sudo systemctl restart docker
在 Docker Compose 中显式绑定地址：
services:
webapp:
ports:
- "127.0.0.1:8080:8080"
II. Docker Compose 安全最佳实践
以下配置适用于 Docker Compose v2.4 及以上。请注意非 Swarm 与 Swarm 模式的差异。
1. 限制容器权限
容器默认以 root 运行风险极高，建议切换为非 root 用户：
services:
app:
image: your-app:v1.2.3
user: "1000:1000" # 非 root 用户
read_only: true # 只读文件系统
volumes:
- /tmp/app:/tmp # 如需写入，仅挂载必要目录
cap_drop:
- ALL
cap_add:
- NET_BIND_SERVICE
说明：
- 只读文件系统可防止容器内部被篡改。
- 确保挂载卷仅限必要目录。
2. 网络隔离与端口管理
精准划分内部 网络与外部网络，避免将敏感服务暴露给公网：
networks:
frontend:
internal: false
backend:
internal: true
services:
nginx:
networks: [frontend, backend]
database:
networks:
- backend
- 前端网络：可对外开放。
- 后端网络：严格受限，仅内部通信。
3. 安全的 Secrets 管理
敏感数据绝不能直接写入 Compose 文件：
单机模式：
services:
webapp:
environment:
- DB_PASSWORD_FILE=/run/secrets/db_password
volumes:
- ./secrets/db_password.txt:/run/secrets/db_password:ro
Swarm 模式：
services:
webapp:
secrets:
- db_password
environment:
DB_PASSWORD_FILE: /run/secrets/db_password
secrets:
db_password:
external: true # 通过 Swarm 内置管理
注意：
- Docker 原生 Swarm Secrets 不能直接使用 Vault、AWS Secrets Manager 等外部工具。
- 如需外部密钥存储，请自行集成读取流程。
4. 资源限制（根据 Docker Compose 版本适配）
容器资源限制可防止单个容器耗尽主机资源。
Docker Compose 单机模式（推荐 v2.4）：
version: '2.4'
services:
api:
image: your-image:1.4.0
mem_limit: 512m
cpus: 0.5
Docker Compose Swarm 模式（v3 及以上）：
services:
api:
deploy:
resources:
limits:
cpus: "0.5"
memory: 512M
reservations:
cpus: "0.25"
memory: 256M
注意：在非 Swarm 环境下，
deploy部分的资源限制 不会生效，请务必关注 Compose 文件的版本。
5. 容器健康检查
配置健康检查可主动发现问题，降低服务停机时间：
services:
webapp:
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost/health"]
interval: 30s
timeout: 10s
retries: 3
start_period: 20s
6. 避免使用 latest 标签
生产环境中请避免使用 latest 标签的不确定性，强制指定镜像版本：
services:
api:
image: your-image:1.4.0
7. 合理的日志管理
防止容器日志耗尽磁盘空间：
services:
web:
logging:
driver: "json-file"
options:
max-size: "10m"
max-file: "5"
8. Ubuntu AppArmor 配置
Ubuntu 默认启用 AppArmor，建议检查 Docker 的 profile 状态：
sudo systemctl enable --now apparmor
sudo aa-status
Ubuntu 上的 Docker 默认开启 AppArmor，无需额外配置。一般不建议在 Ubuntu 上同时启用 SELinux，以免产生冲突。
9. 持续更新与安全扫描
- 镜像漏洞扫描：建议在 CI/CD 流程中集成 Trivy、Clair 或 Snyk 等工具：
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \
aquasec/trivy image your-image:v1.2.3
- 自动化安全更 新流程：至少每周重新构建镜像，以修复已知漏洞。
III. 案例研究：Docker Compose 配置失误的教训
2019 年 7 月，Capital One 发生重大数据泄露，影响超过 1 亿客户的个人信息12。虽然攻击的主要原因是 AWS 配置错误，但也涉及与本案例相似的容器安全问题：
- 容器权限问题：攻击者利用运行在容器中的 Web 应用防火墙（WAF）漏洞，且该容器拥有过高权限。
- 网络隔离不足：攻击者能够从被攻陷的容器访问其他 AWS 资源，说明网络隔离措施不到位。
- 敏感数据泄露：配置错误导致攻击者获取并窃取大量敏感客户数据。
- 安全配置失误：整个事件的根本原因是多项安全配置错误的叠加，包括容器和云服务的配置失误。
此次事件给 Capital One 带来了巨额经济损失和声誉受损。据报道，公司因该事件被罚款最高达 1.5 亿美元，并陷入长期信任危机。该案例凸显了容器与云环境中安全配置的重要性，尤其是在权限管理、网络隔离和敏感数据保护方面。它提醒我们，即使是看似微小的配置错误，也可能被攻击者利用，导致灾难性后果。
IV. 结论与建议
Docker Compose 与 Ubuntu 的组合能够快速部署容器化应用，但安全必须贯穿整个流程：
- 严格控制容器权限与网络隔离。
- 防止敏感数据泄露。
- 定期进行安全扫描与更新。
- 随着企业规模扩大，建议迁移至 Kubernetes 等更高级的编排系统，以获得更强的安全保障。
安全是一项持续的实践，没有终点。希望本文能帮助你更好地保护 Docker Compose + Ubuntu 部署环境。
