Eine Einführung in Open Policy Agent und Styra DAS

Open Policy Agent (oder OPA, ausgesprochen Oh-pa!) ist eine quelloffene (open-source), universell einsetzbare Policy Engine. Wenn man diesen Satz auseinandernimmt, brauchen “open-source” und “Universalität” wahrscheinlich keine weitere Erklärung, also lassen Sie uns direkt zum Teil “Policy Engine” kommen. 

Im Kern ist eine Richtlinie oder Policy – in der “realen Welt” und in OPA – ein Satz von Regeln. Diese Regeln legen meist fest, ob etwas oder jemand etwas darf oder nicht darf, können aber auch viel differenzierter sein. Einige Beispiele für Regeln könnten sein: 

  • Jeder Arzt sollte die Möglichkeit haben, die Krankenakten seiner Patienten einzusehen. 
  • Einem Benutzer, der sich anmeldet, um administrative Aufgaben zu erledigen, sollten nur die für seine Rolle relevanten Optionen angezeigt werden. 
  • Eine neue Software darf nur dann eingesetzt werden, wenn sie mit mindestens zwei Replikaten eingesetzt wird. 
  • Jeder Mikroservice darf nicht außerhalb des Clusters kommunizieren können. 
  • Infrastrukturen, die in Cloud-Umgebungen bereitgestellt werden, müssen stets mit entsprechenden Tags versehen sein, die zeigen, wer für die zugehörigen Ressourcen verantwortlich ist. 
  • Nur jemand, der sich mit mehr als einem Faktor (Multifaktorauthentifizierung – MFA) authentifiziert hat, sollte Kreditberichte einsehen dürfen. 

In der Vergangenheit drehten sich Richtlinien wie diese meist um die Autorisierung (d. h. wer und was darf was tun). Da Infrastruktur, Build- und Deployment-Pipelines und softwaredefinierte Ressourcen zunehmend als Code definiert werden, haben Richtlinien jedoch sowohl neue Anwendungsfälle als auch ein breiteres Publikum gefunden. Dieser Wandel wird durch die Bewegung verkörpert, die gemeinhin als “Policy as Code” bezeichnet wird. Werfen wir einen Blick darauf, was das bedeutet! 

Entkopplung der Policies 

Wenn Sie die obigen Beispielregeln lesen, werden viele von Ihnen wahrscheinlich denken: “Hey! Solche Regeln habe ich schon einmal in meinem Code geschrieben!” Und Sie hätten Recht. Die Einbettung von Richtlinienregeln in die Anwendungs- und Geschäftslogik war traditionell die Art und Weise, wie Richtlinien aus PDF-Dokumenten und PowerPoint-Folien in den Code gelangten, der diese Richtlinien schließlich durchsetzte. Dieses Modell birgt jedoch viele Nachteile. 

Der erste besteht darin, dass Ihre Richtlinien jetzt an mindestens zwei verschiedenen Orten gespeichert werden. Da die “Hauptquelle” der Richtlinie nach wie vor in einem externen Dokument gespeichert ist, besteht die Gefahr, dass die Umsetzung im Anwendungscode im Laufe der Zeit abweicht. Bei einigen wenigen einfachen Richtlinien oder einer einzelnen monolithischen Anwendung mag dies kein großes Problem sein, aber wenn die Anzahl der Richtlinien wächst oder große Anwendungen in kleinere – und oft heterogene – Komponenten aufgeteilt werden, werden Sie bald feststellen, dass die Richtlinien überall verstreut sind. 

Die Verwaltung von Änderungen an Richtlinien kann nun Aktualisierungen in vielen verschiedenen Komponenten erfordern, die von verschiedenen Teams mit unterschiedlichen Technologien verwaltet werden. Das Herausforderung besteht nicht nur darin, den Überblick über die Richtlinie selbst zu behalten. Zu Überwachungs- und Prüfungszwecken wollen wir wahrscheinlich auch verfolgen, wie unsere Richtlinien im Laufe der Zeit durchgesetzt werden. Ohne eine konsistente Möglichkeit für unsere Anwendungen, Richtlinienentscheidungen zu protokollieren, besteht die Gefahr, dass wichtige Richtlinienentscheidungen, wie z. B. die für die Autorisierung, in einem Strom gewöhnlicher Anwendungsereignisse untergehen. 

Die Lösung für dieses Problem besteht darin, die Richtlinien von der Anwendungslogik zu entkoppeln, um die Entwicklung, Aktualisierung und Verwaltung unabhängig von der mit der Anwendung verbundenen Geschäftslogik zu ermöglichen. Die meisten Anwendungen entkoppeln bereits einige Verantwortlichkeiten von externen Systemen. Dabei kann es sich um Dinge wie den Status handeln, den die Anwendung an eine Datenbank delegiert, oder die Authentifizierung, bei der der Benutzer an eine externe Identitätskomponente weitergeleitet wird. Durch die Entkopplung von Richtlinienentscheidungen muss sich Ihre Anwendung nicht mehr mit Rollen und Berechtigungen befassen, und der Richtlinienlebenszyklus kann unabhängig von Ihren Anwendungen und Diensten verwaltet werden. 

Rego 

Wie sehen die eigentlichen Richtlinien aus, wenn sie von einer Anwendung entkoppelt sind? OPA verwendet eine deklarative Sprache namens Rego. Rego-Policies versuchen, reale Richtlinien so weit wie möglich zu spiegeln. Das bedeutet, dass eine Rego-Policy – genau wie eine “echte” Richtlinie – aus einer Reihe von Regeln besteht. Eine Regel wird dann von OPA ausgewertet, um eine Richtlinienentscheidung zu treffen. Wenn alle Bedingungen innerhalb einer Regel wahr sind, wird die Regel als wahr bewertet. Ein Beispiel für eine einfache Regel in einer HTTP-API, die besagt, dass “nur ein Administrator neue Benutzer anlegen darf”, könnte wie folgt aussehen: 

Oben sehen wir eine einfache Regel namens allow, die als wahr gewertet wird, wenn alle Bedingungen innerhalb des Regelkörpers (innerhalb der geschweiften Klammern) als wahr gewertet werden. Die erste Bedingung bezieht sich auf den Pfad der Anfrage aus der Eingabe (input, der – wie im nächsten Abschnitt erläutert – eine von vielen möglichen Datenquellen ist), und wenn er gleich “/users” ist, wird die nächste Bedingung ausgewertet. Diese nächste Bedingung prüft die HTTP-Methode der Anfrage, und wenn es sich um eine POST-Anfrage handelt, wird mit der Prüfung der nächsten Bedingung fortgefahren. Die letzte Bedingung der Regel prüft die Eingabedaten für die mit einem Benutzer verbundenen Rollen, und wenn eine der Rollen, die bei der Iteration über alle angegebenen Rollen gefunden wurde (das [_]-Konstrukt dient zur Iteration über eine Liste von Werten), gleich “admin” ist, wird die Bedingung als wahr ausgewertet. Wenn alle Bedingungen erfüllt sind, wird die Zulassen-Regel als wahr bewertet und die Anfrage wird zugelassen. 

Abhängig von Ihrer bisherigen Erfahrung mit deklarativen Sprachen kann die Syntax von Rego einige Zeit in Anspruch nehmen, um sich daran zu gewöhnen, aber sobald die anfängliche Ungewohntheit überwunden ist, fühlt sich Rego wirklich wie eine natürliche Sprache für den Ausdruck von Richtlinien und Regeln an. 

Rego wurde zwar für die allgemeine Verwendung von OPA entwickelt, ist aber keine Programmiersprache für allgemeine Zwecke, sondern eine Sprache für Richtlinien, mit Merkmalen und (mehr als 150!) eingebauten Funktionen, die speziell auf den Kontext der Bewertung von Richtlinien zugeschnitten sind. Beispiele für eingebaute Funktionen sind solche, die den Umgang mit JSON-Web-Tokens (JWTs), IP-Adressen, Datum und Uhrzeit, Strings und regulären Ausdrücken, JSON- und YAML-Parsing und vieles mehr unterstützen. Es ist zwar unwahrscheinlich, dass das nächste Ego-Shooter-Spiel mit Rego entwickelt wird, aber seine Vielseitigkeit als Sprache hat dazu geführt, dass Rego an vielen Stellen außerhalb der traditionellen Autorisierungsrichtlinien eingesetzt wird (Abb. 1-3).

Abb. 1: Dieses REGO-Beispiel zeigt, dass es einem Nutzer “Alice” erlaubt ist, neue Hunde auf einer Tierhandlungsseite einzufügen.

Daten 

Um fundierte Richtlinienentscheidungen treffen zu können, müssen wir unsere Policies oft mit Daten untermauern. Um auf ein früheres Beispiel zurückzukommen: Eine Richtlinie, die besagt, dass “jeder Arzt die Möglichkeit haben sollte, die Krankenakten seiner Patienten einzusehen”, müsste sowohl wissen, “wer ein Arzt ist”, als auch “wer die Patienten des Arztes sind”, um eine Entscheidung treffen zu können. Es wäre zwar möglich, diese Art von Daten in die Richtlinie selbst aufzunehmen, aber die Daten werden häufiger aktualisiert als die Richtlinie, und wir möchten sensible Daten lieber aus unseren Richtlinien und Versionskontrollsystemen wie Git heraushalten (denken Sie daran, dass Richtlinien schließlich Code sind!). Wie würden wir also diese Art von Daten für OPA bereitstellen? Da Daten ein wesentlicher Bestandteil von Richtlinienentscheidungen sind, bietet OPA mehrere Möglichkeiten. 

  • Die Daten können als Teil der Eingabe (input) bereitgestellt werden, d.h. der Anfrage, die der Kunde stellt, wenn er OPA um eine Entscheidung bittet. Dies ist oft die natürlichste Art, Daten als Teil einer Anfrage bereitzustellen. Zum Beispiel erfordern die meisten Anfragen in gut ausgebauten Systemen, dass sich der Aufrufer authentifiziert. Das Ergebnis der Authentifizierung ist oft eine Reihe von Angaben, darunter Dinge wie die Benutzer-ID, Rollen usw. Die Bereitstellung dieser Informationen an OPA hilft uns, Fragen wie “Ist der Benutzer, der die Anfrage stellt, ein Arzt?” zu beantworten. 
  • Eine weitere Möglichkeit, OPA mit Daten zu versorgen, besteht darin, Daten in eine laufende OPA-Instanz zu schieben (push). Dies ist eine gute Option, wenn ein großer Datensatz häufig aktualisiert wird und man nur die Daten einspeisen möchte, die sich seit der letzten Speicherung der Daten geändert haben (d. h. die Differenz). Ein Nachteil dieser Methode ist, dass OPA extern zugänglich sein muss, damit ein externes System die REST-API von OPA erreichen und Aktualisierungen einspielen kann. Dies wird durch den Pull-Ansatz gemildert. 
  • Ein gängigerer Ansatz besteht darin, dass OPA regelmäßig Daten (und Richtlinien) in Form von Paketen (komprimierte Archivdateien) von einem entfernten Endpunkt abruft (pull). Dies hat den Vorteil, dass die OPA-REST-API nicht nach außen hin offengelegt werden muss, und durch HTTP-Caching wird sichergestellt, dass Bundles nur dann heruntergeladen werden, wenn Aktualisierungen vorgenommen wurden. Der größte Nachteil dieses Ansatzes ist, dass es derzeit keine Möglichkeit gibt, nur die Daten herunterzuladen, die sich seit der letzten Aktualisierung tatsächlich geändert haben. Sofern man nicht mit riesigen Datenmengen arbeiten muss, hat sich dies jedoch in der Praxis als wenig problematisch erwiesen, da selbst große Pakete in nur wenigen Sekunden heruntergeladen werden. Um auf unser Beispiel mit dem Arzt zurückzukommen, könnte dies eine gute Möglichkeit sein, regelmäßig die (natürlich anonymisierten!) Daten von Patienten abzurufen. 
  • Sowohl das Push- als auch das Pull-Modell stellen insofern eine Herausforderung dar, als dass die Daten, die OPA zur Verfügung stehen, nur so aktuell sind, wie der Zeitpunkt des letzten Push- oder Pull-Vorgangs. Für Situationen, in denen dies unerwünscht ist, bietet OPA eine eingebaute Funktion namens
    http.send

    Diese ermöglicht, externe Daten innerhalb von Richtlinien zur Zeit der Richtlinienauswertung abzurufen. Auch wenn dies gelegentlich notwendig ist, führt diese synchrone Art des Datenabrufs zu einer externen Abhängigkeit von einem entfernten System zur Zeit der Richtlinienauswertung und erhöht die Gesamtlatenzzeit für die Entscheidung über eine Richtlinie zusätzlich.

Welche Methode zu verwenden ist, hängt weitgehend von Faktoren wie dem Umfang der Daten und der erwarteten Häufigkeit der Aktualisierungen ab. Eine Kombination aus dem Pull-Modell und der Bereitstellung von Daten als Teil des Inputs hat sich bei den meisten OPA-Einsätzen als sehr effektiv erwiesen. Wichtiger als die Art und Weise, wie die Daten abgerufen werden, ist die Frage, welche Daten zur Bereicherung des Policy-Entscheidungsprozesses verwendet werden können. Kreatives Denken in Bezug auf die Verwendung externer Daten, wie z. B. die Verwendung der Google Calendar API für zeit- und ereignisbasierte Richtlinien, öffnet nicht nur die Tür für neue, interessante Anwendungsfälle für Richtlinien, sondern hilft auch dabei, mehr Menschen in die Erstellung von Richtlinien einzubeziehen. 

Deployment – Einrichten von OPA 

Wir wissen jetzt, was eine Richtlinie ist und wie man Daten aus externen Quellen einbezieht, um fundierte Richtlinienentscheidungen zu treffen. Welche Schritte sind dann erforderlich, um OPA tatsächlich einzusetzen? OPA selbst ist eine kleine, in sich geschlossene ausführbare Datei. Um Policy-Anfragen so schnell wie möglich beantworten zu können, wird sie idealerweise in der Nähe der Anwendung ausgeführt, für die sie Policy-Entscheidungen trifft. Das bedeutet, dass anstelle einiger “zentraler” OPAs, die von vielen Stellen aus abgefragt werden, jede Instanz einer Anwendung mit ihrem “eigenen” OPA neben ihr läuft, oft auf demselben Host wie die Anwendung. Da es sich bei OPA selbst um einen leichtgewichtigen Prozess handelt, bedeutet dies keinen großen Mehraufwand für eine Anwendung. Da Anwendungen zunehmend in kleinere Komponenten und Microservices aufgeteilt werden, bedeutet dies jedoch, dass größere Organisationen möglicherweise Hunderte von OPAs in ihrer Umgebung betreiben. Das verteilte Bereitstellungsmodell von OPA ist zwar ideal für die Leistung, birgt aber auch einige Herausforderungen in Bezug auf die Verwaltung (vgl. Titelbild). 

Abb. 2: Pipeline-Richtlinie, bei der eine Bereitstellung nur zulässig ist, wenn sie nicht am Wochenende erfolgt und die E-Mail-Adresse des Bereitstellers auf “acmecorp.com” endet. 

Management-Fähigkeiten 

Obwohl OPA idealerweise so nah wie möglich an dem Dienst eingesetzt wird, für den es Entscheidungen trifft, sind einige Dinge wahrscheinlich am besten von einem zentralen Standort aus zu orchestrieren. Dazu gehören die Verteilung von Konfigurationen und Richtlinien, das Sammeln von Zustands- und Statusaktualisierungen und die Protokollierung aller getroffenen Entscheidungen.  

Um dies zu erleichtern, bietet OPA Konfigurationsoptionen, die es ermöglichen, dass ein entfernter Dienst Richtlinien- und Datenpakete verteilt sowie Statusaktualisierungen und Entscheidungsprotokolle von OPAs sammelt, die in einem Unternehmen verteilt sind. Schauen wir uns die beiden wichtigsten Optionen genauer an – die Bereitstellung von Richtlinienbündeln und die Protokollierung von Entscheidungen. 

Es ist zwar möglich, OPA mit von der Festplatte geladenen Richtliniendateien und Daten zu starten, doch bleibt dabei eine wichtige Frage unbeantwortet. Was tun wir, wenn wir die Richtlinie oder die Daten aktualisieren müssen, die OPA benötigt, um Entscheidungen zu treffen? Vielleicht wurde in einer Organisation eine neue Rolle zugewiesen, ein neuer Ressourcentyp ist in einem Cloud-Konto aufgetaucht oder wir haben von einem neuen Angriffsvektor in unseren Build- und Deployment-Skripten erfahren und möchten unsere Richtlinie entsprechend aktualisieren. Wenn wir nur ein paar OPAs laufen haben, können wir die Richtlinien wahrscheinlich manuell aktualisieren, aber was ist, wenn wir Hunderte oder sogar Tausende haben? 

Mit der Bundle-API kann OPA stattdessen in regelmäßigen Abständen Richtlinien- und Datenpakete, so genannte Bundles, von einem entfernten Standort abrufen. Immer wenn ein solches Paket aktualisiert wird, bemerkt OPA die Aktualisierung, ruft die neueste Version des Pakets ab und lädt den neuen Inhalt. Auf diese Weise lässt sich die Verteilung von Richtlinien von der eigentlichen Durchsetzung derselben entkoppeln (schon wieder dieses Wort!) und eine große Flotte von OPAs von einer zentralen Komponente aus verwalten. 

Die nächste Verwaltungsfunktion, die einen zusätzlichen Blick wert ist, ist die Entscheidungsprotokollierung. Bei OPA geht es vor allem darum, Entscheidungen zu treffen. Daher ist es sicherlich sinnvoll, später zu wissen, welche Entscheidungen OPA tatsächlich getroffen hat, und zwar auf der Grundlage der Daten, die ihm zu diesem Zeitpunkt zur Verfügung standen. Dies wird durch die Entscheidungsprotokollierungsfunktionen von OPA ermöglicht. Genauso wie die Richtlinien für lokale oder kleinere Einsätze von der Festplatte geladen werden können, kann die Entscheidungsprotokollierung so konfiguriert werden, dass die Entscheidungen auf der lokalen Konsole ausgegeben werden. Für den produktiven Einsatz werden Sie jedoch wahrscheinlich die Protokolle an einem zentralen Ort zusammenfassen wollen. 

OPAs API für Entscheidungsprotokolle ermöglichen genau das und lassen OPA regelmäßig komprimierte Pakete von Entscheidungsprotokollen an einen Server an einem anderen Ort senden. Genau wie bei den Paketen ermöglicht dies einer zentralisierten Verwaltungskomponente, Aggregate von Protokollen zu sammeln, die später verwendet werden können, um Fragen zu beantworten wie “Warum wurde dem Benutzer Jane erlaubt, Gehälter aufzulisten?” oder “Wie konnte der letzte Einsatz von Netzwerkrichtlinien erlaubt werden, ohne dass die entsprechenden Eigentümerkennzeichnungen vorhanden waren?” Da Audits immer häufiger erforderlich sind, ist die zentrale und sichere Speicherung von Protokollen eine absolute Notwendigkeit. 

Styra Deklarativer Autorisierungsservice (DAS) 

Wo legen wir die Richtlinienbündel ab und wohin liefern wir die Entscheidungsprotokolle, wenn alle Verwaltungsfunktionen von OPA verfügbar sind? Und wie überwachen wir eine große Flotte von OPAs, die in unseren Clustern laufen? Die Einrichtung einer eigenen Infrastruktur und eigener Server und das Schreiben eigener Anwendungen zu diesem Zweck ist… machbar, aber es gibt eine viel bessere Option – Styra Declarative Authorization Service (DAS). 

Styra DAS von den Entwicklern des Open Policy Agent bietet eine Control-Plane-Komponente für die Verwaltung von OPA im großen Maßstab. Styra DAS bietet eine fortschrittliche und dennoch einfach zu bedienende Benutzeroberfläche für die Verwaltung von OPA-Systemen sowie für das Erstellen, Testen und Bereitstellen von Richtlinien für eine breite Palette von Anwendungsfällen wie Kubernetes-Zugangskontrolle, Envoy- und Istio-gestützte Anwendungen, Terraform, API-Gateways und Servicemeshes wie Kong, Anwendungsautorisierung oder jeden beliebigen benutzerdefinierten Systemtyp. Darüber hinaus enthalten viele der Systemtypen maßgeschneiderte Richtlinienbündel und Anpassungen, die aus der Erfahrung des OPA-Betriebs in großen Produktionsumgebungen entstanden sind. 

Die Styra DAS-Dokumente leisten eine viel bessere Arbeit bei der Auflistung aller Funktionen, die Styra DAS bietet, als ich es jemals könnte. Anstatt also zu versuchen, das zu kopieren, hier meine nicht umfassende Liste der Lieblingsfunktionen! 

Erstellung von Richtlinien

Mit einem eingebauten grafischen Editor, der denen in IDEs wie IntelliJ IDEA und VS Code ähnelt, macht Styra DAS die Erstellung von Richtlinien zu einem Kinderspiel. Wenn Sie Hilfe bei der Erstellung bevorzugen, ist ein Tool wie der Policy Builder eine gute Möglichkeit, um mit dem Schreiben Ihrer ersten Richtlinien zu beginnen. Für viele Systemtypen, wie z.B. Kubernetes, liefert Styra DAS zusätzlich fertige Richtlinienpakete mit, aus denen Sie einfach eine der gängigen Richtlinien auswählen können, die in Produktionsumgebungen gründlich getestet wurden. 

Abb. 3: Diese Richtlinie überprüft eine bereitgestellte Konfigurationsdatei – im Beispielfall eine Kubernetes-Secret-Ressource – auf erforderliche Attribute wie Namespace und ein Betreuer-Label. 

Git-Integration 

Die Erstellung von Richtlinien ist nur der erste Schritt im Lebenszyklus von Richtlinien. Während Sie Ihre Richtlinien in Styra DAS speichern lassen können, verwenden Produktionskonfigurationen idealerweise Git, um den Richtliniencode wie jeden anderen Code zu verwalten – einschließlich der Automatisierung von Tests, Code-Reviews und Prüfungen vor der Bereitstellung. Um dies zu ermöglichen, integriert sich Styra DAS nahtlos in Repositories wie GitHub und ermöglicht es Ihnen, Richtlinienaktualisierungen in Funktionszweigen zu speichern, die vor der Bereitstellung überprüft und getestet werden können. 

Entscheidungsprotokollierung

Wie wir bereits gelernt haben, hilft uns die Entscheidungsprotokollierung bei der Beantwortung der Frage, welche Richtlinienentscheidungen in der Vergangenheit getroffen wurden. Dieses Wissen ist nicht nur wichtig, um vergangene Entscheidungen zu überprüfen, sondern auch, um zukünftige Richtlinien zu verbessern. Zu den Entscheidungen von besonderem Interesse gehört die Verweigerung des Zugangs zu Systemen, aber noch beängstigender ist natürlich der Gedanke, dass sich jemand Zugang zu Systemen verschafft hat, zu denen er eigentlich keinen Zugang haben sollte! Das Senden von Protokollen an ein entferntes System ist zwar der erste Schritt, ist aber nicht besonders nützlich, wenn das entfernte System die Protokolle nicht tatsächlich sinnvoll verarbeitet. 

Styra DAS macht die Entscheidungsprotokollierung zu einem integralen Bestandteil der OPA-Verwaltung im großen Maßstab und bietet Transparenz in Form von Dashboards, die einen Überblick über die getroffenen Entscheidungen pro System oder für die gesamte Kontrollebene zeigen. Dies ermöglicht es einem Administrator, Abweichungen von den Erwartungen schnell zu erkennen, wie z.B. eine ungewöhnlich hohe Häufigkeit von abgelehnten Entscheidungen oder Fehler bei Policy-Abfragen. Einmal identifiziert, ermöglicht die Ansicht des Entscheidungsprotokolls dem Administrator das Herausfiltern von Protokolleinträgen, die von Interesse sind, oder sogar die Verwendung einer Freitextsuche, um Dinge zu finden, die eine Untersuchung wert sein könnten. 

Auswirkungsanalyse

Mein Lieblingsbeispiel dafür, dass die Entscheidungsprotokollierung nicht nur nützlich ist, um zu wissen, was in der Vergangenheit passiert ist, sondern auch, um künftige Richtlinienentscheidungen zu verbessern, ist die Funktion “Auswirkungsanalyse”. Sie kombiniert die Funktionen zur Richtlinienerstellung von Styra DAS mit der Entscheidungsprotokollierung und ermöglicht es einem Richtlinienautor oder Administrator, Änderungen in einer Richtlinie über die Historie vergangener Entscheidungen wiederzugeben. Dies bietet dem Autor einer Richtlinie eine “Was wäre wenn”-Schaltfläche, um zu beantworten, wie sich eine Änderung an einer Richtlinie (wie das Hinzufügen einer neuen Regel) auf die in der Vergangenheit getroffenen Entscheidungen auswirken würde. Zusammen mit den Unit-Testing-Funktionen von OPA und Styra DAS bietet dies ein hohes Maß an Sicherheit, dass Änderungen eingeführt werden können, ohne bestehende Anwendungsfälle zu zerstören. 

Testen

Unit-Tests sind ein wichtiger Schritt im Lebenszyklus von Richtlinien. Sie helfen uns nicht nur dabei, die Fälle zu testen, die wir erwarten (oder nicht erwarten), sondern eine umfangreiche Testsuite hilft uns auch, im Laufe der Zeit Vertrauen in unsere Richtlinien und Daten aufzubauen. Würde eine Änderung von Richtlinie A Auswirkungen auf Richtlinie B haben? Wenn wir Tests durchführen, wissen wir das sofort. OPA wird mit einem Tool für Unit-Tests von Richtlinien geliefert, und Styra DAS geht noch einen Schritt weiter, indem es die Codeabdeckung visualisiert oder Tests mit einer Auswirkungsanalyse kombiniert, um wirklich sicher zu sein, dass Änderungen keine Produktionsanwendungsfälle zerstören. 

Bibliotheken 

Eine weitere Lieblingsfunktion von Styra DAS sind die Bibliotheken. Da große Organisationen in der Regel Hunderte von Systemen haben, gibt es zwangsläufig Richtlinienregeln und Hilfsfunktionen, die viele von ihnen gemeinsam haben. Bibliotheken helfen genau dabei, indem sie Richtliniencode bereitstellen (natürlich aus Git!), der von allen OPAs in einer Organisation gemeinsam genutzt wird.

Zusammenfassung 

Da immer mehr Unternehmen den Wert der Behandlung von Policies als Code erkennen, der von der Geschäftslogik und den Anwendungsbelangen entkoppelt ist, stellt die Allzwecknatur von OPA eine gemeinsame Lösung für die Anwendung von Richtlinien auf so unterschiedliche Anwendungsfälle wie Infrastruktur, Build- und Bereitstellungspipelines, Datenfilterung, Anwendungsautorisierung und vieles mehr dar. Mit einer gemeinsamen Sprache zur Beschreibung von Richtlinien und gemeinsamen Verfahren für die Erstellung, das Testen und die Bereitstellung von Richtlinien ist OPA die natürliche Wahl, um das Konzept “Policy as Code” in Unternehmen jeder Größe einzuführen. 

In Verbindung mit Styra DAS erhalten Unternehmen Verwaltungsfunktionen für groß angelegte Implementierungen und eine Benutzeroberfläche für die Verwaltung des gesamten Richtlinienlebenszyklus.  

Unabhängig davon, in welchem Stadium sich Ihr Unternehmen auf dem Weg zu Policy as Code befindet, hoffe ich, dass Sie OPA und Styra DAS als Werkzeuge in Betracht ziehen, die Sie auf dem Weg dorthin unterstützen! 

Anders Eknert
Developer Advocate bei Styra mit langjähriger Erfahrung im Bereich Identitätssysteme. Wenn er nicht mit OPA arbeitet, kocht er gerne, isst, spielt Fußball und trinkt belgisches Bier. 

Twitter: https://twitter.com/anderseknert 

LinkedIn: https://www.linkedin.com/in/anderseknert/ 

GitHub: https://github.com/anderseknert/ 

 

English version of this article: https://the-report.cloud/an-introduction-to-open-policy-agent-and-styra-das