Policy as Code

1）什么被认为是"政治"

• 访问/授权：RBAC/ABAC，ReBAC，数据导出，步骤（MFA）。
• 基础架构安全：Kubernetes管理控制、映像/秘密策略、网络规则。
• 合规和隐私：同意管理，PII标记，本地报告日，地理限制。
• 配置和质量："禁令：最新"、资源限制、强制性资源标签（云）。
• 数据和ML：禁止未经同意的工具包培训，k匿名，DP预算，数据线性不变式。

2） PaC架构模型

PAP（策略管理点）：存储库和管理过程（MR/PR, review,版本）。
PDP（策略决策点）：计算策略解决方桉的引擎（OPA, Cedar engine,本机解释器）。
PEP （Policy Enforcement Point）：应用点（API网关、webhook-admission in K8s、ETL变压器、SDK）。
PIP （Policy Information Point）：属性/事实来源：IdP、资源目录、数据仓库、风险漏洞。
决策记录/审核：不变的解决方桉日志（用于事件分析和合规性）。

流：请求→ PEP形成上下文→ PDP加载事实（PIP）→计算解决方案→ PEP应用（allow/deny/修订版）→逻辑/度量。

3）工具和域

OPA/Rego是用于声明性策略的通用引擎和语言（K8s中为webhook-admission：Gatekeeper，CI-Conftest，API-sidecar/Service）。
Kyverno是YAML中Kubernetes的声明性政策，补丁/验证/生成。
Cedar（AWS/可携带）是政治语言，重点是授权"某人做某事"。
Cloud IAM（AWS/GCP/Azure）是云资源策略（最好通过静态和IaC计划检查PaC）。
Custom是JSON/SQL之上针对特定对象（例如ML合规性）的DSL/规则。

4）政策生命周期

1.目标和域定义："禁止装载具有高/严重漏洞的容器"。
2.代码形式化：Rego/Cedar/YAML。
3.测试：真实性表，负案例，基于属性的案例。
4.CI验证：linter, unit,集成在虚构的清单/查询。
5.发布和分发：发布到捆绑包,签名,交付到PDP/edge。
6.监测：命中率，latency p95/p99，deny份额，dashbord漂移。
7.例外/要求：时间限制/范围限制,有审核和所有者。
8.重构和归档：版本，兼容性，迁移。

5）存储和分发

Repo-layout: `policies//.rego|cedar|yaml`, `tests/`, `bundles/`, `schemas/`.

Version： semver和"policy_version"在PDP响应中。
捆绑包：已签名的压缩策略包+电路+configs（供应链安全）。
分布：pull （PDP从registry/S3中拉出）或push（控制器发出）。
分区评估：预测策略以在周边快速执行。

6）数据模型和电路

单一上下文合同："主题"，"资源"，"行动"，"env"，"法律"。
JSON-Schema/Protobuf：验证事实模型；电路不匹配是"indeterminate → deny"的原因。

属性归一化： 统一标题（例如"tenant_id"，"risk_level"，"pii_tags"，"image"。vulns`).

7）性能和可靠性

解决方案缓存：键"（subject_hash，resource_key，行动，policy_version）"；短的TTL，事件障碍（角色/标签更改）。
本地事实：不要在热路上拉重型PIP-同步狙击。
失败开放vs失败关闭：关键域的安全性-失败关闭；对于UX临界值-降级（编辑而不是deny）。
潜伏预算：PDP内存解决方案的目标"<3-10 ms"，PIP的"<30-50 ms"。

8）例外管理（waivers）

时间限制（例如7天），强制所有者和原因。
抢购：按资源/proects/neimspeis；禁止全球"永远"。
审核和提醒：报告即将到期的Waiver'am,自动挖掘/升级。

9）度量与可观察性

Policy Coverage： PaC保护的路径/端点比例。

Decision Latency / QPS / Error rate.

Deny Rate和False Positive/Negative（通过"dry-run/shadow"模式）。
漂移：在SDK和服务器解决方桉之间,计划（IaC）与事实（live）之间存在差异。

Аудит: `decision_id, policy_ids, version, attributes_digest, effect, reason`.

10）反模式

"缝合"到没有版本和测试的代码中的策略。
缺乏方案/上下文验证→不可预测的解决方案。

单个整体文件"mega。rego».

没有例外过程→"手动绕行"和混乱。
仅在CI（后期故障）中不使用"shift-left"的runtime应用。
策略中隐藏的副作用（策略必须是纯函数）。

11）示例

11.1 Rego （OPA）：禁止K8s中易受攻击的图像

rego package k8s. admission. vulns

deny[msg] {
input. kind. kind == "Pod"
some c img:= input. request. object. spec. containers[c].image vulns:= data. registry. scan [img] # actual-snapshot from PIP count ({v     v:= vulns[_]; v.severity == "CRITICAL"}) > 0 msg:= sprintf("image %s has CRITICAL vulns", [img])
}

11.2 Rego：仅从MFA和"白色"IP导出数据

rego package api. export

default allow = false

allow {
input. action == "export"
input. subject. mfa_verified == true net. cidr_contains("203. 0. 113. 0/24", input. env. ip)
}

11.3 Cedar：只读所有者或团队成员

cedar permit(
principal in Group::"team_members",
action in [Action::"read"],
resource in Photo::"")
when { resource. owner == principal          resource. team_id in principal. team_ids };

11.4 Kyverno （YAML）：禁止'：latest'和'。资源

yaml apiVersion: kyverno. io/v1 kind: ClusterPolicy metadata:
name: disallow-latest-and-require-limits spec:
validationFailureAction: Enforce rules:
- name: disallow-latest match: { resources: { kinds: ["Pod"] } }
validate:
message: "Image tag 'latest' is not allowed."
pattern:
spec:
containers:
- name: ""
image: "!:latest"
- name: require-limits match: { resources: { kinds: ["Pod"] } }
validate:
message: "resources. limits.{cpu,memory} required."
pattern:
spec:
containers:
- resources:
limits:
cpu: "?"
memory: "?"

11.5 Conftest at CI for Terraform Plan

bash terraform plan -out tf. plan terraform show -json tf. plan > tf. json conftest test tf. json --policy policies/terraform

12）嵌入现有能力

RBAC/ABAC：PaC-声明层；重新使用了角色扮演引擎文章中的PDP/PEP。
同意管理："ads/personalization"策略作为数据访问/结束的条件。
匿名/PII：政客们禁止在没有匿名和DP预算配置文件的情况下进行培训/导出。
Geo路由：跨存储区域的流量/数据路由策略。

13）流程和人员

策略域所有者：安全性、平台、数据、产品/营销。
复仇者：证券+域名所有者。
策略目录：目标描述、风险、SLO、联系人、示例、事件引用。
培训：为开发人员提供粘合剂和嗅觉（如何编写测试，如何调节Rego）。

14）建筑师支票清单

1.定义了最小域集和所有者?

2.具有测试、linter和CI的策略存储库?

3.PDP/PEP是否放置在外围，API，K8s和数据管道中？
4.有上下文图和验证吗？
5.帮派签名和交付，缓存和残疾策略？

6.度量（latency, deny, drift）、决策日志和审核?

7.TTL和报告异常过程?

8.Enforce之前的dry-run/shadow模式?

9.热路的部分评估/预编译？

10.降级运行手册（fail-closed/allow-with-redaction）?

二.结论

Policy as Code使规则可以按照与应用程序相同的原则进行复制，验证和管理：修订代码，测试，CI/CD，度量和回扣。通过将PaC与授权（RBAC/ABAC）、合规性和平台安全性连接起来,您可以获得单一、可预测和可扩展的系统行为控制回路-从管理控制到数据导出和ML管道。