镜像安全基础：容器镜像概念、镜像分层原理、requests镜像的获取与验证
1. 容器镜像概念
容器镜像是容器化应用的标准交付物，它是一个轻量级、可执行的独立软件包，包含运行应用所需的一切：代码、运行时、系统工具、系统库和设置。在 requests 镜像供应链安全 场景中，镜像既是依赖的载体，也是攻击面之一。
| 概念 | 说明 | 安全关注点 |
|---|---|---|
| 镜像（Image） | 只读模板，用于创建容器 | 镜像来源是否可信、是否被篡改 |
| 容器（Container） | 镜像的运行实例，可读写 | 运行时权限、资源隔离 |
| 仓库（Registry） | 存储和分发镜像的集中地 | 仓库访问控制、镜像签名验证 |
| 标签（Tag） | 镜像的版本标识 | 避免使用 latest，锁定摘要 |
安全基线： 所有生产环境使用的 requests 镜像必须来自受控仓库，且具备数字签名或摘要锁定，禁止直接拉取未验证的公共镜像。
2. 镜像分层原理
Docker 镜像采用 分层（Layer） 结构，每一层代表一组文件系统变更。分层机制的核心优势是复用和增量传输，但也引入了供应链安全风险——每一层都可能被植入恶意文件或漏洞。
分层结构（从下到上）：
- 基础层（Base Layer）： 操作系统发行版（如 Ubuntu、Alpine）
- 依赖层（Dependency Layer）： Python 运行时、pip 包
- 应用层（Application Layer）： requests 库、业务代码
- 配置层（Config Layer）： 环境变量、入口命令
供应链风险提示： 攻击者可能向基础层或依赖层注入恶意包。例如，在 pip 安装阶段替换 requests 为同名恶意包。必须对每一层进行漏洞扫描和完整性校验。
3. requests 镜像的获取与验证
获取 requests 镜像通常有两种方式：从公共仓库拉取 和 基于 Dockerfile 构建。验证环节是供应链安全的第一道防线。
3.1 获取方式对比
| 方式 | 命令/操作 | 安全风险 | 推荐场景 |
|---|---|---|---|
| 公共仓库拉取 | docker pull python:3.11-slim |
镜像可能被篡改、包含恶意层 | 开发测试环境（需验证摘要） |
| 自建 Dockerfile | FROM python:3.11-slim |
基础镜像漏洞、依赖包投毒 | 生产环境（推荐） |
| 私有仓库同步 | docker pull registry.internal/requests-app:v1 |
仓库访问凭证泄露 | 企业合规环境 |
3.2 镜像验证四步法
- 摘要验证（Digest）： 使用
docker images --digests获取镜像的 SHA256 摘要，与官方或受控源比对。 - 签名验证（Notation / Cosign）： 验证镜像是否由可信发布者签名，防止中间人攻击。
- 漏洞扫描（Trivy / Grype）： 扫描镜像各层中的已知 CVE 漏洞，重点关注 requests 依赖链。
- 内容校验（Dive / Skopeo）： 检查镜像层文件变更，确认无异常文件或后门。
# 示例：获取并验证 requests 镜像
# 1. 拉取指定摘要的镜像
docker pull python:3.11-slim@sha256:abc123...
# 2. 查看镜像摘要
docker images --digests | grep python
# 3. 使用 Cosign 验证签名（需镜像已签名）
cosign verify registry.internal/requests-app:v1 \
--certificate-identity user@example.com \
--certificate-oidc-issuer https://accounts.example.com
# 4. 漏洞扫描
trivy image python:3.11-slim --severity HIGH,CRITICAL
最佳实践： 在 CI/CD 流水线中集成
trivy 和 cosign，对每次构建的 requests 镜像自动执行验证四步法，阻断不合规镜像进入仓库。