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管道。