Policy as Code

1) Ce qu'il faut considérer comme une « politique »

• Accès/autorisation : RBAC/ABAC, ReBAC, exportation de données, step-up (MFA).
• Sécurité de l'infrastructure : admission-contrôle Kubernetes, politique images/secrets, règles réseau.
• Conformité et vie privée : gestion du consentement, balise PII, reporting local 24 heures, géo-restrictions.
• Configurations et qualité : « interdiction : latest », limites de ressources, balises de ressources obligatoires (Cloud).
• Données et ML : interdiction de la formation sur les kits sans consentement, k-anonymat, budgets DP, Data Lineage-invariants.

2) Modèle architectural PaC

PAP (Policy Administration Point) : référentiel et processus de gestion (MR/PR, rhubarbe, version).
PDP (Policy Decision Point) : un moteur qui calcule une décision de politique (OPA, Cedar-engine, son propre interprète).
PEP (Policy Enforcement Point) : point d'application (API-gateway, webhook-admiration en K8s, ETL-transformateur, SDK).
PIP (Policy Information Point) : sources d'attributs/faits : IdP, répertoires de ressources, entrepôt de données, risque-score.
Decision Log/Audit : journaux de décision immuables (pour l'analyse des incidents et la conformité).

Flux : la requête → PEP forme le contexte → le PDP charge les faits (PIP) → calcule la solution → PEP applique (allow/deny/editor) → les logs/métriques.

3) Outils et domaines

L'OPA/Rego est un moteur et un langage universels pour les politiques déclaratives (webhook-admiration en K8s : Gatekeeper, CI - Conftest, API - sidecar/service).
Kyverno - politiques déclaratives pour Kubernetes dans YAML, patch/validation/génération.
Cedar (AWS/transférable) est un langage politique qui met l'accent sur l'autorisation de « qui fait quoi ».
Cloud IAM (AWS/GCP/Azure) - Politiques de ressources cloud (il est préférable de vérifier PaC avec statique et dans les plans IaC).
Custom - DSL/règles sur JSON/SQL pour les spécificités (par exemple, la conformité ML).

4) Le cycle de vie de la politique

1. Définition de la cible et du domaine : « Interdiction de charger des conteneurs avec des vulnérabilités High/CRITICAL ».
2. Formalisation dans le code : Rego/Cedar/YAML.
3. Tests : tables de vérité, cas négatifs, property-based.
4. Contrôles CI : linter, unit, intégration sur des manifestes/requêtes fictifs.
5. Sortie et distribution : publication en bundle, signature, livraison sur PDP/edge.
6. Surveillance : hit-rate, latency p95/p99, proportion de deny, dashboard de dérive.
7. Exceptions/waivers : durée/portée limitée, avec vérification et propriétaire.
8. Refactoring et archive : versions, compatibilité, migrations.

5) Stockage et distribution

Repo-layout: `policies/<domain>/<policy>.rego|cedar|yaml`, `tests/`, `bundles/`, `schemas/`.
Versioning : semver et 'policy _ version' dans les réponses PDP.
Bundles : paquets de stratégies compressées + schémas + configs signés (sécurité de la chaîne d'approvisionnement).
Distribution : pull (PDP tire du registry/S3) ou push (le contrôleur envoie).
Évaluation partielle : anticipation des politiques pour une exécution rapide sur le périmètre.

6) Modèle de données et schémas

Contrat de contexte unique : 'subject', 'resource', 'action', 'bou', 'legal'.
JSON-Schema/Protobuf : valider le modèle de fait ; l'incohérence des schémas est la raison pour laquelle « indeterminate → deny ».
Normaliser les attributs : noms unifiés (par exemple, 'tenant _ id', 'risk _ level', 'pii _ tags', 'image. vulns`).

7) Performance et fiabilité

Cache de solution : Clé '(subject_hash, resource_key, action, policy_version)' ; court TTL, handicap par évènement (changement de rôle/tags).
Faits locaux : ne tirez pas les PIP lourds sur le chemin chaud - synchronisez les snapshots.
Fail-open vs fail-closed : sécurité des domaines critiques - fail-closed ; pour les UX-critiques, c'est la dégradation (edito au lieu de deny).
Budget de latence : cible '<3-10 ms' par solution en mémoire PDP, '<30-50 ms' avec PIP.

8) Gestion des exceptions (waivers)

Limité dans le temps (par exemple, 7 jours), avec le propriétaire obligatoire et la raison.
Scooped : par ressource/proect/neimspace ; l'interdiction du « pour toujours » mondial.
Audit et rappels : rapports sur waiver'am expirant, auto-coque/escalade.

9) Métriques et observabilité

Policy Coverage : proportion de voies/endpoints protégés par le PaC.
Decision Latency / QPS / Error rate.
Deny Rate et False Positive/Negative (via le mode « dry-run/shadow »).
Drift : divergence entre le plan (IaC) et le fait (live), entre le SDK et les solutions serveur.
Аудит: `decision_id, policy_ids, version, attributes_digest, effect, reason`.

10) Anti-modèles

Stratégies « cousues » dans le code sans versions ni tests.
L'absence de schémas/validation du contexte → des décisions imprévisibles.
Un fichier monolithique "mega. rego».
Il n'y a pas de processus d'exception → « rondes manuelles » et chaos.
Seule application runtime sans « shift-left » dans CI (pannes tardives).
Effets cachés dans la politique (la politique doit être une fonction pure).

11) Exemples

11. 1 Rego (OPA) : interdiction des images vulnérables en 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 : exportation de données uniquement à partir de MFA et par IP « blanche »

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 : lecture uniquement au propriétaire ou aux membres de l'équipe

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) : interdiction du ': latest' et du '. ressources

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 en CI pour le plan Terraform

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

12) Incorporation dans les capacités existantes

RBAC/ABAC : PaC - couche de déclaration ; PDP/PEP de l'article sur le moteur de rôle sera réutilisé.
Gestion du consentement : la politique « ads/personalization » comme conditions d'accès aux données/endpoints.
Anonymisation/PII : les politiques interdisent la formation/exportation sans profils d'anonymisation et budget DP.
Géo-routage : Politique de routage du trafic/des données par région de stockage.

13) Processus et personnes

Propriétaires de domaines politiques : sécurité, plateforme, données, produits/marketing.
Revues : titres + propriétaires de domaine.
Catalogue des politiques : description de la cible, risque, SLO, contact, exemples, liens vers les incidents.
Formation : hydes et extraits pour les développeurs (comment écrire des tests, comment régler Rego).

14) Chèque de l'architecte

1. Vous avez défini un ensemble minimum de domaines et d'owners ?
2. Référentiel de stratégies avec tests, linter et IC ?
3. Les PDP/PEP sont-ils placés sur le périmètre, dans l'API, dans le K8s et dans les pipelines de données ?
4. Y a-t-il des schémas de contexte et de validation ?
5. Signature et livraison des bandes, stratégie de cache et d'invalidité ?
6. Métriques (latitude, deny, drift), decision-log et audit ?
7. Processus d'exclusion avec TTL et rapports ?
8. Dry-run/shadow-mode avant Enforce ?
9. Évaluation partielle/précompilation pour les voies « chaudes » ?
10. Runbook sur la dégradation (fail-closed/allow-with-redaction) ?

Conclusion

Policy as Code rend les règles reproductibles, vérifiables et gérables selon les mêmes principes que l'application : code-revues, tests, CI/CD, métriques et retouches. En connectant le PaC à l'autorisation (RBAC/ABAC), à la conformité et à la sécurité de la plate-forme, vous obtenez une boucle unique, prévisible et évolutive de contrôle du comportement du système - de l'admission-contrôle aux exportations de données et aux piplines ML.