ProHoster > Blogs > Administrācija > Atgriezties uz mikropakalpojumiem ar Istio. 3. daļa

Atgriezties uz mikropakalpojumiem ar Istio. 3. daļa

Atgriezties uz mikropakalpojumiem ar Istio. 3. daļa

PiezÄ«me. tulk.: Pirmā daļa Ŕī sērija bija veltÄ«ta Istio iespēju iepazÄ«Å”anai un demonstrÄ“Å”anai darbÄ«bā, otrais ā€” precÄ«zi noregulēta marÅ”rutÄ“Å”ana un tÄ«kla trafika pārvaldÄ«ba. Tagad parunāsim par droŔību: lai demonstrētu ar to saistÄ«tās pamatfunkcijas, autors izmanto Auth0 identitātes servisu, taču lÄ«dzÄ«gi var konfigurēt citus pakalpojumu sniedzējus.

Mēs izveidojām Kubernetes klasteru, kurā izvietojām Istio un mikropakalpojuma lietojumprogrammas piemēru Sentiment Analysis, lai parādītu Istio iespējas.

Izmantojot Istio, mēs varējām saglabāt savus pakalpojumus mazos, jo tiem nav jāievieÅ” tādi slāņi kā Atkārtoti mēģinājumi, Taimauts, Strāvas slēdži, IzsekoÅ”ana, UzraudzÄ«ba. Turklāt mēs izmantojām uzlabotas testÄ“Å”anas un izvietoÅ”anas metodes: A/B testÄ“Å”anu, spoguļoÅ”anu un kanāriju izlaiÅ”anu.

Atgriezties uz mikropakalpojumiem ar Istio. 3. daļa

Jaunajā materiālā mēs apskatÄ«sim pēdējos slāņus ceļā uz biznesa vērtÄ«bu: autentifikāciju un autorizāciju ā€“ un Istio tas ir patiess prieks!

Autentifikācija un autorizācija Istio

Es nekad nebÅ«tu ticējis, ka mani iedvesmos autentifikācija un autorizācija. Ko Istio var piedāvāt no tehnoloÄ£iju perspektÄ«vas, lai padarÄ«tu Ŕīs tēmas jautras un, vēl jo vairāk, iedvesmojoÅ”as?

Atbilde ir vienkārÅ”a: Istio nodod atbildÄ«bu par Ŕīm iespējām no jÅ«su pakalpojumiem uz sÅ«tņa starpniekserveri. Kamēr pieprasÄ«jumi sasniedz pakalpojumus, tie jau ir autentificēti un autorizēti, tāpēc atliek tikai uzrakstÄ«t biznesam noderÄ«gu kodu.

Izklausās labi? Ielūkosimies iekŔā!

Autentifikācija ar Auth0

Kā serveri identitātes un piekļuves pārvaldÄ«bai mēs izmantosim Auth0, kam ir izmēģinājuma versija, kas ir intuitÄ«vi lietojams, un man tas vienkārÅ”i patÄ«k. Tomēr tos paÅ”us principus var attiecināt uz jebkuru citu OpenID Connect ievieÅ”anas: KeyCloak, IdentityServer un daudzi citi.

Lai sāktu, dodieties uz Auth0 portāls ar savu kontu izveidojiet nomnieku (Ä«rnieks - ā€œÄ«rnieksā€, izolācijas loÄ£iskā vienÄ«ba, sÄ«kāk sk dokumentācija ā€” apm. tulk.) un dodieties uz Programmas > Noklusējuma programmaizvēloties Domēns, kā parādÄ«ts zemāk esoÅ”ajā ekrānuzņēmumā:

Atgriezties uz mikropakalpojumiem ar Istio. 3. daļa

Norādiet Å”o domēnu failā resource-manifests/istio/security/auth-policy.yaml (avots):

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

Izmantojot Ŕādu resursu, Pilot (viena no trim galvenajām vadÄ«bas plaknes sastāvdaļām Istio ā€” aptuveni tulk.) konfigurē Envoy, lai autentificētu pieprasÄ«jumus pirms to pārsÅ«tÄ«Å”anas pakalpojumiem: sa-web-app Šø sa-feedback. Tajā paŔā laikā konfigurācija netiek piemērota pakalpojumu sÅ«tņiem sa-frontend, ļaujot mums atstāt priekÅ”galu neautentificētu. Lai piemērotu politiku, palaidiet komandu:

$ kubectl apply -f resource-manifests/istio/security/auth-policy.yaml
policy.authentication.istio.io ā€œauth-policyā€ created

Atgriezieties lapā un veiciet pieprasÄ«jumu - jÅ«s redzēsiet, ka tas beidzas ar statusu 401 nesankcionēta. Tagad novirzÄ«sim priekÅ”gala lietotājus, lai tie autentificētos, izmantojot Auth0.

Pieprasījumu autentifikācija, izmantojot Auth0

Lai autentificētu galalietotāju pieprasÄ«jumus, pakalpojumā Auth0 ir jāizveido API, kas pārstāvēs autentificētos pakalpojumus (atsauksmes, informāciju un vērtējumus). Lai izveidotu API, dodieties uz Auth0 portāls > API > Izveidot API un aizpildiet veidlapu:

Atgriezties uz mikropakalpojumiem ar Istio. 3. daļa

Å eit ir svarÄ«ga informācija identifikators, ko izmantosim vēlāk skriptā. PierakstÄ«sim to Ŕādi:

  • audience: {YOUR_AUDIENCE}

Pārējā informācija, kas mums nepiecieÅ”ama, atrodas Auth0 portāla sadaļā Aplikācijas - atlasiet Testa lietojumprogramma (tiek izveidots automātiski kopā ar API).

Šeit mēs rakstīsim:

  • Domēns: {YOUR_DOMAIN}
  • Klienta ID: {YOUR_CLIENT_ID}

Ritiniet lÄ«dz Testa lietojumprogramma uz teksta lauku Atļautie atzvanÄ«Å”anas URL (atrisinātie URL atzvanÄ«Å”anai), kurā mēs norādām URL, uz kuru jānosÅ«ta zvans pēc autentifikācijas pabeigÅ”anas. MÅ«su gadÄ«jumā tas ir:

http://{EXTERNAL_IP}/callback

Un par Atļautie atteikŔanās URL (atļauti URL, lai izietu) pievienojiet:

http://{EXTERNAL_IP}/logout

Pārejam uz priekŔpusi.

Frontend atjauninājums

Pārslēgties uz filiāli auth0 krātuve [istio-mastery]. Å ajā nozarē priekÅ”gala kods tiek mainÄ«ts, lai novirzÄ«tu lietotājus uz Auth0 autentifikācijai un izmantotu JWT marÄ·ieri citu pakalpojumu pieprasÄ«jumos. Pēdējais tiek Ä«stenots Ŕādi (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));
}

Lai mainÄ«tu priekÅ”galu, lai Auth0 izmantotu nomnieka datus, atveriet sa-frontend/src/services/Auth.js un aizstājiet tajā vērtÄ«bas, kuras mēs rakstÄ«jām iepriekÅ” (Auth.js):

const Config = {
    clientID: '{YOUR_CLIENT_ID}',
    domain:'{YOUR_DOMAIN}',
    audience: '{YOUR_AUDIENCE}',
    ingressIP: '{EXTERNAL_IP}' // Š˜ŃŠæŠ¾Š»ŃŒŠ·ŃƒŠµŃ‚ся Š“Š»Ń рŠµŠ“ŠøрŠµŠŗтŠ° ŠæŠ¾ŃŠ»Šµ Š°ŃƒŃ‚ŠµŠ½Ń‚ŠøфŠøŠŗŠ°Ń†ŠøŠø
}

Pieteikums ir gatavs. Veidojot un izvietojot veiktās izmaiņas, tālāk norādÄ«tajās komandās norādiet savu Docker ID:

$ 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

Izmēģiniet lietotni! Jūs tiksiet novirzīts uz Auth0, kur jums ir jāpiesakās (vai jāreģistrējas), pēc tam tiksiet nosūtīts atpakaļ uz lapu, no kuras tiks veikti jau autentificēti pieprasījumi. Ja izmēģināsiet raksta pirmajās daļās minētās komandas ar curl, jūs iegūsit kodu 401 Statusa kods, norādot, ka pieprasījums nav autorizēts.

Spersim nākamo soli ā€“ autorizējam pieprasÄ«jumus.

Autorizācija ar Auth0

Autentifikācija ļauj mums saprast, kas ir lietotājs, taču ir nepiecieÅ”ama autorizācija, lai zinātu, kam viņam ir piekļuve. Istio piedāvā rÄ«kus arÄ« Å”im nolÅ«kam.

Piemēram, izveidosim divas lietotāju grupas (skatiet diagrammu zemāk):

  • Biedri (lietotāji) ā€” ar piekļuvi tikai SA-WebApp un SA-Frontend pakalpojumiem;
  • Moderatori (moderatori) ā€” ar piekļuvi visiem trim pakalpojumiem.

Atgriezties uz mikropakalpojumiem ar Istio. 3. daļa
Autorizācijas koncepcija

Lai izveidotu Ŕīs grupas, mēs izmantosim paplaÅ”inājumu Auth0 Authorization un izmantosim Istio, lai nodroÅ”inātu tām dažādus piekļuves lÄ«meņus.

Auth0 autorizācijas instalÄ“Å”ana un konfigurÄ“Å”ana

Portālā Auth0 dodieties uz paplaÅ”inājumiem (PaplaÅ”inājumi) un instalējiet Auth0 autorizācija. Pēc instalÄ“Å”anas dodieties uz Autorizācijas paplaÅ”inājums, un tur - uz nomnieka konfigurāciju, noklikŔķinot augŔējā labajā stÅ«rÄ« un atlasot atbilstoÅ”o izvēlnes opciju (Konfigurācija). Aktivizēt grupas (Grupas) un noklikŔķiniet uz kārtulas publicÄ“Å”anas pogas (Publicēt kārtulu).

Atgriezties uz mikropakalpojumiem ar Istio. 3. daļa

Izveidojiet grupas

Sadaļā Autorizācijas paplaÅ”inājums dodieties uz grupas un izveidot grupu Moderatori. Tā kā mēs visus autentificētos lietotājus uzskatÄ«sim par parastajiem lietotājiem, viņiem nav jāveido papildu grupa.

Izvēlieties grupu Moderatori, Nospiediet Pievienot dalībniekus, pievienojiet savu galveno kontu. Atstājiet dažus lietotājus bez grupas, lai pārliecinātos, ka viņiem tiek liegta piekļuve. (Jaunus lietotājus var izveidot manuāli, izmantojot Auth0 portāls > Lietotāji > Izveidot lietotāju.)

Pievienojiet piekļuves pilnvarai grupas pretenziju

Lietotāji ir pievienoti grupām, taču Ŕai informācijai ir jāatspoguļojas arī piekļuves marķieros. Lai nodroŔinātu atbilstību OpenID Connect un tajā paŔā laikā atgrieztu mums vajadzīgās grupas, marķierim būs jāpievieno savs pielāgota prasība. Ieviests, izmantojot Auth0 noteikumus.

Lai izveidotu kārtulu, dodieties uz Auth0 portālu uz Noteikumi, Nospiediet Izveidot kārtulu un veidnēs atlasiet tukÅ”u noteikumu.

Atgriezties uz mikropakalpojumiem ar Istio. 3. daļa

Nokopējiet tālāk norādīto kodu un saglabājiet to kā jaunu noteikumu Pievienot grupas pretenziju (namespacedGroup.js):

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

PiezÄ«me: Å”is kods aizņem pirmo autorizācijas paplaÅ”inājumā definēto lietotāju grupu un pievieno to piekļuves pilnvarai kā pielāgotu pretenziju (saskaņā ar tās nosaukumvietu, kā to pieprasa Auth0).

Atgriezties uz lapu Noteikumi un pārbaudiet, vai ir uzrakstīti divi noteikumi Ŕādā secībā:

  • auth0-authorization-extension
  • Pievienot grupas pretenziju

SecÄ«ba ir svarÄ«ga, jo grupas lauks kārtulu saņem asinhroni auth0-authorization-extension un pēc tam to pievieno kā pretenziju ar otro noteikumu. Rezultāts ir Ŕāds piekļuves marÄ·ieris:

{
 "https://sa.io/group": "Moderators",
 "iss": "https://sentiment-analysis.eu.auth0.com/",
 "sub": "google-oauth2|196405271625531691872"
 // [сŠ¾ŠŗрŠ°Ń‰ŠµŠ½Š¾ Š“Š»Ń Š½Š°Š³Š»ŃŠ“Š½Š¾ŃŃ‚Šø]
}

Tagad jums ir jākonfigurē sūtņa starpniekserveris, lai pārbaudītu lietotāja piekļuvi, kurai grupa tiks noņemta no prasības (https://sa.io/group) atgrieztajā piekļuves pilnvarā. Šī ir nākamā raksta sadaļas tēma.

Autorizācijas konfigurācija Istio

Lai autorizācija darbotos, jums ir jāiespējo RBAC Istio. Lai to izdarÄ«tu, mēs izmantosim Ŕādu konfigurāciju:

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"

Paskaidrojums:

  • 1 ā€” iespējojiet RBAC tikai laukā norādÄ«tajiem pakalpojumiem un nosaukumvietām Inclusion;
  • 2 ā€” mēs uzskaitām mÅ«su pakalpojumu sarakstu.

Piemērosim konfigurāciju ar Ŕādu komandu:

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

Tagad visiem pakalpojumiem ir nepiecieÅ”ama uz lomu balstÄ«ta piekļuves kontrole. Citiem vārdiem sakot, piekļuve visiem pakalpojumiem ir aizliegta, un tā rezultātā tiks sniegta atbilde RBAC: access denied. Tagad atļausim piekļuvi autorizētiem lietotājiem.

Piekļuves konfigurācija parastajiem lietotājiem

Visiem lietotājiem ir jābūt piekļuvei SA-Frontend un SA-WebApp pakalpojumiem. Ieviests, izmantojot Ŕādus Istio resursus:

  • Pakalpojuma loma ā€” nosaka lietotāja tiesÄ«bas;
  • ServiceRoleBinding ā€” nosaka, kam pieder Ŕī pakalpojuma loma.

Parastajiem lietotājiem mēs ļausim piekļūt noteiktiem pakalpojumiem (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: ["*"]

Un caur regular-user-binding lietot ServiceRole visiem lapas apmeklētājiem (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"

Vai ā€œvisi lietotājiā€ nozÄ«mē, ka neautentificētiem lietotājiem bÅ«s piekļuve SA WebApp? Nē, politika pārbaudÄ«s JWT marÄ·iera derÄ«gumu.

Izmantosim konfigurācijas:

$ 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

Piekļuves konfigurācija moderatoriem

Moderatoriem mēs vēlamies nodroÅ”ināt piekļuvi visiem pakalpojumiem (mod-service-role.yaml):

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

Taču mēs vēlamies Ŕādas tiesÄ«bas tikai tiem lietotājiem, kuru piekļuves pilnvarā ir ietverta prasÄ«ba https://sa.io/group ar nozÄ«mi 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"

Izmantosim konfigurācijas:

$ 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

SÅ«tņu keÅ”atmiņas dēļ var paiet dažas minÅ«tes, lÄ«dz pilnvaroÅ”anas noteikumi stāsies spēkā. Pēc tam varat nodroÅ”ināt, ka lietotājiem un moderatoriem ir dažādi piekļuves lÄ«meņi.

Secinājums par Ŕo daļu

Ja nopietni, vai esat kādreiz redzējis vienkārŔāku, bez piepÅ«les, mērogojamu un droÅ”u pieeju autentifikācijai un autorizācijai?

Tikai trīs Istio resursi (RbacConfig, ServiceRole un ServiceRoleBinding) bija nepiecieŔami, lai iegūtu precīzu autentifikācijas kontroli un galalietotāja piekļuves pakalpojumiem autorizāciju.

Turklāt mēs esam parÅ«pējuÅ”ies par Å”iem jautājumiem no saviem sÅ«tņu pakalpojumiem, panākot:

  • samazināt vispārÄ«gā koda daudzumu, kas var saturēt droŔības problēmas un kļūdas;
  • samazināt stulbu situāciju skaitu, kurās viens galapunkts izrādÄ«jās pieejams no ārpuses un aizmirsa par to ziņot;
  • novērÅ”ot nepiecieÅ”amÄ«bu atjaunināt visus pakalpojumus katru reizi, kad tiek pievienota jauna loma vai tiesÄ«bas;
  • ka jaunie pakalpojumi joprojām ir vienkārÅ”i, droÅ”i un ātri.

secinājums

Istio ļauj komandām koncentrēt savus resursus uz uzņēmējdarbībai kritiskiem uzdevumiem, nepalielinot pakalpojumiem papildu izmaksas, atjaunojot tiem mikro statusu.

Raksts (trīs daļās) sniedza pamatzināŔanas un gatavus praktiskus norādījumus, lai sāktu darbu ar Istio reālos projektos.

PS no tulka

Lasi arī mūsu emuārā:

Avots: www.habr.com

Pievieno komentāru