Rezept: deny-closed-Policies (Cedar / OPA)

Edition: Das Erstellen und Bearbeiten eigener Cedar-Richtlinien, einschließlich permit und forbid, erfordert Business. Community setzt gespeicherte Richtlinien, eigene Rollen und begrenzte Berechtigungen weiterhin durch; Lesen und Widerrufen bleiben möglich. DELETE /v1/m/governance/pdp/active?engine=cedar deaktiviert nur die selbst verfasste Cedar-Richtlinie und erhält Verlauf, verwaltete Berechtigungen und übernommene Richtlinien. Integrierte Rollen, native Verweigerungsregeln und der Notausschalter bleiben in Community. Der externe PDP dieses Rezepts schränkt nur ein; selbst verfasste Cedar-permits können innerhalb ihres Geltungsbereichs Zugriff gewähren. Die Auswahl dieser externen Engine (OLIVARES_PDP_ENGINE, eine Cedar-Datei oder OPA) erfordert Business: Community verweigert den Start, wenn eine Engine ausgewählt ist.

Ziel: attributbasierte Restriktionen oberhalb von deny-by-default RBAC hinzufügen — zum Beispiel „niemand fasst Ressourcen mit dem Tag secret an, ganz gleich, was seine Rolle erlaubt”.

Die eine Invariante, die man im Kopf behalten muss: der PDP restringiert nur. Die Entscheidung setzt sich als RBAC ∩ natives ABAC ∩ externer PDP zusammen — eine Policy kann niemals gewähren, was das Rollenmodell verweigert (das Modell).

Cedar (eingebettet, primär)

Die Engine auswählen, auf die Policy-Datei verweisen und neu starten:

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

Eine Cedar-Policy ist ein forbid-Overlay — das Basis-permit steht für „RBAC hat bereits entschieden”, und deine forbid-Regeln subtrahieren davon:

permit(principal, action, resource);

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

Zwei Fakten zur Autorenschaft, gegen den Adapter verifiziert: resource.kind und resource.sensitivity sind immer im Entscheidungs-Input vorhanden (unbedingt referenzierbar); jedes andere Attribut muss mit has() abgesichert werden, sonst kann die Regel nicht greifen. Ein permit, das du schreibst, kann die Entscheidung niemals erweitern.

OPA (über 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

Verfasse das Rego permit-by-default:

package olivares

default allow := true

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

true = keine Restriktion. false, ein fehlendes Ergebnis oder jeder Transport- oder Nicht-2xx-Fehler scheitert geschlossen (fail closed) — die Anfrage wird verweigert, niemals stillschweigend ungoverned.

Validieren, Dry-Run, Veröffentlichen

Das Governance-Modul stellt einen Policy-Lebenszyklus bereit, damit eine fehlerhafte Policy niemals blind in Produktion landet:

# policy.cedar is the Cedar policy above; jq 1.6 or newer builds the JSON bodies.
# Compile-Check der Quelle:
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}')"

# Eine Entscheidung OHNE Audit-Seiteneffekte vorab prüfen:
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}')"

# Dann veröffentlichen (policy-admin-Berechtigung):
curl -ks -X POST "$BASE/v1/m/governance/pdp/publish" …

GET /v1/m/governance/pdp/versions listet auf, was deployt ist; POST /v1/m/governance/pdp/explain erklärt eine Entscheidung.

Die Sicherheitseigenschaften verifizieren

• Mit einer ungültigen Policy-Datei neu starten: die Engine deaktiviert nur den externen PDP und protokolliert das — RBAC und natives ABAC governen weiter; die Control Plane fällt nicht aus.
• Jede Restriktion, die der PDP anwendet, wird auditiert — prüfe das Ledger nach einer verweigerten Anfrage.

Hinweise

• Policies werden versioniert und veröffentlicht, nicht als heiß editierte Dateien in Produktion betrieben — behandle die Veröffentlichung als geprüfte Änderung.
• Für genehmigungspflichtige (statt verweigerte) Aktionen siehe HITL-Genehmigungen.