1. 课程导论：镜像供应链信任边界的概念、为什么需要信任边界、课程目标与学习路径
1.1 镜像供应链信任边界的概念
在云原生与容器化部署日益普及的今天，软件交付的核心载体已从传统的二进制包转变为容器镜像。一个镜像从代码提交、构建、存储、分发到最终部署运行，会经历多个环节，形成一条完整的镜像供应链。信任边界（Trust Boundary）是指在该供应链中，数据、元数据或镜像本身从一个受控、可信的环境流向另一个环境时，所跨越的安全分界点。
信任边界并非物理防火墙，而是逻辑上的安全假设切换点。在边界内部，我们默认实体（如构建系统、镜像仓库）是可信的；一旦跨越边界，就必须重新验证镜像的完整性与来源的合法性。镜像供应链中的典型信任边界包括：
- 开发环境 → 构建系统：代码与 Dockerfile 从开发者本地提交至 CI/CD 系统。
- 构建系统 → 镜像仓库：构建完成的镜像被推送至私有或公有 Registry。
- 镜像仓库 → 部署环境：Kubernetes 集群或生产服务器从仓库拉取镜像并运行。
- 基础镜像 → 应用镜像：应用镜像依赖的上游基础镜像（如 Alpine、Ubuntu）的来源可信度。
关键定义： 镜像供应链信任边界是镜像在流转过程中，安全策略、验证机制和信任假设发生变化的逻辑分界线。每一条边界都是潜在的攻击面。
1.2 为什么需要信任边界
没有明确的信任边界，镜像供应链将面临以下严重风险：
| 风险类别 | 具体威胁 | 后果 |
|---|---|---|
| 镜像投毒 | 攻击者向公共仓库上传包含恶意代码的镜像，或篡改私有仓库中的镜像层 | 容器运行时执行恶意指令，数据泄露或挖矿 |
| 依赖混淆 | 利用内部包名在公共仓库上传同名恶意基础镜像，被构建系统自动拉取 | 供应链污染，所有下游镜像均受影响 |
| 构建劫持 | CI/CD 管道被入侵，在构建过程中注入后门 | 镜像在构建阶段即被植入恶意代码 |
| 部署篡改 | 镜像在传输过程中被中间人替换，或仓库凭证泄露导致镜像被替换 | 生产环境运行非预期镜像 |
通过定义信任边界，团队可以：
- 明确安全责任域：每个边界两侧的团队清楚自己的安全职责。
- 实施分级验证：在关键边界部署签名验证、漏洞扫描、准入控制等机制。
- 缩小攻击面：将信任最小化，默认不信任任何跨越边界的镜像或元数据。
- 实现可审计性：每条边界上的验证动作均可记录，形成完整的供应链溯源链。
常见误区： 很多团队认为“只要使用私有仓库就安全了”。实际上，私有仓库只是信任边界的一部分，如果构建系统到仓库之间没有签名验证，仓库内部镜像仍可能被篡改或误用。
1.3 镜像供应链信任边界全景图
下图展示了镜像从开发到部署的完整流转路径，以及其中关键的信任边界节点：
1.4 课程目标
本课程旨在帮助学员建立完整的镜像供应链信任边界防护体系，具体目标如下：
| 目标维度 | 具体内容 | 交付成果 |
|---|---|---|
| 理论认知 | 理解镜像供应链的组成、信任边界模型、威胁模型 | 信任边界全景图与风险清单 |
| 工具实践 | 掌握 Cosign / Notary / Sigstore 签名工具链、Kyverno / OPA 准入控制、Trivy / Grype 漏洞扫描 | 可运行的 CI/CD 集成流水线 |
| 架构设计 | 设计多层信任边界策略：构建签名、仓库验证、部署准入 | 信任边界架构设计文档 |
| 应急响应 | 建立镜像供应链异常检测与溯源机制 | 事件响应剧本与溯源看板 |
1.5 学习路径与章节结构
课程共分为 30 章，按以下路径循序渐进：
1.6 学习建议与前置要求
学习建议： 建议学员按照章节顺序学习，每章结束后完成对应的实验练习。第 6-15 章的工具实践部分需要具备基本的 Docker 和 Kubernetes 操作能力。第 24-30 章的实战案例建议在独立的测试集群中操作，避免影响生产环境。
前置知识要求：
- 熟悉 Docker 镜像构建与推送基本命令。
- 了解 Kubernetes 基本概念（Pod、Deployment、Namespace）。
- 具备基本的 Linux 命令行操作能力。
- 了解 CI/CD 流水线的基本流程（如 GitLab CI、GitHub Actions）。
实验环境要求：
- 一台可运行 Docker 的 Linux 主机（推荐 Ubuntu 22.04+）。
- 一个 Kubernetes 集群（可使用 Minikube 或 Kind 本地搭建）。
- 一个私有镜像仓库（Harbor 或 Docker Registry）。
- Git 仓库与 CI/CD 平台（GitLab / GitHub / Jenkins 任选其一）。