5 Schritte zur Integration von Istio mit OPA

Authentifizierung und Autorisierung sind bedeutende Teile des Sicherheitspuzzles, die von Cloud-Architekten und DevOps-Ingenieuren gelöst werden müssen. In diesem Blog gehen wir besonders auf die Implementierung von Autorisierung/Zugriffskontrolle ein, d.h. auf die Aktionen ein, die die authentifizierte Entität im Istio-Dienstnetz ausführen kann. Dies hilft, die Infrastruktur zu sichern, indem Handlungen mit böswilligem Inhalt verhindert werden.

Autorisierung in einem Dienstnetz kann mit OPA-Politiken definiert werden. OPA ist ein Mechanismus, der DevOps-Mitarbeitern hilft, Autorisierungs-Politiken für Kubernetes-Lasten zu definieren und durchzusetzen. In diesem Beitrag werden wir sehen:

• Was OPA ist
• Warum Sie OPA mit dem Istio-Dienstnetz integrieren sollten
• Wie Istio und OPA Anfragen autorisieren
• Die exakten Schritte, die Sie folgen können, um OPA mit Istio zu integrieren

Was ist OPA?

OPA (kurz für „Open Policy Agent“) ist ein Open-Source-Allgemeingranularität-Politik-Ausführungs-Agent, der DevOps-Mitarbeiter dazu lässt, Politiken als Code mit einer hochwertigen Deklarationssprache namens Rego zu definieren. OPA hilft dabei, politische Definitionen und -ausführungen zentral über den Stack zu definieren und entlastet Entwickler davon, Autorisierungs-Politiken in die Anwendungscode aufzuschreiben. Hier ist, wie OPA funktioniert (siehe Abbildung 1):

1. Der Anwendung/Dienst erhält eine Anfrage.
2. Der Dienst sendet eine JSON-Autorisierungsanfrage an OPA.
3. OPA überprüft die Anfrage auf Basis der definierten Autorisierungs-Politiken.
4. OPA fasst einen Entscheid und gibt die Autorisierungsantwort (ALLOW/DENY) im JSON-Format an den Dienst zurück.

Abbildung 1: Autorisierungsanfragefluss mit OPA

Beachten Sie, dass es nicht notwendigerweise eine von einem Entwickler geschriebene Anwendung ist, die die Autorisierungsanfrage sendet: Es kann Argo CD, Kubernetes Gateway API-Ressource, Terraform, Prometheus oder alles andere sein, da OPA ein allgemein-zielgerichteter ist. (Ich habe hier eine Anwendung in einem Kubernetes-Cluster erwähnt und gezeichnet, um das Verständnis zu erleichtern.)

Warum OPA mit Istio integrieren?

Istio verfügt über eine robuste Autorisierungsmethode. Allerdings bringt es Vorteile, einen dedizierten Policy-Ausführungs-Motor wie OPA neben dem Istio-Dienstnetz zu haben:

• Zentrales Managementssystem, um Richtlinien zu definieren und durchzusetzen: OPA erleichtert es DevOps, zentral Autorisierungsrichtlinien für den gesamten Stack zu verwalten. Dies umfasst meshtes Workloads, nicht-meshtes Stack und auch Autorisierungsprüfungen (eine Richtlinie, die beispielsweise das Deployment am Freitag verhindert). 
• Mehr Flexibilität und Granularität in der Definition von Richtlinien: Wenn Sie sich anschließend an die Tabelle unten (Abbildung 2) erinnern, ist klar, dass die Istio-Autorisierung viel tun kann und eine Anfrage anhand einer Vielzahl von Feldern aus verschiedenen Datenquellen abgleichen kann. Allerdings kann die Istio-Autorisierungsrichtlinie CRD beim Konfigurieren des HTTP-Anforderungsbody oder irgendeines kontextuellen Datums in den Feldern eingeschränkt sein, für das OPA verwendet werden kann. Im Gegensatz zu Istio kann OPA beliebige Daten für die Policy-Bewertung verwenden.
• Vereinfachte AuthZ-Konfiguration: Es kann für DevOps mühsam werden, komplizierte Autorisierungsregeln in Istio zu konfigurieren. OPA wird mit Rego konfiguriert, der dem Programmiersprachcharakter nahekommt. Es ist relativ einfacher, von grundlegenden bis zu komplexen Policy-Regeln mit Rego zu definieren.

Abbildung 2: Tabellarische Vergleich zwischen Istio und OPA-Autorisierung (Quelle)

Wie Istio und OPA Anfragen authorisieren

DevOps kann OPA als separates Dienstdeployment durchführen oder als Sidecar-Container neben dem Envoy Proxy und dem Anwendungskontainer in einem Pod. Der Sidecar-Container- Ansatz ist besser, um Latenz zu reduzieren.

OPA-Sidecar-Container müssen in das Anwendungspod eingespeichert werden, genau wie die Istio-Envoy-Proxy-Sidecar-Container. Wir können eingestellte OPA-Container so konfigurieren, dass sie ConfigMaps mit den Autorisierungsregeln einhängen; jeder OPA-Sidecar-Container in dem Namespace wird dann dieselbe Konfiguration und AuthZ-Regeln, die in der ConfigMap definiert sind, einhängen.

Sobald der OPA-Sidecar eingespeichert wurde, sendet der Envoy Proxy Autorisierungsanfragen an OPA, um Authorisierungsentscheidungen zu treffen, wenn der Dienst eine Anfrage erhält:

Abbildung 3: Istio-OPA-Autorisierungsworkflow

Wenn die DevOps-Mitarbeiter nicht jeden eingespeicherten OPA-Container im selben Namespace auf dieselben Konfigurationen verweisen möchten und verschiedene Regeln durchsetzen wollen, müssen sie eine der folgenden Maßnahmen ergreifen:

• Entfernen Sie die hard-coded Codes, die es dem aktuellen Injektionspolitik erlauben, eine bestimmte ConfigMap zu verwenden
• Konfigurieren Sie ein mutierendes Webhook und deaktivieren Sie das Sidecar-Injektionsfeature auf Pod-Ebene.
• Werde Richtlinienpakete von einem entfernten HTTP-Server bereitstellen
• Deployen Sie die Anwendung und die Sidecars in einem anderen Namespace mit einer anderen ConfigMap

Schritte zur Integration von Opa mit Istio: Demo

Die Idee hier ist, OPA stattdessen als externen Autorisierer anstelle von Envoy-Proxy-Sidecars zu verwenden, um Zugriffskontrollentscheidungen zu treffen.

Ich werde die klassische Bookinfo-Anwendung aus der Istio-Dokumentation für die Demo verwenden. Ich werde OPA mit Istio für Zugriffskontrolle konfigurieren und überprüfen, ob sie durch die Auslösung von Anfragen an bookinfo/productpage durchgesetzt wird:

Abbildung 4: Istio-OPA-Integrationstutorial-Diagramm

Beachten Sie, dass /productpage die Benutzeroberfläche ist, die interne Aufrufe an andere Dienste wie Bewertungen und Bewertungsdienste macht (Diagramm). Ich werde OPA in jeden Pod im bookinfo-Namespace injizieren; alle OPA-Container binden die gleiche ConfigMap ein und haben aufgrund dessen dieselben Autorisierungspolitiken. Das standardmäßige Verhalten der Bookinfo-Anwendung leitet keine HTTP-Authentifizierung weiter, daher werden interne Aufrufe die Authentifizierung und somit die Autorisierung fehlschlagen.

Wir werden den gegebenen Schritten in folgender Reihenfolge folgen:

1. Konfigurieren der OPA-Sidecar-Injektion
2. Erlauben Sie die Kommunikation zwischen dem Istio-Proxy und OPA
3. Deployiere OPA-Konfiguration
4. Apply Istio configuration
5. Deploy the application and test the Istio-OPA authorization setup

Die Voraussetzung für die Demo ist, dass Istio v1.19+ auf Ihrem Cluster installiert ist. Hier verwende ich Istio v1.21.0.

OPA bietet eine quickstart.yaml für die einfache Installation an. Ich habe das YAML in drei Teile aufgeteilt, um eine bessere Verständigung zu ermöglichen: IMESH GitHub repo. 

Schritt 1: Konfiguriere OPA Sidecar Injection

Apply the opa_controller.yaml:

kubectl apply -f opa_controller.yaml

Der opa_controller.yaml führt alle Dinge – TLS-Zertifikate, ConfigMap mit Injection Policy, Admission Controller Deployment und mutating webhook Konfiguration – in das opa-istio Namespace (siehe Abbildung 5) ein:

1. Der mutating webhook Controller (opa-istio-admission-controller) wird dann auf eine bestimmte Kennung (opa-istio-injection) mit dem Wert „enabled“ lauschen.
2. Der Webhook-Controller ruft den admission-controller auf, der die Injektionsstrategie enthält.
3. Die Injektionsstrategie weist den admission-controller darauf hin, wie er den OPA-Sidecar-Container in das Pod einfügt.

Abbildung 5: OPA-Sidecar-Injektionskonfiguration

Nun wird, bevor die Bookinfo-Anwendung部署iert wird, der bookinfo-Namespace erstellt und anschließend werden die folgenden Schritte durchgeführt:

Erstellen Sie den bookinfo-Namespace, indem Sie bookinfo-ns.yaml anwenden:

kubectl apply -f bookinfo-ns.yaml

Schritt 2: Aktivieren der Kommunikation zwischen Istio Proxy und OPA

Bearbeiten Sie den Istio ConfigMap im istio-system-Namespace und fügen Sie extensionProviders (opa-ext-authz-grpc) hinzu, um die externe Autorisierung im Mesh zu aktivieren:

• Kopieren Sie extensionProviders aus dem Kommentar in opa_controller.yaml.
• Bearbeiten Sie den Istio ConfigMap und fügen Sie extensionProviders im Feld des Mesh hinzu.
• Stellen Sie sicher, dass die Einrückung korrekt ist.
• Speichern Sie die Konfiguration.

Der Schritt ermöglicht es dem istio-proxy, mit dem opa-istio-Container im Pod für Autorisierungsanfragen zu sprechen.

Wenn Sie auf den extensionProviders achten, ist es ein ExtAuthzGrpc-Filtertyp in Envoy mit einer angegebenen Service-Eintragung und -port:

...

extensionProviders:
- name: opa-ext-authz-grpc
envoyExtAuthzGrpc:
service: opa-ext-authz-grpc.local
       port: "9191"

...

Der Name, die Dienstadresse und der Port der extensionProviders sollten sich in der opa_authz.yaml und der opa_config.yaml identisch halten.

Schritt 3: Deployment der OPA-Konfiguration

Die opa_config.yaml definiert Konfigurationen, die mit offenen Richtlinien in Verbindung stehen. Sie enthält opa-istio-config und opa-policy ConfigMaps — letztere definieren die gRPC-Dienstimplementierung (envoy_ext_authz_grpc) und die tatsächlichen Autorisierungsrichtlinien, respectively.

Die Autorisierungsrichtlinien können in zwei Teile aufgeteilt werden: Der erste Teil definiert die Bedingungen, unter denen die Autorisierung zugelassen oder verweigert wird; der zweite Teil definiert die Benutzerrollen und die Berechtigungen für jede Rolle.

Die Autorisierungsrichtlinien können zunächst etwas schwierig zu verwenden sein, da Rego hier keine vielen Keywords verwendet. Aktivieren Sie eine neuere Version von Rego, um Keywords zu erhalten (z.B. allow if Bedingungscharakteristik).

Applikieren Sie die OPA-Konfiguration im bookinfo-Namensraum, da dies mit der Anwendung einhergeht:

kubectl apply -f opa_config.yaml -n bookinfo

Schritt 4: Anwenden der Istio-Konfiguration

Die opa_authz.yaml-Datei enthält Istio-Konfigurationen. Sie enthält eine AuthorizationPolicy und einen ServiceEntry. Beachten Sie, dass der Autorisierungs-Policy-Provider opa-ext-authz-grpc ist, das die extensionProvider ist, die wir in Schritt 2 der ConfigMap konfiguriert haben.

Ähnlichermaßen enthält der in der ServiceEntry definierte Hostname die gleiche Service-Adresse wie in der extensionProvider (opa-ext-authz-grpc.local). Der gRPC-Dienst läuft auf Port 9191 am lokalen Host 127.0.0.1, der die ServiceEntry den opa-istio-Sidecars innerhalb der Pods durch den istio-proxy-Container zugänglich macht.

Führen Sie die Konfiguration aus:

kubectl apply -f opa_authz.yaml -n bookinfo

Schritt 5: Deployment der Anwendung und Test der Istio-OPA-Autorisierungssetzung

Deployieren Sie die Bookinfo-Anwendung und den Gateway:

kubectl apply -f /your_Istio_directory/samples/bookinfo/platform/kube/bookinfo.yaml -n bookinfo
kubectl apply -f /your_Istio_directory/samples/bookinfo/networking/bookinfo-gateway.yaml -n bookinfo

Prüfen Sie die Pods im bookinfo-Namensraum:

kubectl get pods -n bookinfo

Sie können sehen, dass jedes Pod drei Container enthält, die dort ausgeführt werden: die Anwendung, den Envoy-Proxy (istio-proxy) und OPA (opa-istio).

Holten Sie die IP des Istio-Gateways, um auf den Dienst zuzugreifen:

kubectl get svc -n istio-system

Nun ist alles eingerichtet und wir sind bereit, die Autorisierungspolitiken zu testen. Die Politiken, die wir in opa_config.yaml definiert haben, lauten wie folgt:

...

user_roles = {
"alice": ["guest"],
"bob": ["admin"]
}

role_perms = {
"guest": [
{"method": "GET", "path": "/productpage"},
],
"admin": [
{"method": "GET", "path": "/productpage"},
{"method": "GET", "path": "/api/v1/products"},
        ],

...

Alice ist ein Gastbenutzer, der nur auf die Seite /productpage zugreifen kann; Bob ist ein Admin, der auf die Pfade /productpage und /api/v1/products zugreifen kann. Lassen Sie uns die Politiken überprüfen.

Versuchen Sie, von Alice auf /api/v1/products zuzugreifen:

curl -vvv your_istio_gateway_ip/api/v1/products -u alice:password

Sie können sehen, dass die 403 Verboten-Antwort seit Alice keinen Zugriff auf den Pfad hat. Lassen Sie uns versuchen, denselben Pfad wie Bob zu verwenden:

curl -vvv your_istio_gateway_ip/api/v1/products -u bob:password

Es zeigt den HTTP-Status 200 OK und den Inhalt der Seite am Ende der Antwort an.

Beispielszenario für Zugriffskontrolle mit OPA

Sie können Istio-Authorisierungspolizei verwenden, um die in der Demo oben gezeigte Politik durchzusetzen. Sie brauchen nicht OPA. Allerdings gibt es Fälle, in denen die Istio-Authorisierung begrenzt sein kann, wie es am Anfang der Tabelle erwähnt wurde. Geben Sie mir einen einfachen Beispiel.

Stellen Sie sich vor, es gibt eine Buchbewertungsanwendung, die ein GraphQL-Dienst ist, bei dem Rezensionen von Rezensenten eingegeben, Redakteure bearbeitet und veröffentlicht und Benutzer die veröffentlichten Rezensionen lesen können.

Wenn ein Rezensent eine Buchrezension dem Dienst hinzufügt, enthält der Anfrage die JWT des Rezensenten, die die Gruppen und Rollen (Rezensent oder Redakteur) enthält, zu denen der Rezensent gehört. Der Anfragebody enthält auch die GraphQL-Mutationsanfrage mit den neu erstellten Rezensionsdaten.

Lassen Sie uns sagen, Sie möchten die folgenden Bedingungen gewährleisten:

• Nur Rezensenten können Rezensionen einreichen.
• Ein Redakteur kann nur eine Rezension bearbeiten, wenn sie von einem Rezensenten geschrieben wurde, der zu demselben Gruppe gehört, die von ihnen verwaltet wird.
• Nur Redakteure können eine Rezension als „fertig zum Veröffentlichen“ markieren.

Hier ist der Diagramm, das die oben genannten Politiken enthält:

Istio-AuthorizationPolicy wird Schwierigkeiten haben, die oben genannten Bedingungen durchzusetzen. Der Grund ist, dass Istio die GraphQL-Anfragebody nicht für Autorisierungsprüfungen verwenden kann, die ein JSON-Objekt neben der für die Politikbewertung notwendigen JWT ist.

OPA hat keine solchen Einschränkungen. Es kann jede Daten laden, um Richtlinien zu überprüfen, und DevOps kann diese Regeln in einer umfassendere Weise mit Rego schreiben.

Video: Demo in Aktion

Wenn Sie die Demo in Aktion anschauen möchten, bitte den unteren Video anschauen:S

Unterstützung für Unternehmen bei der Integration von Istio

Die meisten Unternehmen verwenden OPA, um Authorisierungsrichtlinien zu definieren und durchzusetzen, die für ihre gesamte Struktur gelten. Ein zentrales Mechanismus für den Zugriffsschutz verbessert die Gesamtsicherheit und Agilität der IT-Teams. Anderenfalls müssten Entwickler Zeit investieren, um Authorisierungsrichtlinien in ihrer Anwendungssoftware in einer bestimmten Sprache zu schreiben, was die Skalierbarkeit und die schnelleren Rollouts von Geschäftslogik behindert.