🥇Zurück zu Microservices mit Istio. Teil 3

Hinweis.: Erster Teil Dieser Zyklus war der Einführung in die Möglichkeiten von Istio und deren praktischen Demonstration gewidmet. zweiter Dabei ging es um präzise Routenplanung und das Management des Netzwerkverkehrs. Jetzt steht die Sicherheit im Fokus: Zur Demonstration der grundlegenden Funktionen verwendet der Autor den Identitätsdienst Auth0, jedoch können auch andere Anbieter analog konfiguriert werden.

Wir haben ein Kubernetes-Cluster konfiguriert, in dem wir Istio und ein Beispiel für eine Mikrodiensten-App namens Sentiment Analysis bereitgestellt haben — so wurden die Möglichkeiten von Istio demonstriert.

Mit Istio konnten wir die Größe der Services gering halten, da sie keine Implementierung von Schichten wie Verbindungswiederholungen (Retries), Zeitüberschreitungen (Timeouts), automatische Auslöseschalter (Circuit Breakers), Tracing oder Monitoring benötigen. Außerdem haben wir Techniken für fortgeschrittenes Testen und Deployment eingesetzt: A/B-Tests, Mirroring und Canary-Deployments.

Im neuen Material werden wir die abschließenden Schichten auf dem Weg zum Geschäftswert untersuchen: Authentifizierung und Autorisierung — und bei Istio macht das richtig Spaß!

Authentifizierung und Autorisierung in Istio

Ich hätte nie gedacht, dass ich von Authentifizierung und Autorisierung inspiriert werden könnte. Was kann aus technologischer Sicht Istio bieten, um diese Themen spannend zu machen und vielleicht sogar Sie zu inspirieren?

Die Antwort ist einfach: Istio überträgt die Verantwortung für diese Funktionen von Ihren Services auf den Envoy-Proxy. Wenn die Anfragen die Services erreichen, sind sie bereits authentifiziert und autorisiert, sodass Sie nur noch geschäftsrelevanten Code schreiben müssen.

Klingt gut? Lassen Sie uns einen Blick hineinwerfen!

Authentifizierung mit Auth0

Als Server für Identitäts- und Zugriffsmanagement nutzen wir Auth0, das eine Testversion bietet, intuitiv zu bedienen ist und mir einfach gefällt. Die gleichen Prinzipien können jedoch auch auf jede andere Implementierung von OpenID Connect: KeyCloak, IdentityServer und viele andere.

Zunächst besuchen Sie das Auth0 Portal mit Ihrem Konto, erstellen Sie einen Tenant (Tenant – eine logische Isolationseinheit, detailliertere Informationen finden Sie in Dokumentation. — Anmerkung des Übersetzers). und gehen Sie zu Applications > Default App, indem Sie Domain, wie im Screenshot unten gezeigt:

Geben Sie diese Domain in die Datei resource-manifests/istio/security/auth-policy.yaml (ein.):

apiVersion: authentication.istio.io/v1alpha1
kind: Policy
metadata:
  name: auth-policy
spec:
  targets:
  - name: sa-web-app
  - name: sa-feedback
  origins:
  - jwt:
      issuer: "https://{YOUR_DOMAIN}/"
      jwksUri: "https://{YOUR_DOMAIN}/.well-known/jwks.json"
  principalBinding: USE_ORIGIN

Mit solch einer Ressource konfiguriert Pilot (einer der drei grundlegenden Komponenten des Control Plane in Istio — Anm. d. Übers.) die Envoy-Instanzen zur Authentifizierung von Anfragen, bevor diese an die Dienste weitergeleitet werden: sa-web-app и sa-feedback. Gleichzeitig wird die Konfiguration nicht auf die Envoy-Instanzen des Dienstes angewendet sa-frontend, was es uns ermöglicht, das Frontend nicht authentifiziert zu lassen. Um die Richtlinie (Policy) anzuwenden, führen Sie den Befehl aus:

$ kubectl apply -f resource-manifests/istio/security/auth-policy.yaml
policy.authentication.istio.io “auth-policy” erstellt

Gehen Sie zurück zur Seite und machen Sie eine Anfrage — Sie werden sehen, dass sie mit dem Status endet 401 Unauthorized. Lassen Sie uns die Benutzer des Frontends zur Authentifizierung mit Auth0 weiterleiten.

Anfragen authentifizieren mit Auth0

Um die Anfragen des Endbenutzers zu authentifizieren, müssen Sie eine API in Auth0 erstellen, die die authentifizierten Dienste (Bewertungen, Details und Ratings) repräsentiert. Um eine API zu erstellen, gehen Sie zu Auth0 Portal > APIs > API erstellen und füllen Sie das Formular aus:

Wichtige Informationen hierbei sind Identifier, den wir später im Skript verwenden werden. Notieren wir uns das so:

Zielgruppe: {YOUR_AUDIENCE}

Die verbleibenden benötigten Details finden wir im Auth0-Portal im Abschnitt Anwendungen — wählen Sie aus Testanwendung (wird automatisch zusammen mit der API erstellt).

Hier notieren wir:

Domain: {YOUR_DOMAIN}
Client-ID: {YOUR_CLIENT_ID}

Scrollen Sie zu Testanwendung zum Textfeld Erlaubte Callback-URLs (erlaubte URLs für den Callback), in dem wir die URL angeben, an die der Aufruf gesendet werden soll, nachdem die Authentifizierung abgeschlossen ist. In unserem Fall ist das:

http://{EXTERNAL_IP}/callback

Und für Erlaubte Logout-URLs (erlaubte URLs für die Abmeldung) fügen wir hinzu:

http://{EXTERNAL_IP}/logout

Lassen Sie uns zum Frontend übergehen.

Frontend-Update

Wechseln Sie zu dem Branch auth0 aus dem Repository [istio-mastery]. In diesem Branch ist der Frontend-Code so geändert, dass Benutzer zur Auth0-Authentifizierung umgeleitet werden und das JWT-Token in Anfragen an die anderen Dienste verwendet wird. Letzteres wird wie folgt implementiert (App.js):

analyzeSentence() {
    fetch('/sentiment', {
        method: 'POST',
        headers: {
            'Content-Type': 'application/json',
            'Authorization': `Bearer ${auth.getAccessToken()}` // Access Token
        },
        body: JSON.stringify({ sentence: this.textField.getValue() })
    })
        .then(response => response.json())
        .then(data => this.setState(data));
}

Um das Frontend auf die Verwendung der Tenant-Daten in Auth0 umzustellen, öffnen Sie sa-frontend/src/services/Auth.js und ersetzen Sie darin die Werte, die wir oben notiert haben (Auth.js):

const Config = {
    clientID: '{YOUR_CLIENT_ID}',
    domain:'{YOUR_DOMAIN}',
    audience: '{YOUR_AUDIENCE}',
    ingressIP: '{EXTERNAL_IP}' // Wird für die Weiterleitung nach der Authentifizierung verwendet
}

Die Anwendung ist bereit. Geben Sie Ihre Docker-ID in den folgenden Befehlen bei der Erstellung und dem Deployment der vorgenommenen Änderungen an:

$ docker build -f sa-frontend/Dockerfile 
 -t $DOCKER_USER_ID/sentiment-analysis-frontend:istio-auth0 
 sa-frontend

$ docker push $DOCKER_USER_ID/sentiment-analysis-frontend:istio-auth0

$ kubectl set image deployment/sa-frontend 
 sa-frontend=$DOCKER_USER_ID/sentiment-analysis-frontend:istio-auth0

Testen Sie die Anwendung! Sie werden zu Auth0 weitergeleitet, wo Sie sich anmelden (oder registrieren) müssen. Danach werden Sie zurück auf die Seite geleitet, von der aus authentifizierte Anfragen gestellt werden. Wenn Sie jedoch die in den ersten Teilen des Artikels erwähnten Befehle mit curl versuchen, erhalten Sie den Code 401 Status Code, der signalisiert, dass die Anfrage nicht autorisiert ist.

Gehen wir zum nächsten Schritt über – wir autorisieren die Anfragen.

Autorisierung mit Auth0

Die Authentifizierung ermöglicht es uns zu verstehen, wer der Benutzer ist, aber um herauszufinden, auf was er Zugriff hat, ist eine Autorisierung erforderlich. Istio bietet dafür ebenfalls Werkzeuge an.

Als Beispiel erstellen wir zwei Benutzergruppen (siehe das Schema unten):

Benutzer (users) — mit Zugriff nur auf die Dienste SA-WebApp und SA-Frontend;
Moderatoren (moderators) — mit Zugriff auf alle drei Dienste.

Das Konzept der Autorisierung

Um diese Gruppen zu erstellen, verwenden wir die Auth0 Authorization Erweiterung und bieten ihnen über Istio unterschiedliche Zugriffslevel an.

Installation und Konfiguration von Auth0 Authorization

Gehen Sie im Auth0-Portal zu den Erweiterungen (Extensions) und installieren Sie Auth0 Authorization. Nach der Installation gehen Sie zur Authorization Extension, und klicken Sie oben rechts auf die Konfiguration des Tenants und wählen Sie die entsprechende Menüoption (Configuration). Aktivieren Sie die Gruppen (Groups) und klicken Sie auf die Schaltfläche Regel veröffentlichen (Publish rule).

Gruppen erstellen

Gehen Sie in der Authorization Extension zu Gruppen und erstellen Sie die Gruppe Moderators. Da wir alle authentifizierten Benutzer als gewöhnliche betrachten werden, besteht keine Notwendigkeit, eine zusätzliche Gruppe für sie zu erstellen.

Wählen Sie die Gruppe Moderators, klicken Sie auf Add Members, fügen Sie Ihr Hauptkonto hinzu. Lassen Sie einige Benutzer ohne Gruppe, um sicherzustellen, dass der Zugriff für sie gesperrt ist. (Neue Benutzer können manuell über Auth0 Portal > Benutzer > Benutzer erstellen.)

Fügen Sie den Gruppenanspruch im Zugriffstoken hinzu

Benutzer sind Gruppen hinzugefügt worden, diese Information muss jedoch auch in den Zugriffstoken reflektiert werden. Um OpenID Connect zu entsprechen und gleichzeitig die benötigten Gruppen zurückzugeben, muss das Token seinen benutzerdefinierten Anspruch. Dies wird über Auth0-Regeln implementiert.

Um eine Regel zu erstellen, gehen Sie im Auth0 Portal zu Regeln, klicken Sie auf Regel erstellen und wählen Sie eine leere Regel aus den Vorlagen.

Kopieren Sie den folgenden Code und speichern Sie ihn als neue Regel Gruppenanspruch hinzufügen (namespacedGroup.js):

function (user, context, callback) {
    context.accessToken['https://sa.io/group'] = user.groups[0];
    return callback(null, user, context);
}

Hinweis: dieser Code nimmt die erste Gruppe des Benutzers, die in der Authorization Extension definiert ist, und fügt sie als benutzerdefinierten Anspruch in das Zugriffstoken hinzu (unter ihrem Namensraum, wie von Auth0 gefordert).

Gehen Sie zurück zur Seite Regeln und überprüfen Sie, ob Sie zwei Regeln in folgender Reihenfolge haben:

auth0-authorization-extension
Gruppenanspruch hinzufügen

Die Reihenfolge ist wichtig, da das Gruppenfeld asynchron die Regel erhält. auth0-authorization-extension und anschließend wird es als Claim durch die zweite Regel hinzugefügt. Dadurch entsteht ein solcher Access-Token:

{
 "https://sa.io/group": "Moderatoren",
 "iss": "https://sentiment-analysis.eu.auth0.com/",
 "sub": "google-oauth2|196405271625531691872"
 // [gekürzt zur Übersichtlichkeit]
}

Jetzt ist es notwendig, den Envoy-Proxy zur Überprüfung des Benutzerzugriffs zu konfigurieren, wobei die Gruppe aus dem Claim (https://sa.io/group) im zurückgegebenen Access-Token gezogen wird. Dies ist Thema des nächsten Abschnitts des Artikels.

Konfiguration der Autorisierung in Istio

Um die Autorisierung zu aktivieren, muss RBAC für Istio eingeschaltet werden. Hierfür verwenden wir die folgende Konfiguration:

apiVersion: "rbac.istio.io/v1alpha1"
kind: RbacConfig
metadata:
  name: default
spec:
  mode: 'ON_WITH_INCLUSION'                     # 1
  inclusion:
    services:                                   # 2
    - "sa-frontend.default.svc.cluster.local"
    - "sa-web-app.default.svc.cluster.local"
    - "sa-feedback.default.svc.cluster.local"

Erläuterungen:

1 — wir aktivieren RBAC nur für die in diesem Feld aufgelisteten Dienste und Namensräume Inclusion;
2 — wir listen unsere Dienste auf.

Wir wenden die Konfiguration mit folgendem Befehl an:

$ kubectl apply -f resource-manifests/istio/security/enable-rbac.yaml
rbacconfig.rbac.istio.io/default erstellt

Jetzt erfordern alle Dienste eine rollenbasierte Zugriffskontrolle (Role-Based Access Control). Mit anderen Worten, der Zugriff auf alle Dienste ist untersagt und führt zu einer entsprechenden Antwort. RBAC: Zugriff verweigert. Lassen Sie uns nun autorisierten Benutzern den Zugriff gewähren.

Zugriffsconfiguration für reguläre Benutzer

Alle Benutzer sollten Zugriff auf die Dienste SA-Frontend und SA-WebApp haben. Dies wird durch die folgenden Istio-Ressourcen umgesetzt:

ServiceRole — definiert die Rechte, die der Benutzer hat;
ServiceRoleBinding — legt fest, auf wen sich diese ServiceRole bezieht.

Für reguläre Benutzer gewähren wir den Zugriff auf bestimmte Dienste (servicerole.yaml):

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRole
metadata:
  name: regular-user
  namespace: default
spec:
  rules:
  - services: 
    - "sa-frontend.default.svc.cluster.local" 
    - "sa-web-app.default.svc.cluster.local"
    paths: ["*"]
    methods: ["*"]

Und über regular-user-binding wenden wir die ServiceRole auf alle Besucher der Seite an (regular-user-service-role-binding.yaml):

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRoleBinding
metadata:
  name: regular-user-binding
  namespace: default
spec:
  subjects:
  - user: "*"
  roleRef:
    kind: ServiceRole
    name: "regular-user"

Bedeutet «alle Benutzer», dass auch nicht authentifizierte Benutzer Zugriff auf die SA WebApp erhalten? Nein, die Richtlinie prüft die Gültigkeit des JWT-Tokens.

Wenden wir die Konfigurationen an:

$ kubectl apply -f resource-manifests/istio/security/user-role.yaml
servicerole.rbac.istio.io/regular-user erstellt
servicerolebinding.rbac.istio.io/regular-user-binding erstellt

Zugriffskonfiguration für Moderatoren

Für Moderatoren möchten wir den Zugang zu allen Diensten einbeziehen (mod-service-role.yaml):

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRole
metadata:
  name: mod-user
  namespace: default
spec:
  rules:
  - services: ["*"]
    paths: ["*"]
    methods: ["*"]

Aber wir möchten solche Rechte nur für Benutzer, deren Access-Token über einen Claim verfügen https://sa.io/group mit dem Wert Moderators (mod-service-role-binding.yaml):

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRoleBinding
metadata:
  name: mod-user-binding
  namespace: default
spec:
  subjects:
  - properties:
      request.auth.claims[https://sa.io/group]: "Moderatoren"
  roleRef:
    kind: ServiceRole
name: "mod-user"

Wenden wir die Konfigurationen an:

$ kubectl apply -f resource-manifests/istio/security/mod-role.yaml
servicerole.rbac.istio.io/mod-user erstellt
servicerolebinding.rbac.istio.io/mod-user-binding erstellt

Aufgrund der Cache-Mechanismen in Envoy kann es einige Minuten dauern, bis die Autorisierungsregeln wirksam werden. Danach können Sie sicherstellen, dass Benutzer und Moderatoren unterschiedliche Zugriffsrechte haben.

Zusammenfassung zu diesem Teil

Also mal ehrlich: Haben Sie irgendwo einen einfacheren, mühelos skalierbaren und sicheren Ansatz für Authentifizierung und Autorisierung gesehen?

Es benötigte lediglich drei Istio-Ressourcen (RbacConfig, ServiceRole und ServiceRoleBinding), um eine feinkörnige Kontrolle über die Authentifizierung und Autorisierung des Zugriffs von Endbenutzern auf Dienste zu erreichen.

Darüber hinaus haben wir die Verantwortung für diese Probleme auf Envoys übertragen, was zu folgendem geführt hat:

Verringerung des typischen Codes, der Sicherheitsprobleme und Bugs enthalten kann;
Reduzierung der Anzahl von Missgeschicken, bei denen ein Endpoint extern erreichbar war und dies nicht mitgeteilt wurde;
Eliminierung der Notwendigkeit, alle Services bei jeder Hinzufügung einer neuen Rolle oder Berechtigung zu aktualisieren;
sodass neue Services einfach, sicher und schnell bleiben.

Fazit

Istio ermöglicht es Teams, ihre Ressourcen auf wichtige Geschäftsaufgaben zu konzentrieren, ohne zusätzlichen Overhead für die Services zu schaffen, und bringt sie zurück zum Status von "Mikro".

Der Artikel (in drei Teilen) bietet grundlegendes Wissen und eine praktische Anleitung zum Einstieg in die Arbeit mit Istio in realen Projekten.

P.S. vom Übersetzer

Lesen Sie auch in unserem Blog:

„Zurück zu Microservices mit Istio“: Teil 1 (Einführung in die grundlegenden Funktionen), Teil 2 (Routing, Traffic-Management);
«Conduit – ein leichtgewichtiges Service Mesh für Kubernetes.»;
«Was ist ein Service Mesh und warum benötige ich es [für Cloud-Anwendungen mit Microservices]?».

Quelle: habr.com