Povratak na mikroservise sa Istiom. Dio 3

Bilješka. transl.: Prvi dio ova serija je bila posvećena upoznavanju mogućnosti Istia i demonstriranju ih na djelu, drugi — fino podešeno rutiranje i upravljanje mrežnim prometom. Sada ćemo razgovarati o sigurnosti: da bi demonstrirao osnovne funkcije povezane s njom, autor koristi uslugu identiteta Auth0, ali na sličan način se mogu konfigurirati i drugi provajderi.

Postavili smo Kubernetes klaster u koji smo implementirali Istio i primjer mikroservisne aplikacije, Sentiment Analysis, kako bismo demonstrirali Istio mogućnosti.

Uz Istio, uspjeli smo zadržati naše usluge male jer ne trebaju implementirati slojeve kao što su Retries, Timeouts, Circuit Breakers, Tracing, Monitoring. Osim toga, koristili smo napredne tehnike testiranja i implementacije: A/B testiranje, zrcaljenje i kanarinsko uvođenje.

U novom materijalu bavit ćemo se završnim slojevima na putu do poslovne vrijednosti: autentikacijom i autorizacijom - a u Istiu je to pravo zadovoljstvo!

Autentifikacija i autorizacija u Istio

Nikada ne bih vjerovao da ću biti inspirisan autentifikacijom i autorizacijom. Šta Istio može ponuditi iz perspektive tehnologije kako bi ove teme bile zabavne i, još više, inspirativne za vas?

Odgovor je jednostavan: Istio prebacuje odgovornost za ove mogućnosti sa vaših usluga na Envoy proxy. U trenutku kada zahtjevi stignu do servisa, oni su već provjereni i autorizirani, tako da sve što trebate učiniti je napisati poslovni kod.

Zvuči dobro? Hajde da pogledamo unutra!

Autentifikacija sa Auth0

Kao server za upravljanje identitetom i pristupom koristit ćemo Auth0, koji ima probnu verziju, intuitivan je za korištenje i jednostavno mi se sviđa. Međutim, isti principi se mogu primijeniti na bilo koji drugi Implementacije OpenID Connect: KeyCloak, IdentityServer i mnogi drugi.

Za početak idite na Auth0 Portal sa svojim nalogom, kreirajte zakupca (stanar - „stanar“, logička jedinica izolacije, za više detalja vidi dokumentaciju - cca. prevod) i idi na Aplikacije > Zadana aplikacijaodabirom područje, kao što je prikazano na slici ispod:

Navedite ovu domenu u datoteci resource-manifests/istio/security/auth-policy.yaml (izvor):

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

Sa takvim resursom, Pilote (jedna od tri osnovne komponente upravljačkog plana u Istio-u - pribl. transl.) konfigurira Envoy za provjeru autentičnosti zahtjeva prije nego što ih proslijedi uslugama: sa-web-app и sa-feedback. U isto vrijeme, konfiguracija se ne primjenjuje na usluge Izaslanici sa-frontend, što nam omogućava da frontend ostavimo neautorizovanim. Da biste primijenili Politiku, pokrenite naredbu:

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

Vratite se na stranicu i napravite zahtjev - vidjet ćete da se završava statusom 401 Neovlašćeno. Sada preusmjerimo frontend korisnike na autentifikaciju pomoću Auth0.

Provjera autentičnosti zahtjeva sa Auth0

Za provjeru autentičnosti zahtjeva krajnjih korisnika, potrebno je da kreirate API u Auth0 koji će predstavljati provjerene usluge (recenzije, detalji i ocjene). Da kreirate API, idite na Auth0 Portal > API-ji > Kreiraj API i popunite formular:

Važna informacija ovdje je identifikator, koji ćemo koristiti kasnije u skripti. Hajde da to zapišemo ovako:

• publika: {YOUR_AUDIENCE}

Preostali detalji koji su nam potrebni nalaze se na Auth0 portalu u odjeljku Aplikacije — izaberite Test Application (kreira se automatski zajedno sa API-jem).

Ovdje ćemo napisati:

• područje: {YOUR_DOMAIN}
• Id. klijenta: {YOUR_CLIENT_ID}

Skrolujte do Test Application u tekstualno polje Dozvoljeni URL-ovi povratnog poziva (razriješeni URL-ovi za povratni poziv), u kojem navodimo URL na koji poziv treba biti poslan nakon što je autentifikacija završena. U našem slučaju to je:

http://{EXTERNAL_IP}/callback

I za Dozvoljeni URL-ovi za odjavu (dozvoljeni URL-ovi za odjavu) dodajte:

http://{EXTERNAL_IP}/logout

Pređimo na frontend.

Frontend update

Prebacite se na granu auth0 spremište [istio-mastery]. U ovoj grani, frontend kod se mijenja kako bi se korisnici preusmjerili na Auth0 radi provjere autentičnosti i koristili JWT token u zahtjevima za druge usluge. Ovo posljednje se implementira na sljedeći način (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));
}

Da promijenite frontend da koristi podatke stanara u Auth0, otvorite sa-frontend/src/services/Auth.js i zamijenite u njemu vrijednosti koje smo gore napisali (Auth.js):

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

Aplikacija je spremna. Navedite svoj Docker ID u naredbama u nastavku prilikom izrade i implementacije napravljenih promjena:

$ 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

Isprobajte aplikaciju! Bićete preusmjereni na Auth0, gdje se trebate prijaviti (ili registrovati), nakon čega ćete biti vraćeni na stranicu sa koje će biti napravljeni već autentifikovani zahtjevi. Ako isprobate naredbe spomenute u prvim dijelovima članka s curl-om, dobit ćete kod 401 Status Code, signalizirajući da zahtjev nije ovlašten.

Idemo na sljedeći korak - autoriziranje zahtjeva.

Autorizacija sa Auth0

Autentifikacija nam omogućava da razumijemo ko je korisnik, ali je potrebna autorizacija da bismo znali čemu ima pristup. Istio također nudi alate za ovo.

Kao primjer, napravimo dvije korisničke grupe (pogledajte dijagram ispod):

• korisnici (korisnici) — sa pristupom samo servisima SA-WebApp i SA-Frontend;
• Moderatori (moderatori) — sa pristupom sve tri usluge.

Koncept autorizacije

Da bismo kreirali ove grupe, koristit ćemo Auth0 Authorization ekstenziju i koristiti Istio da im omogućimo različite razine pristupa.

Instalacija i konfiguracija Auth0 Autorizacije

Na portalu Auth0 idite na ekstenzije (Ekstenzije) i instalirajte Auth0 Autorizacija. Nakon instalacije idite na Proširenje autorizacije, a tamo - do konfiguracije stanara tako što ćete kliknuti u gornjem desnom uglu i odabrati odgovarajuću opciju menija (Konfiguracija). Aktivirajte grupe (grupe) i kliknite na dugme za objavljivanje pravila (Pravilo objave).

Kreiranje grupa

U Proširenje autorizacije idite na Grupe i kreirajte grupu Moderatori. Budući da ćemo sve autentificirane korisnike tretirati kao obične korisnike, nema potrebe za kreiranjem dodatne grupe za njih.

Odaberite grupu Moderatori, Pritisnite Dodaj članove, dodajte svoj glavni račun. Ostavite neke korisnike bez ikakve grupe kako biste bili sigurni da im je zabranjen pristup. (Novi korisnici se mogu kreirati ručno putem Auth0 Portal > Korisnici > Kreiraj korisnika.)

Dodajte grupno potraživanje tokenu za pristup

Korisnici su dodani u grupe, ali ove informacije također moraju biti odražene u tokenima za pristup. Da bi se uskladili sa OpenID Connect i u isto vrijeme vratili grupe koje su nam potrebne, token će morati dodati svoj vlastiti prilagođeni zahtjev. Implementirano kroz Auth0 pravila.

Da kreirate pravilo, idite na Auth0 Portal za Pravila, Pritisnite Stvori pravilo i izaberite prazno pravilo iz šablona.

Kopirajte kod ispod i sačuvajte ga kao novo pravilo Dodaj grupni zahtjev (namespacedGroup.js):

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

primjedba: Ovaj kod uzima prvu korisničku grupu definiranu u proširenju autorizacije i dodaje je tokenu pristupa kao prilagođeni zahtjev (u okviru svog imenskog prostora, kako zahtijeva Auth0).

Povratak na stranicu Pravila i provjerite da li imate dva pravila napisana sljedećim redoslijedom:

• auth0-proširenje-autorizacija
• Dodaj grupni zahtjev

Redoslijed je važan jer polje grupe prima pravilo asinhrono auth0-proširenje-autorizacija a nakon toga se dodaje kao tvrdnja po drugom pravilu. Rezultat je pristupni token poput ovog:

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

Sada morate konfigurirati Envoy proxy za provjeru pristupa korisnika, zbog čega će grupa biti povučena iz zahtjeva (https://sa.io/group) u vraćenom pristupnom tokenu. Ovo je tema za sljedeći dio članka.

Konfiguracija autorizacije u Istio

Da bi autorizacija radila, morate omogućiti RBAC za Istio. Da bismo to učinili, koristit ćemo sljedeću konfiguraciju:

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" 

Objašnjenja:

• 1 — omogući RBAC samo za usluge i prostore imena navedene u polju Inclusion;
• 2 — navodimo listu naših usluga.

Primijenimo konfiguraciju sljedećom naredbom:

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

Sve usluge sada zahtijevaju kontrolu pristupa zasnovanu na ulogama. Drugim riječima, pristup svim uslugama je zabranjen i rezultirat će odgovorom RBAC: access denied. Sada dozvolimo pristup ovlaštenim korisnicima.

Konfiguracija pristupa za obične korisnike

Svi korisnici moraju imati pristup uslugama SA-Frontend i SA-WebApp. Implementirano korištenjem sljedećih Istio resursa:

• ServiceRole — utvrđuje prava koja korisnik ima;
• ServiceRoleBinding — određuje kome pripada ova ServiceRole.

Za obične korisnike omogućit ćemo pristup određenim uslugama (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: ["*"]

I kroz regular-user-binding primijeniti ServiceRole na sve posjetitelje stranice (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"

Da li "svi korisnici" znači da će korisnici bez autentifikacije također imati pristup SA WebApp-u? Ne, politika će provjeriti valjanost JWT tokena.

Primijenimo konfiguracije:

$ 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

Konfiguracija pristupa za moderatore

Za moderatore želimo omogućiti pristup svim servisima (mod-service-role.yaml):

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

Ali želimo takva prava samo za one korisnike čiji pristupni token sadrži zahtjev https://sa.io/group sa značenjem 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]: "Moderators"
  roleRef:
    kind: ServiceRole
name: "mod-user" 

Primijenimo konfiguracije:

$ 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

Zbog keširanja u poslanicima, može proći nekoliko minuta da pravila autorizacije stupe na snagu. Tada možete osigurati da korisnici i moderatori imaju različite nivoe pristupa.

Zaključak o ovom dijelu

Ozbiljno, jeste li ikada vidjeli jednostavniji, lakši, skalabilan i siguran pristup autentifikaciji i autorizaciji?

Samo tri Istio resursa (RbacConfig, ServiceRole i ServiceRoleBinding) su bila potrebna da bi se postigla fino zrnasta kontrola nad autentifikacijom i autorizacijom pristupa krajnjeg korisnika uslugama.

Osim toga, mi smo se pobrinuli za ova pitanja iz naših usluga izaslanika, postižući:

• smanjenje količine generičkog koda koji može sadržavati sigurnosne probleme i greške;
• smanjenje broja glupih situacija u kojima se jedna krajnja tačka pokazala kao dostupna izvana i zaboravila je prijaviti;
• eliminisanje potrebe za ažuriranjem svih usluga svaki put kada se doda nova uloga ili pravo;
• da nove usluge ostanu jednostavne, sigurne i brze.

zaključak

Istio omogućava timovima da fokusiraju svoje resurse na poslovne kritične zadatke bez dodavanja troškova uslugama, vraćajući ih u mikro status.

Članak (u tri dijela) pruža osnovna znanja i gotove praktične upute za početak korištenja Istio-a u stvarnim projektima.

PS od prevodioca

Pročitajte i na našem blogu:

• "Povratak na mikroservise sa Istiom": dio 1 (uvod u glavne karakteristike), dio 2 (usmjeravanje, kontrola saobraćaja);
• «Conduit - lagana servisna mreža za Kubernetes»;
• «Šta je servisna mreža i zašto mi je potrebna [za aplikaciju u oblaku sa mikroservisima]?".

izvor: www.habr.com