Nazaj k mikrostoritvam z Istio. 3. del

Opomba. prevod: Prvi del ta serija je bila namenjena spoznavanju zmožnosti Istio in njihovi predstavitvi v akciji, Drugi — natančno nastavljeno usmerjanje in upravljanje omrežnega prometa. Zdaj bomo govorili o varnosti: za predstavitev osnovnih funkcij, povezanih z njo, avtor uporablja storitev identitete Auth0, vendar je druge ponudnike mogoče konfigurirati na podoben način.

Vzpostavili smo gručo Kubernetes, v kateri smo namestili Istio in primer mikrostoritvene aplikacije Sentiment Analysis, da bi prikazali zmožnosti Istia.

Z Istio smo lahko naše storitve ohranili majhne, ​​ker jim ni treba implementirati plasti, kot so ponovni poskusi, časovne omejitve, prekinjevalci, sledenje, spremljanje. Poleg tega smo uporabili napredne tehnike testiranja in uvajanja: A/B testiranje, zrcaljenje in kanarične uvedbe.

V novem gradivu se bomo ukvarjali z zadnjimi plastmi na poti do poslovne vrednosti: avtentikacijo in avtorizacijo – in v Istiu je to pravo veselje!

Avtentikacija in avtorizacija v Istio

Nikoli ne bi verjel, da me bosta navdihnila avtentikacija in avtorizacija. Kaj lahko Istio ponudi s tehnološkega vidika, da bodo te teme za vas zabavne in še bolj navdihujoče?

Odgovor je preprost: Istio prelaga odgovornost za te zmogljivosti z vaših storitev na posrednika Envoy. Ko zahteve dosežejo storitve, so že overjene in avtorizirane, zato morate le napisati poslovno uporabno kodo.

Zveni dobro? Poglejmo notri!

Preverjanje pristnosti z Auth0

Kot strežnik za upravljanje identitete in dostopa bomo uporabljali Auth0, ki ima preizkusno različico, je intuitiven za uporabo in mi je enostavno všeč. Vendar se lahko enaka načela uporabijo za katero koli drugo Implementacije OpenID Connect: KeyCloak, IdentityServer in številni drugi.

Za začetek pojdite na Portal Auth0 s svojim računom ustvarite najemnika (najemnik - "najemnik", logična enota izolacije, za več podrobnosti glej dokumentacijo — pribl. prev.) in pojdi na Aplikacije > Privzeta aplikacijaizbiro Domena, kot je prikazano na spodnjem posnetku zaslona:

Določite to domeno v datoteki resource-manifests/istio/security/auth-policy.yaml (vir):

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

S takim virom, Pilot (ena od treh osnovnih komponent Control Plane v Istio - pribl. prev.) konfigurira Envoy za preverjanje pristnosti zahtev, preden jih posreduje storitvam: sa-web-app и sa-feedback. Hkrati se konfiguracija ne uporablja za storitev Envoys sa-frontend, kar nam omogoča, da pustimo sprednji del nepreverjen. Če želite uporabiti pravilnik, zaženite ukaz:

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

Vrnite se na stran in oddajte zahtevo - videli boste, da se konča s statusom 401 Nedovoljeno. Zdaj pa preusmerimo čelne uporabnike na preverjanje pristnosti z Auth0.

Preverjanje pristnosti zahtev z Auth0

Za preverjanje pristnosti zahtev končnih uporabnikov morate ustvariti API v Auth0, ki bo predstavljal overjene storitve (mnenja, podrobnosti in ocene). Če želite ustvariti API, pojdite na Portal Auth0 > API-ji > Ustvari API in izpolnite obrazec:

Pomembna informacija tukaj je identificirati, ki ga bomo uporabili kasneje v scenariju. Zapišimo takole:

• Občinstvo: {VAŠA_OBČINSTVO}

Preostale podrobnosti, ki jih potrebujemo, se nahajajo na portalu Auth0 v razdelku Aplikacije - izberite Testna aplikacija (ustvarjeno samodejno skupaj z API-jem).

Tukaj bomo zapisali:

• Domena: {VAŠA_DOMAIN}
• ID stranke: {YOUR_CLIENT_ID}

Pomaknite se do Testna aplikacija v besedilno polje Dovoljeni URL-ji za povratni klic (razrešeni URL-ji za povratni klic), v katerem določimo URL, kamor naj se pošlje klic po končani avtentikaciji. V našem primeru je to:

http://{EXTERNAL_IP}/callback

In za Dovoljeni URL-ji za odjavo (dovoljeni URL-ji za odjavo) dodaj:

http://{EXTERNAL_IP}/logout

Preidimo na sprednji del.

Posodobitev sprednjega dela

Preklopi na podružnico auth0 repozitorija [istio-mastery]. V tej veji je koda sprednjega dela spremenjena tako, da uporabnike preusmeri na Auth0 za preverjanje pristnosti in uporabi žeton JWT v zahtevah do drugih storitev. Slednji se izvaja na naslednji 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));
}

Če želite spremeniti sprednji del za uporabo podatkov najemnika v Auth0, odprite sa-frontend/src/services/Auth.js in v njem zamenjajte vrednosti, ki smo jih zapisali zgoraj (Auth.js):

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

Aplikacija je pripravljena. Podajte svoj Docker ID v spodnjih ukazih, ko gradite in uvajate izvedene spremembe:

$ 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

Preizkusite aplikacijo! Preusmerjeni boste na Auth0, kjer se morate prijaviti (ali registrirati), nato pa boste vrnjeni na stran, s katere se izvajajo že overjene zahteve. Če poskusite ukaze, omenjene v prvih delih članka, s curl, boste dobili kodo 401 Statusna koda, kar pomeni, da zahteva ni avtorizirana.

Naredimo naslednji korak - odobrimo zahteve.

Avtorizacija z Auth0

Avtentikacija nam omogoča, da razumemo, kdo je uporabnik, vendar je potrebna avtorizacija, da vemo, do česa ima dostop. Istio ponuja orodja tudi za to.

Za primer ustvarimo dve uporabniški skupini (glejte spodnji diagram):

• Člani (uporabniki) — z dostopom samo do storitev SA-WebApp in SA-Frontend;
• Moderatorji (moderatorji) — z dostopom do vseh treh storitev.

Koncept avtorizacije

Za ustvarjanje teh skupin bomo uporabili razširitev avtorizacije Auth0 in uporabili Istio, da jim zagotovimo različne ravni dostopa.

Namestitev in konfiguracija avtorizacije Auth0

Na portalu Auth0 pojdite na razširitve (razširitve) in namestite Pooblastilo Auth0. Po namestitvi pojdite na Podaljšanje pooblastila, tam pa - do konfiguracije najemnika s klikom zgoraj desno in izbiro ustrezne menijske možnosti (Konfiguracija). Aktiviraj skupine (skupine) in kliknite gumb za objavo pravila (pravilo objave).

Ustvarite skupine

V Razširitev avtorizacije pojdite na skupine in ustvarite skupino Moderatorji. Ker bomo vse overjene uporabnike obravnavali kot običajne uporabnike, zanje ni treba ustvariti dodatne skupine.

Izberite skupino Moderatorji, Pritisnite Dodaj člane, dodajte svoj glavni račun. Nekatere uporabnike pustite brez skupine, da zagotovite, da jim je dostop onemogočen. (Nove uporabnike lahko ustvarite ročno prek Portal Auth0 > Uporabniki > Ustvari uporabnika.)

Dodaj skupinski zahtevek žetonu za dostop

Uporabniki so bili dodani v skupine, vendar se morajo te informacije odražati tudi v žetonih za dostop. Za skladnost z OpenID Connect in istočasno vrnitev skupin, ki jih potrebujemo, bo moral žeton dodati svojega zahtevek po meri. Implementirano prek pravil Auth0.

Če želite ustvariti pravilo, pojdite na portal Auth0 do Pravila, Pritisnite Ustvari pravilo in med predlogami izberite prazno pravilo.

Kopirajte spodnjo kodo in jo shranite kot novo pravilo Dodaj skupinski zahtevek (namespacedGroup.js):

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

Obvestilo: Ta koda vzame prvo uporabniško skupino, definirano v razširitvi avtorizacije, in jo doda žetonu dostopa kot zahtevek po meri (pod njenim imenskim prostorom, kot zahteva Auth0).

Nazaj na stran Pravila in preverite, ali imate napisani dve pravili v naslednjem vrstnem redu:

• auth0-pooblastilo-razširitev
• Dodaj skupinski zahtevek

Vrstni red je pomemben, ker polje skupine prejme pravilo asinhrono auth0-pooblastilo-razširitev in za tem je dodan kot trditev z drugim pravilom. Rezultat je žeton za dostop, kot je ta:

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

Zdaj morate konfigurirati proxy Envoy za preverjanje dostopa uporabnikov, za kar bo skupina potegnjena iz zahtevka (https://sa.io/group) v vrnjenem žetonu za dostop. To je tema za naslednji del članka.

Konfiguracija avtorizacije v Istio

Da bi avtorizacija delovala, morate omogočiti RBAC za Istio. Za to bomo uporabili naslednjo konfiguracijo:

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" 

Pojasnilo:

• 1 — omogoči RBAC samo za storitve in imenske prostore, navedene v polju Inclusion;
• 2 — navajamo seznam naših storitev.

Uporabimo konfiguracijo z naslednjim ukazom:

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

Vse storitve zdaj zahtevajo nadzor dostopa na podlagi vlog. Z drugimi besedami, dostop do vseh storitev je prepovedan in bo povzročil odgovor RBAC: access denied. Zdaj dovolimo dostop pooblaščenim uporabnikom.

Konfiguracija dostopa za običajne uporabnike

Vsi uporabniki morajo imeti dostop do storitev SA-Frontend in SA-WebApp. Izvedeno z uporabo naslednjih virov Istio:

• ServiceRole — določa pravice, ki jih ima uporabnik;
• ServiceRoleBinding — določa, komu pripada ta ServiceRole.

Navadnim uporabnikom bomo omogočili dostop do določenih storitev (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: ["*"]

In potem regular-user-binding uporabite ServiceRole za vse obiskovalce strani (navadna-user-storitev-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"

Ali "vsi uporabniki" pomeni, da bodo imeli dostop do SA WebApp tudi nepreverjeni uporabniki? Ne, pravilnik bo preveril veljavnost žetona JWT.

Uporabimo 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 dostopa za moderatorje

Moderatorjem želimo omogočiti dostop do vseh storitev (mod-service-role.yaml):

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

Vendar želimo takšne pravice le za tiste uporabnike, katerih dostopni žeton vsebuje zahtevek https://sa.io/group s pomenom 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" 

Uporabimo 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

Zaradi predpomnjenja odposlancev lahko traja nekaj minut, da pravila avtorizacije začnejo veljati. Nato lahko zagotovite, da imajo uporabniki in moderatorji različne ravni dostopa.

Zaključek o tem delu

Resno, ali ste že kdaj videli enostavnejši, preprostejši, razširljiv in varen pristop k avtentikaciji in avtorizaciji?

Samo trije viri Istio (RbacConfig, ServiceRole in ServiceRoleBinding) so bili potrebni za doseganje natančnega nadzora nad avtentikacijo in avtorizacijo dostopa končnega uporabnika do storitev.

Poleg tega smo za ta vprašanja poskrbeli iz naših odposlanskih služb in dosegli:

• zmanjšanje količine generične kode, ki lahko vsebuje varnostne težave in hrošče;
• zmanjšanje števila neumnih situacij, v katerih se je izkazalo, da je ena končna točka dostopna od zunaj in so jo pozabili prijaviti;
• odprava potrebe po posodobitvi vseh storitev vsakič, ko je dodana nova vloga ali pravica;
• da nove storitve ostanejo preproste, varne in hitre.

Izhod

Istio omogoča ekipam, da osredotočijo svoje vire na poslovno kritične naloge brez dodajanja dodatnih stroškov storitvam in jih vrnejo v mikro status.

Članek (v treh delih) je podal osnovno znanje in pripravljena praktična navodila za začetek uporabe Istio v realnih projektih.

PS od prevajalca

Preberite tudi na našem blogu:

• "Nazaj k mikrostoritvam z Istio": 1. del (uvod v glavne značilnosti), del 2 (usmerjanje, nadzor prometa);
• «Conduit - lahka servisna mreža za Kubernetes»;
• «Kaj je storitvena mreža in zakaj jo potrebujem [za aplikacijo v oblaku z mikrostoritvami]?".

Vir: www.habr.com