1. 课程导论：什么是策略即代码（Policy as Code）？为什么需要准入门禁？OPA（Open Policy Agent）在云原生中的角色
1.1 策略即代码（Policy as Code）的定义与价值
策略即代码（Policy as Code, PaC）是将传统安全策略、合规规则与治理约束，以机器可读的代码形式进行声明、版本化管理、自动化执行与持续审计的工程实践。它打破了以往策略散落在 Wiki 文档、邮件审批或人工检查中的“黑盒”状态，使策略成为软件交付生命周期中的一等公民。
| 维度 | 传统策略管理 | 策略即代码（PaC） |
|---|---|---|
| 表达形式 | 自然语言文档、PDF、邮件 | 声明式代码（Rego、JSON、YAML） |
| 版本控制 | 无或手动归档 | Git 仓库 + CI/CD 流水线 |
| 执行时机 | 人工审核、事后检查 | 实时准入、预提交、持续审计 |
| 可测试性 | 低，依赖人工判断 | 高，支持单元测试与模拟验证 |
| 变更影响 | 难以追溯，容易遗漏 | 可审计、可回滚、可追溯 |
核心收益： 策略即代码将安全左移，使合规检查从“门卫”变为“嵌入式护栏”，在部署前即可发现违规配置，降低生产事故与合规风险。
1.2 为什么需要准入门禁？
在云原生环境中，Kubernetes 集群每天可能接收数百次资源创建、更新请求。如果没有准入门禁（Admission Gate），任何具备 API 访问权限的实体都可以直接部署特权容器、挂载宿主机敏感路径或使用不安全的镜像。准入门禁是集群安全的“第一道防线”，在请求持久化到 etcd 之前进行拦截与校验。
- 防止配置漂移： 确保所有资源符合组织基线，例如禁止
privileged: true、强制设置readOnlyRootFilesystem。 - 合规强制： 自动执行 PCI-DSS、SOC2、GDPR 等合规要求，例如限制命名空间标签、强制资源配额。
- 降低攻击面： 阻断高危镜像（如 latest 标签）、限制 hostNetwork 与 hostPID 的使用。
- 审计与可观测： 记录每一次准入决策，为事后取证与策略调优提供数据基础。
关键认知： 准入门禁不是“可选项”，而是生产集群的“必选项”。CNCF 安全基准（NSA/Kubernetes Hardening Guide）明确建议启用至少一种准入控制器。
1.3 OPA（Open Policy Agent）在云原生中的角色
OPA（Open Policy Agent）是一个开源的、通用的策略引擎，由 CNCF 毕业项目维护。它通过统一的声明式语言 Rego 将策略从具体服务中解耦，实现策略决策与策略执行的分离。在云原生生态中，OPA 通常以 OPA Gatekeeper（Kubernetes 准入控制器）的形式部署，扮演“策略裁判”的角色。
OPA 在云原生中的核心职责可归纳为以下三点：
- 策略决策点（Policy Decision Point, PDP）： 接收来自 API Server 的 AdmissionReview 请求，基于 Rego 策略返回允许（allow）或拒绝（deny）决策。
- 策略与执行分离： 开发团队维护 Rego 策略，平台团队维护 OPA 引擎，互不耦合，策略变更无需重启集群组件。
- 生态集成： 除 Kubernetes 外，OPA 还可集成 Terraform、Envoy、Docker、Kafka 等，实现跨栈统一策略治理。
常见误区： OPA 本身不是准入控制器，而是策略引擎。在 Kubernetes 中，需要配合 OPA Gatekeeper 或 Kube-mgmt 将 OPA 注册为
ValidatingAdmissionWebhook 或 MutatingAdmissionWebhook 才能生效。
1.4 策略即代码 + 准入门禁 + OPA：三位一体的安全护栏
将策略即代码的工程化能力、准入门禁的拦截机制与 OPA 的策略引擎相结合，形成云原生环境下的“声明式安全护栏”。下图展示了三者之间的协作关系：
通过本课程，你将掌握如何编写 Rego 策略、配置 OPA Gatekeeper 约束模板、设计升级窗口的准入门禁规则，并最终实现一个完整的“策略即代码升级窗口演练”项目。