Open Policy Agent – Policy as Code?

Viele moderne Tools setzen rollenbasierte Autorisierung ein – und geben den Administratoren einen umfangreichen Katalog mit, welche Fähigkeiten welcher Rolle zugeordnet sind. Einige Tools wie Jira ermöglichen sogar, diese Rollenprofile in komplexen Administrationsoberflächen anzupassen. Die Komplexität der Benutzeroberfläche steigt damit mit der Mächtigkeit der Anpassungsmöglichkeiten enorm, gibt aber dennoch nur eine eingeschränkte Möglichkeit, Berechtigungen zu konfigurieren. Wie lässt sich diese Komplexität in einem modernen DevOps-Umfeld besser verwalten?

Open Policy Agent bietet eine Alternative zur Benutzeroberfläche: Policy as Code. Tools, die Open Policy Agent für die Autorisierung einsetzen, erlauben damit das Festlegen von Rollenprofilen in einer Domain Specific Language, die für diesen Zweck entwickelt wurde. Das ermöglicht es, verschiedene Policies mit Sourcecode-Verwaltungstools zu versionieren, verwalten, testen und zu vergleichen. Über die diversen Funktionen lassen sich neben rollenbasierter Autorisierung auch komplexere Autorisierungsverfahren an die Anforderungen der Organisation maßschneidern.

Open Policy Agent stellt die Policy und alle zusätzlich geladenen Daten als virtuelles JSON-Dokument bereit. Die durch die Daten dargestellten Werte sind statisch und werden nur mit einem Update der Datenquelle aktualisiert. Im Gegensatz dazu ergibt die Auswertung der Policies virtuelle Teildokumente, die sich je nach Autorisierungsanfrage, die mit dem API-Aufruf übermittelt wird, im Ergebnis unterscheiden können.

Eine Policy für eine Parkhausschranke, die das Teildokument data.app.parking definiert, könnte bspw. wie folgt aussehen:

package app.parking 
import future.keywords.contains 
import future.keywords.if 
import future.keywords.in 
default allow := false  

Eine solche Policy folgt dem Deny-by-Default-Prinzip und würde ohne weitere Anweisungen keine Zufahrt ermöglichen. Möchte man nun allen Fahrzeugen, die eine beliebige Parkkarte präsentiert haben, die Zufahrt pauschal erlauben, so kann man eine Regel definieren, die die Zufahrt erlaubt, sofern eine Karten-ID übermittelt wurde: 

allow if  
input.card_read 
}  

Ein Kennzeichenscanner ließe sich auf analoge Art und Weise anbinden; ergänzt um eine Prüfung des Kennzeichens gegen eine Liste von Unternehmensfahrzeugen, die aus einer Datenbank bereitgestellt werden könnte: 

allow if { 
input.license_plate in data.company_cars 
}  

Ebenso können komplexere Einschränkungen, bspw. die Verbindung von Kennzeichen und Uhrzeit, realisiert werden: 

allow if { 
    input.license_plate in data.employee_cars 

    is_daytime 
} 

is_daytime if { 
    [hour, _, _] := time.clock([time.now_ns(),"CET"]) 
    hour >= 8 
    hour < 20 
}  

Open Policy Agent gibt so Administratoren im DevOps-Prozess die Möglichkeit, Berechtigungs-Policies flexibel entsprechend den Anforderungen zu definieren.

Ebenso ist es möglich, spezifische Fehlermeldungen zu definieren, die dem Benutzer gegenüber, den Grund für die Berechtigungsverweigerung und ggf. auch eine Problemlösung aufführen:

deny["License Plate not allowed during this time of day. Please pull a ticket."]{ 
    not allow 
    input.license_plate in data.employee_cars 
    not is_daytime 
}  

Wer mehr über die Sprache Rego und ihre Möglichkeiten erfahren möchte, findet die Dokumentation unter diesem Link.

Oder haben sie weitere Fragen zu dem Thema Berechtigungsmanagement? Dann sprechen Sie uns gerne an. Wir unterstützen Sie gerne beim Aufbau Ihrer IAM (Identity- and Accessmanagement) Lösung.

Seminarempfehlung