ProHoster > Blog > Administrimi > Kthehu te mikrosherbimet me Istio. Pjesa 3

Kthehu te mikrosherbimet me Istio. Pjesa 3

Kthehu te mikrosherbimet me Istio. Pjesa 3

ShĂ«n. pĂ«rk.: Pjesa e parĂ« Ky kyç do tĂ« ishte i kushtuar njohjes me mundĂ«sitĂ« e Istio dhe demonstruar nĂ« veprim, e dyta — routing i rafinuar dhe menaxhimi i trafikut tĂ« rrjetit. Tani do tĂ« flasim pĂ«r sigurinĂ«: pĂ«r tĂ« demonstruar funksionet e saj bazĂ«, autori pĂ«rdor shĂ«rbimin e identitetit Auth0, megjithatĂ«, sipas analogjisĂ«, mund tĂ« konfigurohen edhe ofrues tĂ« tjerĂ«.

Ne kemi konfiguruar njĂ« klaster Kubernetes, nĂ« tĂ« cilin kemi vendosur Istio dhe njĂ« shembull tĂ« aplikacionit mikroshĂ«rbim Sentiment Analysis, — kĂ«shtu u demonstruan mundĂ«sitĂ« e Istio.

Me Istio, arritëm të ruajmë një madhësi të vogël të shërbimeve, pasi ata nuk kanë nevojë për implementimin e 'shtresave' të tillë si përpjekjet e rishikimit (Retries), kohët max (Timeouts), burimet automatike (Circuit Breakers), gjurmimi (Tracing) dhe monitorimi (Monitoring). Për më tepër, zbatuam teknika të avansuara të testimit dhe vendosjes: testimi A/B, pasqyra dhe versionet kanarinë.

Kthehu te mikrosherbimet me Istio. Pjesa 3

NĂ« materialin e ri, do tĂ« shqyrtojmĂ« shtresat pĂ«rfundimtare nĂ« rrugĂ«n drejt vlerĂ«s biznesore: autentikimin dhe autorizimin — dhe nĂ« Istio kjo Ă«shtĂ« njĂ« kĂ«naqĂ«si e vazhdueshme!

Autentikimi dhe autorizimi në Istio

KurrĂ« nuk do tĂ« besoj se do tĂ« frymĂ«zohem nga autentikimi dhe autorizimi. ÇfarĂ« mund tĂ« ofrojĂ« Istio nga pikĂ«pamja teknologjike pĂ«r tĂ« bĂ«rĂ« kĂ«to tema emocionuese dhe madje pĂ«r t'i frymĂ«zuar edhe ju?

Përgjigja është e thjeshtë: Istio transferon përgjegjësinë për këto mundësi nga shërbimet tuaja tek proxy Envoy. Kur kërkesat arrijnë shërbimet, ato janë tashmë të autentikuara dhe të autorizuara, kështu që ju vetëm duhet të shkruani kod të dobishëm për biznesin.

Dëgjon mirë? Le të hedhim një sy brenda!

Autentikimi me Auth0

Si server për menaxhimin e identitetit dhe qasjes 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 principe mund të aplikohen edhe për çdo implementim tjetër të OpenID Connect: KeyCloak, IdentityServer dhe shumë të tjerë.

SĂ« pari, hyni nĂ« Auth0 Portal me llogarinĂ« tuaj, krijoni njĂ« tenant (tenant — 'qiramarrĂ«s', njĂ«si logjike e izolimit, shihni mĂ« shumĂ« nĂ« dokumentacion — shĂ«nim i pĂ«rkthyesit.) dhe hyni nĂ« Applications > Default App, duke zgjedhur Domen, siç tregohet nĂ« screenshotin mĂ« poshtĂ«:

Kthehu te mikrosherbimet me Istio. Pjesa 3

Specifikoni këtë domen në skedarin 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

Duke pasur njĂ« burim tĂ« tillĂ«, Pilot (njĂ« nga tre komponentĂ«t bazĂ« tĂ« Control Plane nĂ« Istio — shĂ«n. pĂ«rkth.) konfiguron Envoy pĂ«r tĂ« autentikuar kĂ«rkesat pĂ«rpara se t'i drejtojĂ« ato te shĂ«rbimet: sa-web-app dhe sa-feedback. NĂ« tĂ« njĂ«jtĂ«n kohĂ«, konfigurimi nuk aplikohet te Envoy-t e shĂ«rbimit sa-frontend, duke na lejuar tĂ« lĂ«mĂ« frontend-in tĂ« paautentikuar. PĂ«r tĂ« aplikuar politikĂ«n (Policy), 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 se do tĂ« pĂ«rfundojĂ« me statusin 401 Unauthorized. Tani, le tĂ« drejtojmĂ« pĂ«rdoruesit e frontend-it te autentikimi me Auth0.

Autentikimi i kërkesave me Auth0

Për të autentikuar kërkesat e përdoruesve përfundimtarë, është e nevojshme të krijoni një API në Auth0 që do të përfaqësojë shërbimet e autentikuara (reviews, details dhe ratings). Për të krijuar API kaloni në Auth0 Portal > APIs > Create API dhe plotësoni formularin:

Kthehu te mikrosherbimet me Istio. Pjesa 3

Informacioni i rëndësishëm këtu është Identifier, i cili do të përdoret më vonë në skript. Të shkruajmë atë si:

  • Audience: {YOUR_AUDIENCE}

Detajet e tjera qĂ« na nevojiten janĂ« nĂ« Auth0 Portal nĂ« seksionin Applications — zgjidhni Test Application (krijohet automatikisht sĂ« bashku me API).

Këtu do të shkruajmë:

  • Domen: {YOUR_DOMAIN}
  • Client Id: {YOUR_CLIENT_ID}

Rrokullisni në Test Application deri te fushë tekstuale Allowed Callback URLs (URL-të e lejueshme për callback), ku do të specifikojmë URL-në në të cilën duhet dërguar thirrja pas përfundimit të autentikimit. Në rastin tonë, është:

http://{EXTERNAL_IP}/callback

Dhe për Allowed Logout URLs (URL-të e lejueshme për çregjistrim) shtojmë:

http://{EXTERNAL_IP}/logout

Kaloni te frontend-i.

Përditësimi i frontend-it

Kaloni në degën auth0 repoja [istio-mastery]. Në këtë degë, kodi i frontend-it është ndryshuar në mënyrë që të drejtojë përdoruesit në Auth0 për autentikim dhe të përdorë tokenin JWT në kërkesat për shërbime të tjera. Kjo e fundit implementohet në këtë mënyrë (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ë kaluar frontend-in në përdorimin e të dhënave të tenant-it në Auth0, hapni sa-frontend/src/services/Auth.js dhe zëvendësoni aty vlerat që shkruam më sipër (Auth.js):

const Config = {
    clientID: '{YOUR_CLIENT_ID}',
    domain:'{YOUR_DOMAIN}',
    audience: '{YOUR_AUDIENCE}',
    ingressIP: '{EXTERNAL_IP}' // Përdoret për ridrejtim pas autentikimit
}

Aplikacioni është gati. Shkruani ID-në tuaj të Docker në komandat më poshtë gjatë ndërtimit dhe shpërndarjes së ndryshimeve të prodhuara:

$ 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

Provo aplikacionin! Do të ridrejtohesh në Auth0, ku duhet të regjistrohesh (ose të krijosh një llogari), pas së cilës do të kthehesh në faqen nga e cila do të bësh kërkesa të autentikuara. Nëse provon komandat e përmendura në pjesët e para të artikullit me curl, do të marrësh kodin 401 Status Code, që sinjalizon se kërkesa nuk është e autorizuar.

TĂ« bĂ«jmĂ« hapin tjetĂ«r — tĂ« autorizojmĂ« kĂ«rkesat.

Autorizimi me Auth0

Autentikimi na lejon të kuptojmë se kush është përdoruesi, por për të ditur se çfarë akses ka, kërkohet autorizimi. Istio ofron mjete edhe për këtë.

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

  • PĂ«rdoruesit (users) — qĂ« kanĂ« qasje vetĂ«m nĂ« shĂ«rbimet SA-WebApp dhe SA-Frontend;
  • Moderators (moderators) — qĂ« kanĂ« qasje nĂ« tĂ« tre shĂ«rbimet.

Kthehu te mikrosherbimet me Istio. Pjesa 3
Koncepti i autorizimit

Për të krijuar këto grupe, do të përdorim zgjerimin e autorizimit Auth0 dhe me ndihmën e Istio do t'u ofrojmë nivele të ndryshme qasjeje.

Instalimi dhe konfigurimi i autorizimit Auth0

NĂ« portalin Auth0, kaloni te zgjerimet (Extensions) dhe instaloni Auth0 Authorization.Pas instalimit, kaloni te Authorization Extension, dhe atje — nĂ« konfigurimin e tenant-it duke klikuar nĂ« tĂ« djathtĂ«n lart dhe zgjedhur opsionin pĂ«rkatĂ«s tĂ« menusĂ« (Configuration).Aktivizoni grupet (Groups) dhe klikoni butonin pĂ«r publikimin e rregullave (Publish rule)..

Kthehu te mikrosherbimet me Istio. Pjesa 3

Krijimi i grupeve

Në Authorization Extension kaloni në Grupet dhe krijoni grupin Moderators.Pasi ne do t'i konsiderojmë të gjithë përdoruesit e autentikuar si të zakonshëm, nuk ka nevojë të krijojmë një grup të veçantë për ta.

Zgjidhni grupin Moderators., klikoni në Add Members, shtoni llogarinë tuaj kryesore. Lini disa përdorues pa asnjë grup, për të siguruar që qasja për ta është e ndaluar. (Përdorues të rinj mund të krijohen manualisht përmes Auth0 Portal > Users > Create User.)

Shtoni Claim e Grupit në Tokenin e Aksesit

Përdoruesit janë shtuar në grupe, por kjo informacion duhet të pasqyrohet edhe në tokenat për akses. Për të përmbushur OpenID Connect dhe në të njëjtën kohë të kthejë grupet që na duhen, tokenit do t'i kërkohet të shtojë custom claim.Kjo realizohet përmes rregullave Auth0.

Për të krijuar një rregull, kaloni në portalin Auth0 te Rules, klikoni në Create Rule dhe zgjidhni një rregull të zbrazët nga shabllonet.

Kthehu te mikrosherbimet me Istio. Pjesa 3

Kopjoni kodin më poshtë dhe ruajeni si një rregull të ri Add Group Claim (namespacedGroup.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ërdoruesit, të përcaktuar në Authorization Extension, dhe e shton në access-token si custom claim (nën hapësirën e tij të emrave, sipas kërkesës së Auth0).

Kthehuni në faqen Rules dhe kontrolloni që keni dy rregulla të shkruara në këtë rend:

  • auth0-authorization-extension
  • Add Group Claim

Rendi është i rëndësishëm, pasi fusha e grupit e merr rregullën asinkronisht auth0-authorization-extension dhe pastaj shtohet si claim nga rregulla e dytë. Si rezultat fitoni një access-token të tillë:

{
 "https://sa.io/group": "Moderators",
 "iss": "https://sentiment-analysis.eu.auth0.com/",
 "sub": "google-oauth2|196405271625531691872"
 // [shkurtuar për qartësi]
}

Tani është e nevojshme të konfiguroni proxy-në Envoy për të verifikuar aksesin e përdoruesve, për këtë grupi do të nxirret nga claim (https://sa.io/group) në access-tokenin që kthehet. Ky është një temë për seksionin tjetër të artikullit.

Konfigurimi i autorizimit në Istio

Për të punuar autorizimi, është e nevojshme të aktivizoni RBAC për Istio. Për këtë do të përdorim konfigurimin në vijim:

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"

Shpjegime:

  • 1 — aktivizojmĂ« RBAC vetĂ«m pĂ«r shĂ«rbimet dhe hapĂ«sirat e emrave tĂ« listuara nĂ« fushĂ«n Inclusion;
  • 2 — rendisim listĂ«n e shĂ«rbimeve tona.

Të aplikojmë konfigurimin me këtë komandë:

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

Tani të gjitha shërbimet kërkojnë menaxhim të aksesit të bazuar në role (Role-Based Access Control). Në fjalë të tjera, qasja në të gjitha shërbimet është e ndaluar dhe do të çojë në përgjigjen RBAC: access denied.Tani lejojmë aksesin për përdoruesit e autorizuar.

Konfigurimi i aksesit për përdoruesit e zakonshëm

Të gjithë përdoruesit duhet të kenë qasje në shërbimet SA-Frontend dhe SA-WebApp. Kjo realizohet përmes burimeve të mëposhtme të Istio:

  • ServiceRole — pĂ«rcakton tĂ« drejtat qĂ« ka pĂ«rdoruesi;
  • ServiceRoleBinding — pĂ«rcakton se kujt i pĂ«rket kjo ServiceRole.

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

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

A do të thotë "të gjithë përdoruesit" që edhe përdoruesit pa autentifikim do të kenë akses në SA WebApp? Jo, politika do të verifikojë vlefshmërinë e tokenit JWT.

Do të aplikojmë 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 aksesit për moderatorët

Për moderatorët, ne duam të lejojmë aksesin 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 këto të drejta vetëm për ata përdorues, në tokenin e aksesit të të cilëve ka claim https://sa.io/group me vlerë 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"

Do të aplikojmë 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ë keq-marrjes në envoy, për zbatimin e rregullave të autorizimit mund të nevojiten disa minuta. Pas kësaj, do të mund të siguroni që përdoruesit dhe moderatorët kanë nivele të ndryshme akses.

Përfundimi në këtë pjesë

Pra, ndonjëherë: a keni parë ndonjëherë një qasje më të thjeshtë, pa mundim, të shkallëzueshme dhe të sigurt për autentifikim dhe autorizim?

Vetëm tre burime të Istio (RbacConfig, ServiceRole, dhe ServiceRoleBinding) ishin të nevojshme për të arritur një kontroll të hollë mbi autentifikimin dhe autorizimin e aksesit të përdoruesve për shërbimet.

Për më tepër, ne e kemi kaluar këtë shqetësim nga shërbimet tona në envoy, duke arritur:

  • reduktimin e kodit tĂ« zakonshĂ«m, ku mund tĂ« jenĂ« probleme tĂ« sigurisĂ« dhe bllokime;
  • uljen e situatave tĂ« paditur, ku njĂ« endpoint u bĂ« i aksesueshĂ«m nga jashtĂ« dhe harroi ta raportonte kĂ«tĂ«;
  • eleminimin e nevojĂ«s pĂ«r tĂ« pĂ«rditĂ«suar tĂ« gjitha shĂ«rbimet sa herĂ« qĂ« njĂ« rol ose tĂ« drejtĂ« tĂ« re tĂ« shtohet;
  • qĂ« shĂ«rbimet e reja mbeten tĂ« thjeshta, tĂ« sigurta dhe tĂ« shpejta.

PĂ«rfundim

Istio lejon ekipet të përqendrojnë burimet e tyre në detyrat e rëndësishme për biznesin, pa ndihmuar shërbimet duke i rikthyer ato në statusin "mikro".

Ky artikull (në tre pjesë) ofroi njohuri themelore dhe një udhëzues praktik për të filluar përdorimin e Istio në projekte të vërteta.

P.S. nga përkthyesi

Lexoni gjithashtu në blogun tonë:

Burimi: habr.com

Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster