Docker 容器安全加固的价值，不只是“少几个漏洞”，而是帮助团队把镜像来源、运行权限、网络边界和持续监控都纳入同一套可验证流程。很多开发者习惯直接 docker pull 官方镜像就用于生产环境，殊不知即使是官方镜像也可能包含已知漏洞。本文会用可执行命令和配置示例说明如何从镜像扫描、构建规范、运行时防护到网络隔离逐层收紧风险，适合正在把业务部署到容器环境的开发者、站长和运维团队。
容器安全的威胁模型：你在防什么？
容器安全的威胁主要来自三个层面：
- 镜像层：基础镜像包含已知CVE（公共漏洞和暴露）漏洞、恶意软件包、硬编码的密钥或凭据。
- 运行时层：容器以root权限运行、挂载了宿主机敏感目录、资源未限制导致DoS攻击。
- 网络层：容器间网络未隔离、暴露了不必要的端口、未加密的服务间通信。
理解这三个层面后，安全加固的思路就清晰了：在每个层面建立防线，遵循最小权限原则。
第一步：镜像安全——从源头把关
1.1 使用可信的基础镜像
优先选择官方镜像或知名维护者的镜像。Docker Hub上的「Official Image」标签虽然不是绝对安全的保证，但至少经过了Docker团队的审核。避免使用来源不明的第三方镜像，尤其是那些星标数很少、长期未更新的镜像。
对于生产环境，推荐使用最小化基础镜像，并把镜像变更记录在构建说明中。如果镜像用于网站 API、后台任务或服务器运维场景，每次升级基础镜像后都应重新执行扫描，避免“开发环境已修复、生产镜像仍带旧漏洞”的断层。
FROM node:20-alpine FROM gcr.io/distroless/nodejs20
Alpine Linux的镜像体积约为5MB，相比Ubuntu的77MB，不仅体积小，攻击面也更小——系统中安装的软件包越少，潜在漏洞就越少。
1.2 镜像漏洞扫描
在构建和部署流程中集成镜像扫描工具，可以在漏洞进入生产环境之前将其拦截。常用的免费扫描工具包括：
- Trivy：Aqua Security开源的扫描器，支持扫描镜像、文件系统和Git仓库，检测OS包和语言依赖中的已知漏洞。
- Scout：Docker官方提供的镜像扫描服务，集成在Docker Desktop和Docker Hub中。
- Grype：Anchore开源的漏洞扫描器，与Syft（SBOM生成工具）配合使用效果更好。
以Trivy为例，在CI/CD流水线中添加扫描步骤。团队可以先把门槛设为 HIGH,CRITICAL，再根据业务节奏逐步纳入 MEDIUM 级别；如果你同时关注站点响应速度，也可以把镜像体积变化和TTFB 优化一起纳入发布前检查。
安装 Trivy 后，可以只针对高危和严重漏洞扫描镜像；如果命中严重漏洞，扫描命令会返回非零退出码，CI 流水线可以据此中断发布。
curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh trivy image --severity HIGH,CRITICAL your-image:tag
第二步：构建安全的镜像
Dockerfile的写法直接影响镜像的安全性。以下是关键的构建规范：
下面的 Dockerfile 片段演示了多阶段构建、非 root 用户、必要端口和固定入口命令四个约束点。
FROM node:20-alpine AS builder WORKDIR /app COPY package*.json ./ RUN npm ci --production COPY . . RUN npm run build FROM node:20-alpine WORKDIR /app COPY --from=builder /app/dist ./dist COPY --from=builder /app/node_modules ./node_modules RUN addgroup -S appgroup && adduser -S appuser -G appgroup USER appuser EXPOSE 3000 ENTRYPOINT ["node", "dist/server.js"]
另一个常见问题是硬编码密钥。永远不要在Dockerfile中写入数据库密码、API密钥等敏感信息——这些会被固化在镜像层中，即使后续删除文件，通过 docker history 或导出镜像层仍然可以看到。正确做法是通过环境变量或Docker Secrets在运行时注入。
第三步：运行时安全防护
3.1 最小权限运行
容器默认以root用户运行，这意味着如果攻击者突破了容器边界，就直接获得了宿主机的root权限。除了在Dockerfile中指定 USER 指令外，还可以在运行时进一步限制：
docker run \ --read-only \ # 只读文件系统 --tmpfs /tmp \ # 可写临时目录 --cap-drop ALL \ # 丢弃所有Linux能力 --cap-add NET_BIND_SERVICE \ # 只添加绑定低端口的能力 --security-opt no-new-privileges \ # 禁止提权 --memory 512m \ # 限制内存 --cpus 1 \ # 限制CPU your-image:tag
3.2 资源限制与健康检查
不限制资源的容器可能消耗宿主机全部内存或CPU，导致其他服务不可用（DoS效果）。Docker Compose中可以这样配置：
services:
web:
image: your-image:tag
deploy:
resources:
limits:
memory: 512M
cpus: '1.0'
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:3000/health"]
interval: 30s
timeout: 5s
retries: 3
第四步：网络隔离
Docker默认创建一个桥接网络，所有容器都在同一个网络中，可以互相通信。在生产环境中，应该为不同的服务创建独立的网络，只允许必要的通信路径：
services:
web:
networks:
- frontend
- backend
db:
networks:
- backend # 数据库只能被后端访问，不能被前端直接访问
networks:
frontend:
backend:
internal: true # 不允许外部访问
此外，不要使用 --privileged 模式运行容器——这个模式会赋予容器几乎所有宿主机权限，等于把安全防线完全撤除。除非你确实需要访问宿主机硬件设备，否则永远不要用这个参数。
持续安全监控
安全加固不是一次性的操作。建议定期重新扫描已部署的镜像（新漏洞每天都在被发现），启用Docker daemon的审计日志，监控容器的异常行为（如异常的网络连接或进程创建）。如果你使用托管的容器编排平台（如Kubernetes），还可以利用Pod Security Standards（Pod安全标准）在集群层面强制执行安全策略。
实践中可以把持续监控拆成三个固定动作：每周重新扫描生产镜像，每次发布后保留镜像摘要和SBOM（软件物料清单），每月抽查一次容器运行参数。比如通过 docker inspect 检查 ReadonlyRootfs、CapDrop、Privileged 等字段，再用 docker stats 观察CPU和内存是否长期接近上限。对于承载外贸网站、API服务或后台任务的环境，这类例行检查能比“出问题后再排查”更早暴露配置漂移。
下面两条命令分别用于检查容器是否启用只读文件系统、是否误开 privileged，以及查看当前资源占用。
docker inspect app-container \
--format 'Readonly={{.HostConfig.ReadonlyRootfs}} Privileged={{.HostConfig.Privileged}} CapDrop={{.HostConfig.CapDrop}}'
docker stats --no-stream app-container
如果容器承载对外业务，还需要把宿主机基础设施一起纳入安全范围。例如运行在VPS（虚拟专用服务器）上的容器，建议同时配置快照、备份、防火墙规则和登录审计；如果服务对CPU、磁盘I/O或隔离性要求更高，可以评估独立服务器是否更适合。Hostease 提供 [VPS](https://cn.hostease.com/vps/) 与[独立服务器](https://cn.hostease.com/dedicated-server/)方案，但具体选择仍应以业务负载、预算和运维能力为准。容器不是安全边界的全部，它只是应用交付链路中的一层。
总结来看，Docker 容器安全加固可以按“镜像先扫描、构建少依赖、运行降权限、网络做隔离、监控可追踪”这五步推进。建议从一两个高风险服务开始落地：先加 trivy image --severity HIGH,CRITICAL 扫描，再把 USER、--cap-drop ALL、--read-only 和资源限制纳入部署模板。等模板稳定后，再推广到更多项目，安全收益会比临时修改单个容器更持久。