🥇Tilbage til mikrotjenester med Istio. Del 3

Bemærk. overs.: Den første del denne serie var viet til at lære Istios evner at kende og demonstrere dem i aktion, sekund — finjusteret routing og netværkstrafikstyring. Nu vil vi tale om sikkerhed: For at demonstrere de grundlæggende funktioner relateret til det, bruger forfatteren Auth0-identitetstjenesten, men andre udbydere kan konfigureres på lignende måde.

Vi oprettede en Kubernetes-klynge, hvor vi implementerede Istio og et eksempel på en mikroserviceapplikation, Sentiment Analysis, for at demonstrere Istios evner.

Med Istio var vi i stand til at holde vores tjenester små, fordi de ikke behøver at implementere lag som Genforsøg, Timeouts, Circuit Breakers, Tracing, Monitoring. . Derudover brugte vi avancerede test- og implementeringsteknikker: A/B-test, spejling og udrulninger af kanariefugle.

I det nye materiale vil vi beskæftige os med de sidste lag på vejen til forretningsværdi: autentificering og autorisation - og i Istio er det en sand fornøjelse!

Autentificering og autorisation i Istio

Jeg ville aldrig have troet, at jeg ville blive inspireret af autentificering og autorisation. Hvad kan Istio tilbyde fra et teknologisk perspektiv for at gøre disse emner sjove og endnu mere inspirerende for dig?

Svaret er enkelt: Istio flytter ansvaret for disse funktioner fra dine tjenester til Envoy-proxyen. På det tidspunkt, hvor anmodningerne når frem til tjenesterne, er de allerede blevet godkendt og godkendt, så det eneste, du skal gøre, er at skrive en forretningsnyttig kode.

Lyder godt? Lad os tage et kig indenfor!

Godkendelse med Auth0

Som server til identitets- og adgangsstyring vil vi bruge Auth0, som har en prøveversion, er intuitiv at bruge og jeg kan simpelthen lide det. De samme principper kan dog anvendes på alle andre OpenID Connect implementeringer: KeyCloak, IdentityServer og mange andre.

Gå til for at komme i gang Auth0 portal med din konto, opret en lejer (lejer - "lejer", logisk isolationsenhed, for flere detaljer se dokumentation - ca. oversættelse) og gå til Applikationer > Standardappvælger Domæne, som vist på skærmbilledet nedenfor:

Angiv dette domæne i filen resource-manifests/istio/security/auth-policy.yaml (kilde):

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

Med sådan en ressource, Pilot (en af de tre grundlæggende kontrolplankomponenter i Istio - ca. oversættelse) konfigurerer Envoy til at godkende anmodninger, før de videresendes til tjenester: sa-web-app и sa-feedback. Samtidig anvendes konfigurationen ikke på serviceudsendinge sa-frontend, hvilket giver os mulighed for at forlade frontenden uautoriseret. For at anvende politikken skal du køre kommandoen:

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

Gå tilbage til siden og lav en anmodning - du vil se, at den ender med status 401 Uautoriseret. Lad os nu omdirigere frontend-brugere til at godkende med Auth0.

Godkendelse af anmodninger med Auth0

For at autentificere slutbrugeranmodninger skal du oprette en API i Auth0, der repræsenterer de godkendte tjenester (anmeldelser, detaljer og vurderinger). For at oprette en API skal du gå til Auth0 Portal > API'er > Opret API og udfyld formularen:

Den vigtige information her er Identifier, som vi vil bruge senere i scriptet. Lad os skrive det ned sådan her:

Publikum: {YOUR_AUDIENCE}

De resterende detaljer, vi har brug for, er placeret på Auth0-portalen i sektionen Applikationer - Vælg Test applikation (oprettet automatisk sammen med API'en).

Her vil vi skrive:

Domæne: {DIT_DOMÆNE}
Kunde-id: {YOUR_CLIENT_ID}

Rul til Test applikation til tekstfelt Tilladte tilbagekalds-URL'er (løste URL'er for tilbagekaldet), hvori vi angiver den URL, hvortil opkaldet skal sendes, efter at autentificeringen er gennemført. I vores tilfælde er det:

http://{EXTERNAL_IP}/callback

Og for Tilladte logout-URL'er (tilladte webadresser til at logge ud) tilføj:

http://{EXTERNAL_IP}/logout

Lad os gå videre til frontend.

Frontend opdatering

Skift til filial auth0 depot [istio-mastery]. I denne gren ændres frontend-koden for at omdirigere brugere til Auth0 for godkendelse og bruge JWT-tokenet i anmodninger til andre tjenester. Sidstnævnte implementeres som følger (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));
}

For at ændre frontend til at bruge lejerdata i Auth0, skal du åbne sa-frontend/src/services/Auth.js og erstatte værdierne i det, som vi skrev ovenfor (Auth.js):

const Config = {
    clientID: '{YOUR_CLIENT_ID}',
    domain:'{YOUR_DOMAIN}',
    audience: '{YOUR_AUDIENCE}',
    ingressIP: '{EXTERNAL_IP}' // Используется для редиректа после аутентификации
}

Ansøgningen er klar. Angiv dit Docker ID i kommandoerne nedenfor, når du bygger og implementerer de foretagne ændringer:

$ 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

Prøv appen! Du bliver omdirigeret til Auth0, hvor du skal logge ind (eller registrere dig), hvorefter du bliver sendt tilbage til siden, hvorfra der vil blive foretaget allerede godkendte anmodninger. Hvis du prøver kommandoerne nævnt i de første dele af artiklen med curl, får du koden 401 Statuskode, hvilket signalerer, at anmodningen ikke er godkendt.

Lad os tage det næste skridt - godkend anmodninger.

Autorisation med Auth0

Autentificering giver os mulighed for at forstå, hvem en bruger er, men der kræves autorisation for at vide, hvad de har adgang til. Istio tilbyder også værktøjer til dette.

Lad os som et eksempel oprette to brugergrupper (se diagrammet nedenfor):

Medlemmer (brugere) — kun med adgang til SA-WebApp og SA-Frontend-tjenester;
Moderatorer (moderatorer) — med adgang til alle tre tjenester.

Autorisation koncept

For at oprette disse grupper vil vi bruge Auth0 Authorization-udvidelsen og bruge Istio til at give dem forskellige adgangsniveauer.

Installation og konfiguration af Auth0 Authorization

I Auth0-portalen skal du gå til udvidelser (Udvidelser) og installer Auth0 Autorisation. Efter installationen skal du gå til Autorisationsudvidelse, og der - til lejerens konfiguration ved at klikke øverst til højre og vælge den relevante menuindstilling (Konfiguration). Aktiver grupper (Grupper) og klik på knappen Udgiv regel (Udgiv regel).

Opret grupper

Gå til Autorisationsudvidelse Grupper og oprette en gruppe Redaktører. Da vi vil behandle alle godkendte brugere som almindelige brugere, er det ikke nødvendigt at oprette en ekstra gruppe for dem.

Vælg en gruppe Redaktører, Tryk på Tilføj medlemmer, tilføj din hovedkonto. Efterlad nogle brugere uden nogen gruppe for at sikre, at de nægtes adgang. (Nye brugere kan oprettes manuelt via Auth0 Portal > Brugere > Opret bruger.)

Tilføj gruppekrav til adgangstoken

Brugere er blevet føjet til grupper, men disse oplysninger skal også afspejles i adgangstokens. For at overholde OpenID Connect og samtidig returnere de grupper, vi har brug for, skal tokenet tilføje sit eget tilpasset krav. Implementeret gennem Auth0-regler.

For at oprette en regel, gå til Auth0 Portal til Regler, Tryk på Opret regel og vælg en tom regel fra skabelonerne.

Kopier koden nedenfor og gem den som en ny regel Tilføj gruppekrav (namespacedGroup.js):

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

Bemærk: Denne kode tager den første brugergruppe defineret i autorisationsudvidelsen og føjer den til adgangstokenet som et brugerdefineret krav (under dets navneområde, som krævet af Auth0).

Vend tilbage til siden Regler og tjek, at du har to regler skrevet i følgende rækkefølge:

auth0-autorisation-extension
Tilføj gruppekrav

Rækkefølgen er vigtig, fordi gruppefeltet modtager reglen asynkront auth0-autorisation-extension og derefter tilføjes det som et krav efter den anden regel. Resultatet er et adgangstoken som dette:

{
 "https://sa.io/group": "Moderators",
 "iss": "https://sentiment-analysis.eu.auth0.com/",
 "sub": "google-oauth2|196405271625531691872"
 // [сокращено для наглядности]
}

Nu skal du konfigurere Envoy-proxyen til at kontrollere brugeradgang, for hvilken gruppen vil blive trukket fra krav (https://sa.io/group) i det returnerede adgangstoken. Dette er emnet for næste afsnit af artiklen.

Autorisationskonfiguration i Istio

For at autorisation skal virke, skal du aktivere RBAC for Istio. For at gøre dette bruger vi følgende 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"

Forklaring:

1 — aktiver kun RBAC for tjenester og navneområder, der er angivet i feltet Inclusion;
2 — vi viser en liste over vores tjenester.

Lad os anvende konfigurationen med følgende kommando:

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

Alle tjenester kræver nu rollebaseret adgangskontrol. Med andre ord er adgang til alle tjenester forbudt og vil resultere i et svar RBAC: access denied. Lad os nu tillade adgang til autoriserede brugere.

Adgang til konfiguration for almindelige brugere

Alle brugere skal have adgang til SA-Frontend- og SA-WebApp-tjenesterne. Implementeret ved hjælp af følgende Istio-ressourcer:

Servicerolle — bestemmer de rettigheder, som brugeren har;
ServiceRoleBinding — bestemmer, hvem denne ServiceRole tilhører.

For almindelige brugere vil vi tillade adgang til visse tjenester (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: ["*"]

Og efter regular-user-binding anvende ServiceRole på alle sidebesøgende (regular-user-service-rolle-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"

Betyder "alle brugere", at uautoriserede brugere også vil have adgang til SA WebApp? Nej, politikken vil kontrollere gyldigheden af JWT-tokenet.

Lad os anvende konfigurationerne:

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

Adgang til konfiguration for moderatorer

For moderatorer ønsker vi at aktivere adgang til alle tjenester (mod-service-rolle.yaml):

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

Men vi ønsker kun sådanne rettigheder for de brugere, hvis adgangstoken indeholder krav https://sa.io/group med betydningen Moderators (mod-service-rolle-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]: "Moderators"
  roleRef:
    kind: ServiceRole
name: "mod-user"

Lad os anvende konfigurationerne:

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

På grund af caching i udsendinge kan det tage et par minutter, før godkendelsesreglerne træder i kraft. Du kan derefter sikre, at brugere og moderatorer har forskellige adgangsniveauer.

Konklusion på denne del

Men seriøst, har du nogensinde set en enklere, ubesværet, skalerbar og sikker tilgang til godkendelse og godkendelse?

Kun tre Istio-ressourcer (RbacConfig, ServiceRole og ServiceRoleBinding) var nødvendige for at opnå finmasket kontrol over godkendelse og autorisation af slutbrugeres adgang til tjenester.

Derudover har vi taget os af disse problemer fra vores udsendingstjenester og opnået:

at reducere mængden af generisk kode, der kan indeholde sikkerhedsproblemer og fejl;
at reducere antallet af dumme situationer, hvor et endepunkt viste sig at være tilgængeligt udefra og glemte at rapportere det;
eliminerer behovet for at opdatere alle tjenester, hver gang en ny rolle eller rettighed tilføjes;
at nye tjenester forbliver enkle, sikre og hurtige.

Output

Istio giver teams mulighed for at fokusere deres ressourcer på forretningskritiske opgaver uden at føje overhead til tjenesterne og vende dem tilbage til mikrostatus.

Artiklen (i tre dele) gav grundlæggende viden og færdige praktiske instruktioner til at komme i gang med Istio i rigtige projekter.

PS fra oversætteren

Læs også på vores blog:

"Tilbage til mikrotjenester med Istio": del 1 (introduktion til hovedfunktionerne), del 2 (ruteplanlægning, trafikkontrol);
«Conduit - letvægts servicenet til Kubernetes";
«Hvad er et servicemesh, og hvorfor har jeg brug for det [til en cloud-applikation med mikrotjenester]?'.

Kilde: www.habr.com

Tilbage til mikrotjenester med Istio. Del 3