🥇Povratak mikroservisima uz Istio. Dio 3

Napomena za prijevod.: Prvi dio Ovaj ciklus je bio posvećen upoznavanju s mogućnostima Istio i njihovoj demonstraciji u akciji, dva — fino podešavanje usmjeravanja i upravljanje mrežnim prometom. Sada se radi o sigurnosti: za demonstraciju povezanih osnovnih funkcija autor koristi identity servis Auth0, no po analogiji s njim mogu se postaviti i drugi pružatelji.

Postavili smo Kubernetes klaster u kojem smo implementirali Istio i primjer mikroservisne aplikacije Sentiment Analysis — tako su prikazane mogućnosti Istio.

Pomoću Istio uspjeli smo zadržati malu veličinu servisa, jer ne trebaju implementirati takve 'slojeve' kao ponovne pokušaje (Retries), vremenska ograničenja (Timeouts), automatske prekidače (Circuit Breakers), praćenje (Tracing), nadzor (Monitoring). Osim toga, primijenili smo tehnike naprednog testiranja i implementacije: A/B testiranje, zrcaljenje i kanarinski izlasci.

U novom materijalu razmotrit ćemo završne slojeve na putu prema poslovnoj vrijednosti: autentifikaciju i autorizaciju — i u Istio je to potpuni užitak!

Autentifikacija i autorizacija u Istio

Nikada ne bih povjerovao da ću se inspirirati autentifikacijom i autorizacijom. Što to tehnološki može ponuditi Istio kako bi ove teme postale zanimljive i čak vas inspirirale?

Odgovor je jednostavan: Istio prebacuje odgovornost za ove mogućnosti s vaših servisa na proxy Envoy. U trenutku kada zahtjevi dosegnu servise, oni su već autentificirani i autorizirani, pa vam ostaje samo pisati korisni poslovni kod.

Zvuči dobro? Pogledajmo iznutra!

Autentifikacija s Auth0

Kao server za upravljanje identifikacijom i pristupom koristit ćemo Auth0, koji ima probnu verziju, intuitivan je za korištenje i jednostavno mi se sviđa. Usput, iste principe možemo primijeniti i na bilo koju drugu implementaciju OpenID Connect: KeyCloak, IdentityServer i mnoge druge.

Za početak, prijavite se na Auth0 Portal sa svojim računom, kreirajte tenant (tenant — 'iznajmljivač', logička jedinica izolacije, više informacija u dokumentaciju — napomena prev.) i idite na Applications > Default App, odabirući Domena, 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

Imati takav resurs, Pilot (jedna od tri osnovne komponente Control Plane u Istio — napomena prev.) konfigurira Envoye za autentifikaciju zahtjeva prije nego što ih preusmjeri na servise: sa-web-app i sa-feedback. U isto vrijeme, konfiguracija se ne primjenjuje na Envoye servisa sa-frontend, što nam omogućuje da ostavimo frontend neautentificiranim. Da biste primijenili politiku (Policy), izvršite naredbu:

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

Vratite se na stranicu i izvršite zahtjev — vidjet ćete da je završio statusom 401 Neautorizirano. Sada ćemo preusmjeriti korisnike frontenda na autentifikaciju s Auth0.

Autentifikacija zahtjeva s Auth0

Kako biste autentificirali zahtjeve krajnjeg korisnika, potrebno je stvoriti API u Auth0, koji će predstavljati autentificirane servise (reviews, details i ratings). Da biste stvorili API, idite na Auth0 Portal > APIs > Create API i popunite obrazac:

Važna informacija ovdje je Identifier, koji ćemo kasnije koristiti u skripti. Zapišimo ga ovako:

Audience: {YOUR_AUDIENCE}

Preostali potrebni podaci nalaze se na Auth0 Portalu u odjeljku Applications — odaberite Test Application (automatski se kreira zajedno s API-em).

Ovdje ćemo zabilježiti:

Domena: {YOUR_DOMAIN}
Client Id: {YOUR_CLIENT_ID}

Pomaknite se do Test Application do tekstualnog polja Allowed Callback URLs (dozvoljeni URL-ovi za callback), u kojem ćemo navesti URL na koji bi poziv trebao biti poslan nakon završetka autentifikacije. U našem slučaju to je:

http://{EXTERNAL_IP}/callback

A za Allowed Logout URLs (dozvoljeni URL-ovi za odjavu) dodajmo:

http://{EXTERNAL_IP}/logout

Pređimo na frontend.

Ažuriranje frontenda

Prebacite se na granu auth0 repozitorija [istio-mastery]. U ovoj grani je kod frontenda izmijenjen tako da preusmjerava korisnike na Auth0 radi autentifikacije i koristi JWT-token u zahtjevima prema ostalim servisima. Ovo je realizirano 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 biste prebacili frontend na korištenje podataka tena u Auth0, otvorite sa-frontend/src/services/Auth.js i zamijenite u njemu vrijednosti koje smo zapisali iznad (Auth.js):

const Config = {
    clientID: '{YOUR_CLIENT_ID}',
    domain:'{YOUR_DOMAIN}',
    audience: '{YOUR_AUDIENCE}',
    ingressIP: '{EXTERNAL_IP}' // Koristi se za preusmjeravanje nakon autentifikacije
}

Aplikacija je spremna. Unesite svoj Docker ID u naredbama ispod prilikom izgradnje i implementacije učinjenih 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! Bit ćete preusmjereni na Auth0, gdje se morate prijaviti (ili registrirati), nakon čega ćete biti poslani natrag na stranicu s koje će se već obavljati autentificirani zahtjevi. Ako pokušate s navedenim naredbama u prvom dijelu članka koristeći curl — dobit ćete kod 401 Status Code, što signalizira da zahtjev nije autoriziran.

Idemo na sljedeći korak — autorizirajmo zahtjeve.

Autorizacija s Auth0

Autentifikacija nam omogućava da shvatimo tko je korisnik, ali da bismo saznali kojem ima pristup, potrebna je autorizacija. Istio nudi alate i za to.

Kao primjer, kreirat ćemo dvije korisničke grupe (vidi na dijagramu ispod):

Korisnici (korisnici) — s pristupom samo servisima SA-WebApp i SA-Frontend;
Moderatori (moderatori) — s pristupom svim trima servisima.

Koncept autorizacije

Za kreiranje ovih grupa iskoristit ćemo Auth0 Authorization ekstenziju i putem Istio-a im omogućiti različite razine pristupa.

Instalacija i konfiguracija Auth0 Authorization

Na Auth0 portalu idite na ekstenzije (Ekstenzije) i instalirajte Auth0 Authorization. Nakon instalacije, idite do Authorization Extension, zatim idite na konfiguraciju tena i odaberite odgovarajuću opciju iz izbornika (Konfiguracija). Aktivirajte grupe (Grupe) i pritisnite dugme za objavu pravila (Objavi pravilo).

Kreiranje grupa

U Authorization Extension idite na Grupe i kreirajte grupu Moderatori. Budući da ćemo sve autentificirane korisnike smatrati običnim, potreba za stvaranjem dodatne grupe za njih nije potrebna.

Odaberite grupu Moderatori, pritisnite na Dodaj članove, dodajte svoj osnovni račun. Ostavite neke korisnike bez ikakve grupe kako biste se uvjerili da im je pristup zabranjen. (Nove korisnike možete stvoriti ručno putem Auth0 Portal > Korisnici > Kreiraj korisnika.)

Dodajte Group Claim u Access Token

Korisnici su dodani u grupe, međutim, te informacije trebaju biti odražene i u tokenima za pristup. Da bi se pridržavali OpenID Connect i u isto vreme vraćali potrebne grupe, token će morati dodavati svoj custom claim. Ovo se implementira preko pravila Auth0.

Za kreiranje pravila pređite na Auth0 Portal na Rules, pritisnite na Kreiraj pravilo i odaberite prazno pravilo iz šablona.

Kopirajte donji kod i sačuvajte ga kao novo pravilo Dodaj grupu claim (namespacedGroup.js):

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

Napomena: ovaj kod uzima prvu grupu korisnika, određenu u Authorization Extension, i dodaje je u access-token kao custom claim (u svom imenskom prostoru, kao što zahteva Auth0).

Vratite se na stranicu Rules i proverite da imate dva pravila zapisana u sledećem redosledu:

auth0-authorization-extension
Dodaj grupu claim

Redosled je važan, jer polje grupe asinkrono dobija pravilo auth0-authorization-extension i nakon toga se dodaje kao claim drugim pravilom. Kao rezultat se dobija ovakav access-token:

{
 "https://sa.io/group": "Moderators",
 "iss": "https://sentiment-analysis.eu.auth0.com/",
 "sub": "google-oauth2|196405271625531691872"
 // [skraćeno za uvid]
}

Sada je potrebno podesiti Envoy proxy za proveru pristupa korisnika, za šta će se grupa izvući iz claim-a (https://sa.io/group) u vraćenom access-tokenu. Ovo je tema za sledeći deo članka.

Konfiguracija autorizacije u Istio

Da bi autorizacija funkcionisala, potrebno je uključiti RBAC za Istio. Za to ćemo koristiti sledeć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 — aktiviramo RBAC samo za usluge i imenska prostore navedene u polju Inclusion;
2 — navodimo listu naših usluga.

Primeni konfiguraciju sledećom komandom:

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

Sada sve usluge zahtevaju upravljanje pristupom zasnovano na rolama (Role-Based Access Control). Drugim rečima, pristup svim uslugama je zabranjen i dovest će do odgovora RBAC: pristup odbijen. Sada ćemo dozvoliti pristup autorizovanim korisnicima.

Konfiguracija pristupa za obične korisnike

Svi korisnici treba da imaju pristup uslugama SA-Frontend i SA-WebApp. Ovo se ostvaruje pomoću sledećih resursa Istio:

ServiceRole — određuje prava koja korisnik ima;
ServiceRoleBinding — određuje kome se ta ServiceRole odnosi.

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: ["*"]

A preko regular-user-binding primijenit ćemo 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"

Znači li „svi korisnici“ da će i neautentificirani korisnici dobiti pristup SA WebApp-u? Ne, politika će provjeriti valjanost JWT tokena.

Primijenit ćemo 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 uslugama (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 access token sadrži claim https://sa.io/group s vrijednošću Moderatori (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"

Primijenit ćemo 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 envoyima, može proći nekoliko minuta da pravila autorizacije stupe na snagu. Nakon toga možete potvrditi da korisnici i moderatori imaju različite razine pristupa.

Zaključak za ovaj dio

Pa ozbiljno: jeste li negdje vidjeli jednostavniji, ne zahtjevan, skalabilan i siguran pristup autentifikaciji i autorizaciji?

Samo tri resursa Istio (RbacConfig, ServiceRole i ServiceRoleBinding) bila su potrebna za postizanje fine kontrole nad autentifikacijom i autorizacijom pristupa krajnjih korisnika uslugama.

Osim toga, prebacili smo brigu o ovim problemima iz naših usluga u envoy-e, postignuvši:

smanjenje količine standardnog koda u kojem mogu biti sigurnosni problemi i greške;
smanjenje broja glupih situacija u kojima je jedan endpoint bio dostupan izvana i zaboravio obavijestiti o tome;
uklanjanje potrebe za ažuriranjem svih servisa pri svakom dodavanju nove uloge ili prava;
da novi servisi ostanu jednostavni, sigurni i brzi.