📚 课程目录第4章准入策略框架

4. 准入策略框架：策略分层、引擎架构与执行点

镜像供应链的准入策略不能采用“一刀切”的单一规则集。不同业务场景、不同风险等级的镜像需要差异化的检查深度。本节将准入策略拆解为基础层、增强层、严格层三层模型，并阐述策略引擎的架构设计以及策略执行点的部署位置。

策略分层依据镜像的来源、用途以及数据敏感度进行划分。每一层在检查项、阻断阈值和响应方式上均有明确区别。

策略层	适用场景	核心检查项	阻断阈值	响应方式
基础层	内部开发镜像、非生产环境	签名验证、基础CVE扫描、元数据完整性	仅阻断CRITICAL漏洞	记录告警，允许通过
增强层	第三方基础镜像、预发布环境	基础层 + 依赖溯源、SBOM一致性、密钥泄露检测	阻断CRITICAL + HIGH漏洞	阻断并生成工单
严格层	生产环境、涉及PII/金融数据	增强层 + 运行时行为基线、构建溯源、合规策略	阻断所有MEDIUM及以上漏洞	阻断并触发应急响应

实践建议： 建议为每个镜像仓库（Registry）的命名空间（Namespace）绑定一个默认策略层。例如 prod/* 命名空间自动继承严格层，dev/* 命名空间使用基础层，避免人工配置遗漏。

策略引擎是准入控制的核心决策单元。它接收镜像元数据与扫描结果，根据预定义策略规则输出“通过/阻断/告警”决策。下图展示了引擎的内部组件与数据流。

  关键设计原则： 策略引擎必须保持无状态（除缓存外）和可水平扩展。每次准入决策仅依赖输入数据与策略规则，不依赖外部运行时状态，确保决策的一致性与高可用性。

策略执行点（Policy Enforcement Point, PEP）是策略引擎的“手脚”，负责在镜像供应链的关键节点拦截并执行决策。根据部署位置不同，PEP分为以下三类：

构建阶段PEP（CI Pipeline）： 集成在CI工具（如Jenkins、GitLab CI）中，在镜像构建完成后、推送至仓库前执行准入检查。阻断不合规镜像进入仓库。
仓库阶段PEP（Registry Admission）： 部署在镜像仓库（如Harbor、Docker Registry）的Webhook中，在镜像被拉取或推送时触发策略检查。适用于控制镜像分发。
运行时阶段PEP（Kubernetes Admission）： 通过Kubernetes的Admission Controller（如ValidatingWebhookConfiguration）实现，在Pod创建或更新时拦截并验证镜像是否满足准入策略。

常见误区： 仅依赖运行时阶段的K8s Admission Controller作为唯一执行点。如果镜像在构建阶段已携带严重漏洞，运行时阻断虽然能阻止Pod启动，但镜像仍存在于仓库中，可能被其他环境拉取。建议采用多层执行点叠加策略，构建阶段阻断 > 仓库阶段拦截 > 运行时兜底。

不同策略层应映射到不同的执行点组合，以实现成本与安全性的平衡。

基础层： 仅在CI Pipeline执行一次检查，仓库与运行时阶段不做额外验证。适用于开发环境，减少延迟。
增强层： CI Pipeline + Registry Webhook双重检查。CI阶段阻断明显违规，仓库阶段对已通过的镜像做二次校验，防止绕过。
严格层： CI Pipeline + Registry Webhook + K8s Admission三层全量检查。运行时阶段额外验证镜像签名是否过期、运行时基线是否合规。

落地检查清单： 在实施准入策略框架时，请确认以下三点：
1. 每个镜像仓库命名空间是否已绑定正确的策略层？
2. 策略引擎是否具备缓存能力，避免重复扫描相同镜像？
3. 三个执行点（CI/Registry/K8s）的日志是否统一汇聚到安全运营平台？