Open Policy Agent – Maschinen, die auf Regeln starren

Der Open Policy Agent (OPA) ist eine universell einsetzbare, quelloffene Policy Engine, also eine Sammlung von Komponenten, die eine einheitliche und effiziente Umsetzung von Regeln aller Art erlaubt. Dieser Artikel zeigt ein kleines Praxisbeispiel.

Wann hast du das letzte Mal von einer Policy gehört? Etwa: Wir sollen im Terraform-Skript darauf achten, dass wir bestimmte Parameter setzen. Oder: Wir sollen beim Kubernetes-Deployment darauf achten, dass wir nicht als Root laufen. Das Ganze kann man umsetzen, indem man organisatorische Maßnahmen trifft, was eine umständliche Formulierung für ein Peer Review oder Freigabeprozess ist. Oder durch geschickte Automatisierung. Letztere erhöht zum einen die Sicherheit – denn, mal Hand aufs Herz: Wie oft fällt doch mal etwas nicht auf? – und zum anderen auch die Geschwindigkeit, da eine automatische Prüfung innerhalb einer Pipeline auf jeden Fall schneller ist, als ein Mensch es je sein kann. In dieses kleine Beispiel möchte ich gerne in diesem Artikel konkret hineinschauen, weil ich denke, dass dies eine schöne Möglichkeit ist, mit wenig Aufwand einen In-House-Prozess durch Automatisierung zu beschleunigen – mit dem Open Policy Agent.

OPA-Ökosystem

Um es direkt zu sagen: Das Ökosystem ist groß und die Einsatzmöglichkeiten sind sehr vielfältig. OPA bietet zum einen die Softwarekomponenten, die benötigt werden, um Regeln während der Laufzeit auszuführen, und zum anderen ist es ein Ökosystem mit verschiedensten Werkzeugen und Integration. Und da zeigt sich meiner Meinung nach auch die Stärke dieser Lösung. Wir haben damit die Möglichkeit, als Community voneinander zu profitieren, wie wir es auch normalerweise bei unserer Arbeit gerne machen.

Benutzung

Wenn wir das Projekt einsetzen wollen, können wir zwischen mehreren Deployment-Varianten auswählen. Im Folgenden einmal die Herausstechenden:

1. Einbindung als Library, z. B. in einem Go-Projekt oder über Web Assembly
2. Standalone-Deployment als Service mit REST-basierter API
3. Benutzung in einem Test-Tool wie z. B. Conftest

Je nach Einsatzszenario unterscheiden sich die Ansätze, wie die Daten und Regeln geladen und zur Ausführung gebracht werden. So gibt es etwa die Möglichkeit, die Daten und Regeln in der Auslieferung als Paket mitzuliefern oder diese Regeln von außen zu erhalten.

Was die Szenarien verbindet, ist das generelle Vorgehen: Zunächst erfolgt ein Aufruf, der von außen an die Engine geliefert wird. Die Regeln werden dann ausgeführt und die Entscheidung wird mit Meta-Daten zurückgeliefert. Conftest ist das einfachste Werkzeug, da in diesem Fall die Regeln und die Eingabedaten vorhanden sind und einfach lokal ausgeführt werden kann.

Rego

Bei dieser Sprache handelt es sich um eine für diesen Zweck optimiert entwickelte Sprache, die von Dataloc inspiriert ist. Ich muss zugeben, dass ich erst im Rahmen der Recherche das erste Mal von dieser Sprache gehört habe. Wir können hiermit effizient Regeln definieren, die auf strukturierte Eingabedaten angewendet werden. Dokumente oder Eingabedaten sind über eine bestimmte Variable innerhalb der Regelausführung bekannt und können über logische Operationen validiert werden. Die Navigation innerhalb der Dokumente ist mit https://github.com/stedolan/jq vergleichbar und geht mit ein wenig Übung leicht von der Hand. Damit gehen wir schnell in das obligatorische „Hello, World!“-Beispiel. Als Eingabedaten verwenden wir hier ein JSON-Dokument mit dem Input-Objekt bestehend aus zwei Attributen. Die Policy prüft, ob die beiden Attribute mit den gewünschten Werten vorhanden sind.

Eingabedaten:

1{
2    "greeting": "hello",
3    "message": "world",
4    
5}

Policy:

1default result := false
2result if {
3    input.message == "world"
4    input.greeting == "hello"
5}

Kubernetes

Eingabedaten können beliebige strukturierte Dokumente sein, wie z. B. YAML- oder JSON-Dokumente, sodass sich als Beispiel Kubernetes-Manifeste anbieten, weswegen ich in diesem kurzen Artikel diesen Use Case betrachte.

Die Validierung von Kubernetes-Manifesten kann sowohl im CI-System als auch durch einen Admission Controller im Cluster erfolgen. Innerhalb des CI-Systems wird das OPA-Tooling verwendet, um einen Build mit einer entsprechenden Fehlermeldung zu beenden. Darüber hinaus kann auf den Clustern ein aktiver Check in Form des o. g. Admission Controllers eingebunden werden. Dieser Admission Controller weist Kubernetes-API-Objekte zurück, die den definierten Firmenvorgaben nicht entsprechen.

Ein kleines Beispiel, wie man die Validierung der Kubernetes-Manifeste über das Open-Policy-Agent-Tool Conftest umsetzen kann: Conftest ist ein kleines Kommandozeilentool, das die Rego-Policies und Deploymentkonfiguration erhält, die Prüfung vornimmt, das Ergebnis ausgibt und einen entsprechenden Return-Code liefert, um in der CI darauf reagieren zu können.

Wir implementieren jetzt diese Policies in Rego, die ein Deployment prüfen.

1# Wird in den folgenden Regeln referenziert, um nur auf Deployments zu arbeiten. Andere API-Objekte werden ignoriert
2is_deployment {
3  input.kind = "Deployment"
4}
5
6# Nur Container-Images vom internen Container-Repository sollen verwendet werden. Wird geprüft durch eine Regular Expression auf dem Image-Name
7deny[msg] {
8    kubernetes.is_deployment
9    container := input.spec.template.spec.containers[_]
10    not re_match("^internal.repository.de/.+$", container.image)
11    msg = sprintf("Container in Deployment %s should use an image from the internal repository", [name])
12}
13
14# Wir wollen eine Warnung erzeugen, falls für ein Deployment keine Liveness-Probe definiert wurde. Es wird direkt geprüft, ob diese definiert wurde
15warn[msg] {
16    kubernetes.is_deployment
17    container := input.spec.template.spec.containers[_]
18    not container.livenessProbe
19    msg = sprintf("Container in Deployment %s should define a livenessProbe", [name])
20}

Sollte eine Regel nicht erfüllt sein, wird eine Meldung durch den msg-Block zurückgeliefert und ist damit in der CI-Pipeline sichtbar. Ein sehr einfacher Schritt, der aus dem Stand Mehrwert bietet. Wenn du Fragen dazu hast, melde dich gerne direkt bei mir z. B. über Twitter oder per-Mail, dann schaue ich gerne zusammen mit dir, wie wir das umsetzen können.

Ausblick

Dieser Artikel hat dir schnell einen ersten Überblick über das Projekt Open Policy Agent (OPA) und eine Einsatzmöglichkeit gegeben. Es gibt viel mehr Optionen, das Tool zu verwenden. Um einen ersten Eindruck davon zu erhalten, lohnt es sich, auf der Ökosystem-Seite des Projekts zu stöbern. Weiterhin werden wir auf diesem Blog Artikel zu diesem Thema posten und auch eine SoftwerkerCast-Folge zu diesem Thema aufnehmen.