Recette : politiques deny-closed (Cedar / OPA)

Édition : créer ou modifier des politiques Cedar personnalisées, permit comme forbid, nécessite Business. Community continue d’appliquer les politiques, rôles personnalisés et droits limités déjà enregistrés ; leur lecture et leur révocation restent possibles. DELETE /v1/m/governance/pdp/active?engine=cedar désactive uniquement la politique Cedar rédigée et conserve l’historique, les droits gérés et les politiques adoptées. Les rôles intégrés, les règles natives de refus et l’arrêt d’urgence restent dans Community. Le PDP externe de cette recette ne fait que restreindre ; les permit Cedar rédigés peuvent accorder l’accès dans leur périmètre. Sélectionner ce moteur externe (OLIVARES_PDP_ENGINE, un fichier Cedar ou OPA) requiert Business : Community refuse de démarrer lorsqu’un moteur est sélectionné.

Objectif : ajouter des restrictions basées sur les attributs par-dessus un RBAC deny-by-default — par exemple, « personne ne touche aux ressources étiquetées secret, quel que soit ce que dit son rôle ».

L’invariant à garder en tête : le PDP restreint uniquement. La décision se compose comme RBAC ∩ ABAC natif ∩ PDP externe — une politique ne peut jamais accorder ce que le modèle de rôles refuse (le modèle).

Cedar (embarqué, primaire)

Sélectionnez le moteur et pointez-le sur votre fichier de politique, puis redémarrez :

OLIVARES_PDP_ENGINE=cedar
OLIVARES_PDP_CEDAR_FILE=/etc/olivares/policy.cedar

Une politique Cedar est une surcouche forbid — le permit de base représente « le RBAC a déjà décidé », et vos règles forbid soustraient :

permit(principal, action, resource);

forbid(principal, action, resource)
  when { resource.kind == "credential" && resource.sensitivity == "secret" };

Deux faits d’écriture, vérifiés contre l’adaptateur : resource.kind et resource.sensitivity sont toujours présents sur l’entrée de décision (référençables sans condition) ; tout autre attribut doit être protégé par has(), sinon la règle ne peut pas s’apparier. Un permit que vous écrivez ne peut jamais élargir la décision.

OPA (via HTTP)

OLIVARES_PDP_ENGINE=opa
OLIVARES_PDP_OPA_URL=http://opa.internal:8181
OLIVARES_PDP_OPA_PATH=/v1/data/olivares/decision
OLIVARES_PDP_OPA_TOKEN=<bearer-reference>     # optional

Écrivez le Rego en permit-by-default :

package olivares

default allow := true

allow := false if {
  input.resource.sensitivity == "secret"
  endswith(input.permission, ":read")
}

true = aucune restriction. false, un résultat manquant, ou toute erreur de transport ou réponse non-2xx échoue en mode fermé — la requête est refusée, jamais silencieusement non gouvernée.

Valider, dry-run, publier

Le module de gouvernance expose un cycle de vie des politiques afin qu’une mauvaise politique n’atterrisse jamais à l’aveugle :

# policy.cedar is the Cedar policy above; jq 1.6 or newer builds the JSON bodies.
# Compile-check the source:
curl -ks -X POST "$BASE/v1/m/governance/pdp/validate" \
  -H "Authorization: Bearer $TOKEN" -H "X-Olivares-Tenant: $TENANT" \
  -d "$(jq -n --rawfile source policy.cedar '{engine:"cedar",$source}')"

# Pre-flight a decision WITHOUT audit side effects:
curl -ks -X POST "$BASE/v1/m/governance/pdp/dry-run" \
  -H "Authorization: Bearer $TOKEN" -H "X-Olivares-Tenant: $TENANT" \
  -d "$(jq -n --rawfile source policy.cedar --argjson request '{"principal":{"kind":"user","id":"u1"},"permission":"models:keys:read","resource":{"kind":"credential","sensitivity":"secret"}}' \
        '{engine:"cedar",$source,$request}')"

# Then publish (policy-admin permission):
curl -ks -X POST "$BASE/v1/m/governance/pdp/publish" …

GET /v1/m/governance/pdp/versions liste ce qui est déployé ; POST /v1/m/governance/pdp/explain explique une décision.

Vérifier les propriétés de sécurité

• Redémarrez avec un fichier de politique invalide : le moteur ne désactive que le PDP externe et le journalise — le RBAC et l’ABAC natif continuent de gouverner ; le control plane ne tombe pas.
• Chaque restriction appliquée par le PDP est auditée — vérifiez le ledger après une requête refusée.

Notes

• Les politiques sont versionnées et publiées, ce ne sont pas des fichiers édités à chaud en production — traitez la publication comme un changement revu.
• Pour les actions soumises à approbation (plutôt que refusées), voir les approbations HITL.