🥇Kthim te mikroshërbimet me Istio. Pjesa 3

Shënim. përkth.: Pjesa e pare ky serial iu kushtua njohjes me aftësitë e Istios dhe demonstrimit të tyre në veprim, i dytë — Drejtimi i rregulluar mirë dhe menaxhimi i trafikut të rrjetit. Tani do të flasim për sigurinë: për të demonstruar funksionet themelore që lidhen me të, autori përdor shërbimin e identitetit Auth0, por ofruesit e tjerë mund të konfigurohen në një mënyrë të ngjashme.

Ne krijuam një grup Kubernetes në të cilin vendosëm Istio dhe një shembull të aplikacionit të mikroshërbimit, Analiza e ndjenjave, për të demonstruar aftësitë e Istio.

Me Istio, ne ishim në gjendje t'i mbanim shërbimet tona të vogla sepse ato nuk kanë nevojë të zbatojnë shtresa si Riprovimet, Kohët e fundit, Ndërprerësit, Gjurmimi, Monitorimi. Përveç kësaj, ne përdorëm teknika të avancuara testimi dhe vendosjeje: testimi A/B, pasqyrimi dhe nxjerrja e kanarinave.

Në materialin e ri, do të merremi me shtresat përfundimtare në rrugën drejt vlerës së biznesit: vërtetimi dhe autorizimi - dhe në Istio është një kënaqësi e vërtetë!

Autentifikimi dhe autorizimi në Istio

Nuk do ta kisha besuar kurrë se do të frymëzohesha nga vërtetimi dhe autorizimi. Çfarë mund të ofrojë Istio nga këndvështrimi i teknologjisë për t'i bërë këto tema argëtuese dhe, aq më tepër, frymëzuese për ju?

Përgjigja është e thjeshtë: Istio e zhvendos përgjegjësinë për këto aftësi nga shërbimet tuaja tek përfaqësuesi i të dërguarit. Në momentin që kërkesat arrijnë te shërbimet, ato tashmë janë vërtetuar dhe autorizuar, kështu që gjithçka që duhet të bëni është të shkruani kodin e dobishëm për biznesin.

Tingëllon mirë? Le të hedhim një sy brenda!

Autentifikimi me Auth0

Si një server për menaxhimin e identitetit dhe aksesit, ne do të përdorim Auth0, i cili ka një version provë, është intuitiv për t'u përdorur dhe thjesht më pëlqen. Megjithatë, të njëjtat parime mund të zbatohen për çdo tjetër Implementimet e OpenID Connect: KeyCloak, IdentityServer dhe shumë të tjerë.

Për të filluar, shkoni te Portali Auth0 me llogarinë tuaj, krijoni një qiramarrës (qiramarrësi - "qiramarrësi", njësia logjike e izolimit, për më shumë detaje shih dokumentacionin - përafërsisht. përkth.) dhe shkoni në Aplikacionet > Aplikacioni i parazgjedhurzgjedhja Fushë, siç tregohet në pamjen e mëposhtme të ekranit:

Specifikoni këtë domen në skedar resource-manifests/istio/security/auth-policy.yaml (burimi):

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

Me një burim të tillë, Pilot (një nga tre komponentët bazë të Planit të Kontrollit në Istio - përafërsisht përkth.) konfiguron Envoy për të vërtetuar kërkesat përpara se t'i përcjellë ato te shërbimet: sa-web-app и sa-feedback. Në të njëjtën kohë, konfigurimi nuk zbatohet për të dërguarit e shërbimit sa-frontend, duke na lejuar ta lëmë frontin të paautentikuar. Për të aplikuar Politikën, ekzekutoni komandën:

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

Kthehuni në faqe dhe bëni një kërkesë - do të shihni që përfundon me statusin 401 I paautorizuar. Tani le t'i ridrejtojmë përdoruesit e frontit për të vërtetuar me Auth0.

Autentifikimi i kërkesave me Auth0

Për të vërtetuar kërkesat e përdoruesve fundorë, duhet të krijoni një API në Auth0 që do të përfaqësojë shërbimet e vërtetuara (rishikimet, detajet dhe vlerësimet). Për të krijuar një API, shkoni te Portali Auth0 > API-të > Krijo API dhe plotësoni formularin:

Informacioni i rëndësishëm këtu është Identifikuesi, të cilin do ta përdorim më vonë në skenar. Le ta shkruajmë kështu:

Audiencë: {YOUR_AUDIENCE}

Detajet e mbetura që na duhen gjenden në Portalin Auth0 në seksion Aplikime - zgjidhni Aplikimi i testit (krijohet automatikisht së bashku me API-në).

Këtu do të shkruajmë:

Fushë: {YOUR_DOMAIN}
ID-ja e klientit: {YOUR_CLIENT_ID}

Lëvizni te Aplikimi i testit në fushën e tekstit URL-të e lejuara të kthimit të telefonatës (URL të zgjidhura për kthimin e thirrjes), në të cilat ne specifikojmë URL-në ku duhet të dërgohet thirrja pas përfundimit të vërtetimit. Në rastin tonë është:

http://{EXTERNAL_IP}/callback

Dhe për URL-të e lejuara të daljes (URL-të e lejuara për dalje) shtoni:

http://{EXTERNAL_IP}/logout

Le të kalojmë në front.

Përditësimi i frontendit

Kalo në degë auth0 repozitoriя [istio-mastery]. Në këtë degë, kodi i frontendit ndryshohet për të ridrejtuar përdoruesit te Auth0 për vërtetim dhe për të përdorur tokenin JWT në kërkesat për shërbime të tjera. Kjo e fundit zbatohet si më poshtë (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));
}

Për të ndryshuar frontin për të përdorur të dhënat e qiramarrësit në Auth0, hapeni sa-frontend/src/services/Auth.js dhe zëvendësoni në të vlerat që kemi shkruar më sipër (Auth.js):

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

Aplikacioni është gati. Specifikoni ID-në tuaj Docker në komandat e mëposhtme kur ndërtoni dhe vendosni ndryshimet e bëra:

$ 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

Provoni aplikacionin! Do të ridrejtoheni në Auth0, ku duhet të identifikoheni (ose të regjistroheni), pas së cilës do të ktheheni në faqen nga e cila do të bëhen kërkesat tashmë të vërtetuara. Nëse provoni komandat e përmendura në pjesët e para të artikullit me curl, do të merrni kodin 401 Kodi i statusit, duke sinjalizuar se kërkesa nuk është e autorizuar.

Le të bëjmë hapin tjetër - të autorizojmë kërkesat.

Autorizim me Auth0

Autentifikimi na lejon të kuptojmë se kush është një përdorues, por kërkohet autorizimi për të ditur se në çfarë kanë akses. Istio ofron mjete edhe për këtë.

Si shembull, le të krijojmë dy grupe përdoruesish (shih diagramin më poshtë):

Anëtarët (përdoruesit) — me akses vetëm në shërbimet SA-WebApp dhe SA-Frontend;
Moderatorët (moderatorë) — me akses në të tre shërbimet.

Koncepti i autorizimit

Për të krijuar këto grupe, ne do të përdorim shtesën e Autorizimit Auth0 dhe do të përdorim Istio për t'u ofruar atyre nivele të ndryshme aksesi.

Instalimi dhe konfigurimi i Autorizimit Auth0

Në portalin Auth0, shkoni te shtesat (Extensions) dhe instaloni Autorizimi Auth0. Pas instalimit, shkoni te Zgjatja e autorizimit, dhe atje - në konfigurimin e qiramarrësit duke klikuar lart djathtas dhe duke zgjedhur opsionin e duhur të menysë (Konfigurimi). Aktivizoni grupet (Grupet) dhe klikoni në butonin e rregullave të publikimit (Rregulli i publikimit).

Krijimi i grupeve

Në Zgjerimin e Autorizimit shkoni te Grupet dhe krijoni një grup moderatorët. Meqenëse ne do t'i trajtojmë të gjithë përdoruesit e vërtetuar si përdorues të rregullt, nuk ka nevojë të krijojmë një grup shtesë për ta.

Zgjidhni një grup moderatorët, Shtypni Shto Anëtarët, shtoni llogarinë tuaj kryesore. Lërini disa përdorues pa ndonjë grup për t'u siguruar që atyre iu mohohet qasja. (Përdoruesit e rinj mund të krijohen manualisht nëpërmjet Portali Auth0 > Përdoruesit > Krijo përdorues.)

Shtoni pretendimin e grupit në shenjën e aksesit

Përdoruesit janë shtuar në grupe, por ky informacion duhet të pasqyrohet gjithashtu në shenjat e aksesit. Për t'u pajtuar me OpenID Connect dhe në të njëjtën kohë për të kthyer grupet që na duhen, token-i do të duhet të shtojë të tijën kërkesë me porosi. Zbatuar përmes rregullave Auth0.

Për të krijuar një rregull, shkoni te Auth0 Portal to Rregullat, Shtypni Krijo rregull dhe zgjidhni një rregull bosh nga shabllonet.

Kopjoni kodin më poshtë dhe ruajeni si rregull të ri Shto pretendim në grup (namespaceGroup.js):

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

Shënim: Ky kod merr grupin e parë të përdoruesve të përcaktuar në Zgjerimin e Autorizimit dhe e shton atë në shenjën e aksesit si një pretendim të personalizuar (nën hapësirën e tij të emrave, siç kërkohet nga Auth0).

Kthehu në faqe Rregullat dhe kontrolloni nëse keni dy rregulla të shkruara në rendin e mëposhtëm:

auth0-autorization-extension
Shto pretendim në grup

Rendi është i rëndësishëm sepse fusha e grupit e merr rregullin në mënyrë asinkrone auth0-autorization-extension dhe pas kësaj shtohet si kërkesë me rregullin e dytë. Rezultati është një shenjë aksesi si kjo:

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

Tani ju duhet të konfiguroni përfaqësuesin e Envoy për të kontrolluar aksesin e përdoruesit, për të cilin grupi do të tërhiqet nga pretendimi (https://sa.io/group) në shenjën e kthyer të aksesit. Kjo është tema për pjesën tjetër të artikullit.

Konfigurimi i autorizimit në Istio

Që autorizimi të funksionojë, duhet të aktivizoni RBAC për Istio. Për ta bërë këtë, ne do të përdorim konfigurimin e mëposhtëm:

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"

Shpjegimet:

1 — aktivizoni RBAC vetëm për shërbimet dhe hapësirat e emrave të listuara në fushë Inclusion;
2 — ne listojmë një listë të shërbimeve tona.

Le të zbatojmë konfigurimin me komandën e mëposhtme:

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

Të gjitha shërbimet tani kërkojnë kontroll të qasjes së bazuar në role. Me fjalë të tjera, qasja në të gjitha shërbimet është e ndaluar dhe do të rezultojë në një përgjigje RBAC: access denied. Tani le të lejojmë qasjen për përdoruesit e autorizuar.

Konfigurimi i aksesit për përdoruesit e rregullt

Të gjithë përdoruesit duhet të kenë akses në shërbimet SA-Frontend dhe SA-WebApp. Zbatuar duke përdorur burimet e mëposhtme të Istio:

Roli i Shërbimit — përcakton të drejtat që ka përdoruesi;
ServiceRoleBinding — përcakton se kujt i përket ky Rol i Shërbimit.

Për përdoruesit e zakonshëm, ne do të lejojmë qasje në shërbime të caktuara (shërbimi.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: ["*"]

Dhe përmes regular-user-binding aplikoni ServiceRole për të gjithë vizitorët e faqes (rregullt-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"

A do të thotë "të gjithë përdoruesit" që përdoruesit e paautentikuar do të kenë gjithashtu akses në aplikacionin ueb SA? Jo, politika do të kontrollojë vlefshmërinë e tokenit JWT.

Le të zbatojmë konfigurimet:

$ 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

Konfigurimi i qasjes për moderatorët

Për moderatorët, ne duam të mundësojmë qasjen në të gjitha shërbimet (mod-service-role.yaml):

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

Por ne duam të drejta të tilla vetëm për ata përdorues, token e qasjes së të cilëve përmban pretendim https://sa.io/group me kuptim 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"

Le të zbatojmë konfigurimet:

$ 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ër shkak të ruajtjes në memorien e të dërguarve, mund të duhen disa minuta që rregullat e autorizimit të hyjnë në fuqi. Më pas mund të siguroheni që përdoruesit dhe moderatorët të kenë nivele të ndryshme aksesi.

Konkluzioni në këtë pjesë

Megjithatë, seriozisht, a keni parë ndonjëherë një qasje më të thjeshtë, të lehtë, të shkallëzuar dhe të sigurt për vërtetimin dhe autorizimin?

Vetëm tre burime Istio (RbacConfig, ServiceRole dhe ServiceRoleBinding) u kërkuan për të arritur kontroll të imët mbi vërtetimin dhe autorizimin e aksesit të përdoruesit fundor në shërbime.

Përveç kësaj, ne jemi kujdesur për këto çështje jashtë shërbimeve tona të të dërguarve, duke arritur:

zvogëlimi i sasisë së kodit gjenerik që mund të përmbajë probleme sigurie dhe gabime;
zvogëlimi i numrit të situatave budallaqe në të cilat një pikë përfundimtare doli të jetë e arritshme nga jashtë dhe harroi ta raportonte atë;
eliminimi i nevojës për të përditësuar të gjitha shërbimet sa herë që shtohet një rol ose e drejtë e re;
që shërbimet e reja të mbeten të thjeshta, të sigurta dhe të shpejta.

Prodhim

Istio lejon ekipet të përqendrojnë burimet e tyre në detyrat kritike për biznesin pa shtuar shpenzime të përgjithshme për shërbimet, duke i kthyer ato në status mikro.

Artikulli (në tre pjesë) ofron njohuri bazë dhe udhëzime praktike të gatshme për fillimin e Istio në projekte reale.