📚 课程目录第2章容器运行时安全基础

2. 容器镜像基础：镜像分层原理、Dockerfile最佳安全实践、镜像构建与仓库管理

2.1 镜像分层原理与存储驱动

容器镜像并非一个单体二进制文件，而是由一系列只读层（Layer）堆叠而成的联合文件系统。每一层对应 Dockerfile 中的一条指令，层与层之间通过写时复制（Copy-on-Write, CoW）机制实现高效存储与分发。

  核心概念：镜像层是只读的，容器运行时在顶层添加一个可写层。所有对文件的修改（新增、删除、修改）都发生在该可写层，底层镜像层保持不变。这保证了多个容器可以共享同一基础镜像，节省磁盘与网络带宽。

2.2 Dockerfile 最佳安全实践

Dockerfile 是镜像构建的蓝图，其质量直接决定镜像的安全性与可维护性。以下实践基于生产环境经验总结，涵盖最小权限、减少攻击面、层优化与凭证管理。

实践类别	推荐做法	安全收益
基础镜像	使用官方签名镜像，指定完整版本标签（如 `alpine:3.19`），避免 `latest`	防止版本漂移与恶意篡改，确保可复现构建
用户权限	在 Dockerfile 中创建非 root 用户，使用 `USER` 指令切换	限制容器逃逸后的攻击面，遵循最小权限原则
层数控制	合并 `RUN` 指令，清理临时文件（如 `apt-get clean`）	减少镜像层数，降低历史层中残留敏感数据的风险
凭证管理	使用 `--secret` 构建参数或 Docker BuildKit，禁止在 `ENV`/`ARG` 中硬编码密钥	防止密钥被持久化到镜像层，避免泄露
文件权限	显式设置 `COPY --chown`，避免使用 `chmod 777`	防止容器内敏感文件被任意进程读取或修改
软件源	使用可信镜像源，定期扫描基础镜像 CVE	降低供应链攻击风险

⚠️ 常见陷阱：许多团队在 Dockerfile 中使用 ADD 指令从 URL 下载文件。这会引入不可控的中间人攻击风险，且下载的文件会永久保存在镜像层中。优先使用 curl 或 wget 配合 RUN 指令，并在同一条指令中完成下载、校验与清理。

安全 Dockerfile 示例

# 使用指定版本的基础镜像
FROM alpine:3.19 AS builder

# 安装构建依赖，合并 RUN 指令并清理缓存
RUN apk add --no-cache curl build-base \
    && curl -fsSL https://example.com/app.tar.gz -o /tmp/app.tar.gz \
    && tar -xzf /tmp/app.tar.gz -C /opt \
    && rm -f /tmp/app.tar.gz

# 最终阶段：使用更小的运行时镜像
FROM alpine:3.19

# 创建非 root 用户
RUN addgroup -S appgroup && adduser -S appuser -G appgroup

# 从构建阶段复制产物，并设置属主
COPY --from=builder --chown=appuser:appgroup /opt/app /app

# 切换用户
USER appuser

# 暴露端口与启动命令
EXPOSE 8080
CMD ["/app/entrypoint.sh"]

2.3 镜像构建与仓库管理

镜像构建不仅仅是执行 docker build，还涉及构建上下文安全、多阶段构建优化、镜像签名与仓库访问控制。在 Kubernetes 环境中，镜像仓库是供应链攻击的高发区。

2.3.1 多阶段构建（Multi-stage Build）

多阶段构建允许在同一个 Dockerfile 中使用多个 FROM 指令，将构建环境与运行环境分离。最终镜像只包含运行时所需的二进制文件和依赖，大幅减小体积并消除构建工具中的潜在漏洞。

2.3.2 镜像仓库安全策略

镜像仓库（如 Harbor、Docker Hub、Amazon ECR）是镜像生命周期的核心存储与分发节点。以下策略可有效防范镜像篡改与未授权访问：

镜像签名与验证：使用 cosign 或 Notary 对镜像进行数字签名，在 Kubernetes 准入控制器中强制验证签名，拒绝未签名或签名无效的镜像。
访问控制（RBAC）：为不同团队分配独立的仓库项目，使用基于角色的访问控制限制推送（push）与拉取（pull）权限。
漏洞扫描：集成 Trivy、Clair 或 Grype 等扫描器，在镜像推送时自动扫描，阻止包含高危 CVE 的镜像进入生产环境。
不可变标签：禁止覆盖已有标签（如 latest），强制使用语义化版本标签（如 v1.2.3），确保镜像可追溯。
仓库间复制：使用仓库复制功能（如 Harbor 的 P2P 复制）将镜像同步到灾备或边缘站点，避免单点故障。

💡 生产建议：在 Kubernetes 集群中，结合 ImagePolicyWebhook 或 OPA/Gatekeeper 实现镜像来源白名单。例如，只允许从内部 Harbor 仓库拉取镜像，拒绝所有来自公共仓库的镜像，从而降低供应链攻击风险。

2.3.3 构建上下文安全

docker build 命令会将构建上下文（通常是一个目录）发送给 Docker 守护进程。如果上下文中包含 .env、id_rsa、kubeconfig 等敏感文件，它们会被打包进镜像层，即使后续被 .dockerignore 排除，也可能在构建缓存中留下痕迹。

风险场景	后果	解决方案
构建上下文中包含 `.git` 目录	泄露 Git 历史、提交记录、远程仓库地址	在 `.dockerignore` 中添加 `.git`
使用 `ADD` 指令添加本地压缩包	压缩包内可能包含隐藏的敏感文件	解压后显式 `COPY` 所需文件
构建时挂载宿主机 SSH 代理	容器内进程可访问宿主机 SSH 密钥	使用 BuildKit 的 `--ssh` 功能，限制访问范围

# 推荐 .dockerignore 示例
.git
.gitignore
*.md
.env
.env.*
node_modules/
__pycache__/
*.log
secrets/