1. 课程导论：Admission Policy 在 Kubernetes 安全体系中的定位、策略即代码（Policy as Code）核心理念、资源配额模型与发布包完整性的关系
1.1 Admission Policy 在 Kubernetes 安全体系中的定位
Kubernetes 安全体系采用纵深防御（Defense in Depth）模型，从集群基础设施、网络、身份认证、授权、准入控制到运行时安全层层递进。其中，Admission Policy（准入策略） 位于 API 请求处理链的最后一个授权环节，是资源进入持久化存储（etcd）前的最后一道策略关卡。
下图展示了 Kubernetes API 请求的完整安全处理流程，突出 Admission Policy 的拦截位置：
关键定位：Admission Policy 是 Kubernetes 安全体系中的策略执行点（Policy Enforcement Point, PEP），与认证、授权共同构成 API 请求的三道防线。认证确认身份，授权判断权限，Admission Policy 校验资源内容是否符合集群级策略。
1.2 策略即代码（Policy as Code）核心理念
策略即代码（Policy as Code, PaC）是将安全策略、合规规则、资源约束等以代码形式声明、版本化管理、自动化执行的实践方法。在 Kubernetes 场景下，PaC 通过 Admission Policy 将策略从人工审核、文档约束转变为可编程、可测试、可审计的代码资产。
下表对比了传统策略管理与策略即代码的核心差异：
| 维度 | 传统策略管理 | 策略即代码 (PaC) |
|---|---|---|
| 表达形式 | 文档、PDF、邮件 | YAML/JSON/Rego 代码 |
| 版本控制 | 无或手动 | Git 仓库、CI/CD 集成 |
| 执行方式 | 人工审核、定期检查 | 自动拦截、实时校验 |
| 可测试性 | 低 | 单元测试、集成测试 |
| 审计追溯 | 困难 | 完整变更历史 |
| 变更效率 | 数天至数周 | 分钟级 |
策略即代码的核心理念可归纳为以下四个原则：
- 声明式策略定义：使用声明式语言（如 Rego、CEL）描述策略意图，而非编写命令式逻辑。
- 策略与基础设施同源：策略代码与应用代码、基础设施配置存储在同一个 Git 仓库中，遵循相同的 CI/CD 流程。
- 自动化执行与反馈：策略在 Admission 阶段自动执行，拒绝或修改不合规资源，并返回清晰错误信息。
- 持续合规审计：所有策略评估结果记录为审计日志，支持事后追溯和合规报告生成。
实践建议：在 Kubernetes 中实现 PaC 时，优先从 ValidatingAdmissionPolicy（基于 CEL 表达式）开始，它无需额外部署 Webhook 服务，降低运维复杂度。对于复杂策略场景，再引入 OPA Gatekeeper 或 Kyverno 等框架。
1.3 资源配额模型与发布包完整性的关系
资源配额模型（Resource Quota Model） 定义了 Kubernetes 集群中每个命名空间或租户可消耗的 CPU、内存、存储、对象数量等资源上限。而发布包完整性（Release Package Integrity） 则关注部署到集群中的容器镜像、Helm Chart、YAML 清单等制品是否被篡改、是否来自可信源、是否符合安全基线。
两者在 Admission Policy 层面形成双重校验关系：
- 资源配额模型：确保资源使用不超限，防止单个应用耗尽集群资源导致拒绝服务。
- 发布包完整性：确保部署的制品未被篡改，防止恶意代码或配置注入。
下图展示了资源配额模型与发布包完整性在 Admission Policy 中的协同校验流程：
常见误区：部分团队仅关注资源配额模型而忽略发布包完整性校验，导致集群虽未超限，但运行了包含已知漏洞或恶意代码的镜像。反之，仅校验完整性而不设资源配额，可能导致单个应用抢占所有集群资源。两者必须组合使用才能形成完整的安全基线。