Policy as Code

1) Що вважати «політикою»

• Доступ/авторизація: RBAC/ABAC, ReBAC, експорт даних, step-up (MFA).
• Безпека інфраструктури: admission-контроль Kubernetes, політика образів/секретів, мережеві правила.
• Комплаєнс і приватність: управління згодою, PII-тегування, локальні звітну добу, гео-обмеження.
• Конфігурації та якість: "заборона:latest", ліміти ресурсів, обов'язкові теги ресурсів (Cloud).
• Дані та ML: заборона тренінгу на наборах без згоди, k-анонімність, DP-бюджети, Data Lineage-інваріанти.

2) Архітектурна модель PaC

PAP (Policy Administration Point): репозиторій і процеси управління (MR/PR, рев'ю, версія).
PDP (Policy Decision Point): рушій, що обчислює рішення з політики (OPA, Cedar-engine, власний інтерпретатор).
PEP (Policy Enforcement Point): точка застосування (API-шлюз, webhook-адміссіон в K8s, ETL-трансформер, SDK).
PIP (Policy Information Point): джерела атрибутів/фактів: IdP, каталоги ресурсів, склад даних, ризик-скор.
Decision Log / Audit: незмінні журнали рішень (для розбору інцидентів і відповідності).

Потік: запит PEP формує контекст PDP завантажує факти (PIP) обчислює рішення PEP застосовує (allow/deny/редакція) лог/метрики.

3) Інструменти та домени

OPA/Rego - універсальний рушій і мова для декларативних політик (webhook-адміссіон в K8s: Gatekeeper, в CI - Conftest, в API - sidecar/служба).
Kyverno - декларативні політики для Kubernetes в YAML, патч/валідація/генерація.
Cedar (AWS/переноситься) - мова політик з акцентом на авторизацію «хто-над-чим-що робить».
Cloud IAM (AWS/GCP/Azure) - політики хмарних ресурсів (бажано використовувати PaC статикою і в планах IaC).
Custom - DSL/правила поверх JSON/SQL для специфічок (наприклад, ML-комплаєнс).

4) Життєвий цикл політики

1. Визначення мети і домену: «Заборона на завантаження контейнерів з уразливостями High/CRITICAL».
2. Формалізація в коді: Rego/Cedar/YAML.
3. Тести: таблиці істинності, негативні кейси, property-based.
4. CI-перевірки: лінтер, unit, інтеграція на фіктивних маніфестах/запитах.
5. Реліз і поширення: публікація в bundle, підпис, доставка на PDP/edge.
6. Моніторинг: hit-rate, latency p95/p99, частка deny, дашборди дрифту.
7. Винятки/waivers: обмежені за часом/обсягом, з аудитом і власником.
8. Рефакторинг та архів: версії, сумісність, міграції.

5) Зберігання та розповсюдження

Repo-layout: `policies/<domain>/<policy>.rego|cedar|yaml`, `tests/`, `bundles/`, `schemas/`.
Версіонування: semver і'policy _ version'у відповідях PDP.
Bundles: стислі пакети політик + схем + конфігів, підписані (supply chain security).
Distribution: pull (PDP тягне з registry/S3) або push (контролер розсилає).
Partial evaluation: передвирахування політик для швидкого виконання на периметрі.

6) Модель даних і схеми

Єдиний контракт контексту: `subject`, `resource`, `action`, `env`, `legal`.
JSON-Schema/Protobuf: валідуйте факт-моделі; розбіжність схем - причина для «indeterminate → deny».
Нормалізація атрибутів: уніфіковані назви (наприклад,'tenant _ id','risk _ level','pii _ tags','image. vulns`).

7) Продуктивність і надійність

Кеш рішень: ключ `(subject_hash, resource_key, action, policy_version)`; короткий TTL, інвалідація за подіями (зміна ролей/тегів).
Локальні факти: не тягніть важкі PIP на гарячому шляху - синхронізуйте снапшоти.
Fail-open vs fail-closed: безпека критичних доменів - fail-closed; для UX-критичних - деградація (редакція замість deny).
Бюджет латентності: мета'< 3-10 мс'на рішення в пам'яті PDP,'< 30-50 мс'з PIP.

8) Управління винятками (waivers)

Обмежені за часом (наприклад, 7 днів), з обов'язковим власником і причиною.
Скоуповані: по ресурсу/проекту/неймспейсу; заборона глобальних «назавжди».
Аудит та нагадування: звіти по закінчуються waiver'ам, автозакриття/ескалація.

9) Метрики і спостережуваність

Policy Coverage: частка шляхів/ендпойнтів, захищених PaC.
Decision Latency / QPS / Error rate.
Deny Rate і False Positive/Negative (через режим «dry-run/shadow»).
Drift: розбіжність між планом (IaC) і фактом (live), між SDK і серверними рішеннями.
Аудит: `decision_id, policy_ids, version, attributes_digest, effect, reason`.

10) Анти-патерни

Політики, «зашиті» в код без версій і тестів.
Відсутність схем/валідації контексту → непередбачувані рішення.
Один монолітний файл "mega. rego».
Немає процесу винятків → «ручні обходи» і хаос.
Тільки runtime-застосування без «shift-left» в CI (пізні відмови).
Приховані сайд-ефекти в політиці (політика повинна бути чистою функцією).

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 в CI для Terraform-плану

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. Визначено мінімальний набір доменів і owners?
2. Репозиторій політик з тестами, лінтером і CI?
3. PDP/PEP розміщені на периметрі, в API, в K8s і в пайплайнах даних?
4. Є схеми контексту і валідація?
5. Підпис і доставка бандлів, стратегія кешу та інвалідації?
6. Метрики (latency, deny, drift), decision-лог і аудит?
7. Процес виключень з TTL і звітністю?
8. Dry-run/shadow-режим перед Enforce?
9. Partial evaluation/передкомпіляція для «гарячих» шляхів?
10. Runbook на деградацію (fail-closed/allow-with-redaction)?

Висновок

Policy as Code робить правила відтворюваними, перевіреними і керованими за тими ж принципами, що і додаток: код-рев'ю, тести, CI/CD, метрики та відкати. З'єднуючи PaC з авторизацією (RBAC/ABAC), комплаєнсом і безпекою платформи, ви отримуєте єдиний, передбачуваний і масштабований контур управління поведінкою системи - від admission-контролю до експортів даних і ML-пайплайнів.