ProHoster > Blog > Administrim > Kthehu te mikroshërbimet me Istio. Pjesa 3

Kthehu te mikroshërbimet me Istio. Pjesa 3

Kthehu te mikroshërbimet me Istio. Pjesa 3

ShĂ«n. pĂ«rkth.: Pjesa e parĂ« Ky kĂ«tij cikli iu kushtua njohjes me mundĂ«sitĂ« e Istio dhe demonstrimit tĂ« tyre nĂ« veprim, DytĂ« — rrugezuar me pĂ«rpunimin e trafikut nĂ« rrjet. Tani, do tĂ« flasim pĂ«r sigurinĂ«: pĂ«r tĂ« demonstruar funksionet bazike tĂ« lidhura me tĂ«, autori pĂ«rdor shĂ«rbimin e identitetit Auth0, megjithatĂ«, sipas analogjisĂ« me tĂ« mund tĂ« konfigurohen edhe ofrues tĂ« tjerĂ«.

Ne konfigurim një klaster Kubernetes, në të cilin të deploy-ojmë Istio dhe një shembull të aplikacionit mikro-shërbimeve Sentiment Analysis, - kështu u demonstruan mundësitë e Istio.

Me ndihmën e Istio, arritëm të ruajmë një madhësi të vogël të shërbimeve, pasi ato nuk kanë nevojë për implementimin e 'shtresave' si përpjekjet e përsëritura (Retries), kohët e skadimit (Timeouts), automatikët e fikjes (Circuit Breakers), gjurmimin (Tracing), monitorimin (Monitoring). Për më tepër, ne përdorëm teknika të avancuara të testimit dhe deploy-it: testim A/B, pasqyrim dhe lëshime kanarinë.

Kthehu te mikroshërbimet me Istio. Pjesa 3

Në materialin e ri do të shqyrtojmë shtresat finale në rrugën drejt vlerës biznesore: autentifikimin dhe autorizimin - dhe në Istio kjo është një kënaqësi e madhe!

Autentifikimi dhe autorizimi në Istio

KurrĂ« nuk do tĂ« besoja se do tĂ« frymĂ«zohem nga autentifikimi dhe autorizimi. ÇfarĂ« mund tĂ« ofrojĂ« Istio nga kĂ«ndvĂ«shtrimi teknologjik pĂ«r ta bĂ«rĂ« kĂ«to tema interesante dhe madje mĂ« shumĂ« - qĂ« ato tĂ« frymĂ«zojnĂ« edhe ju?

Përgjigjja është e thjeshtë: Istio e transferon përgjegjësinë për këto mundësi nga shërbimet tuaja në proxy-në Envoy. Në momentin kur kërkesat arrijnë në shërbime, ato janë tashmë të autentikuara dhe të autorizuara, kështu që ju mbetet vetëm të shkruani kod të dobishëm për biznesin.

Duket mirë? Le të hedhim një vështrim të brendshëm!

Autentifikimi me Auth0

Si server për menaxhimin e identitetit dhe aksesi do të përdorim Auth0, që ka një version provues, i cili është intuitiv për përdorim dhe thjesht më pëlqen. Megjithatë, të njëjtat principe mund të zbatohen edhe për çdo implementim tjetër të OpenID Connect: KeyCloak, IdentityServer dhe shumë të tjerë.

PĂ«r tĂ« filluar, shko te Auth0 Portal me llogarinĂ« tuaj, krijoni njĂ« tenant (tenant - 'qiramarres', njĂ«si logjike izolimi, shih mĂ« shumĂ« nĂ« dokumentacionin — shĂ«n. pĂ«rkth.) dhe shkoni te Applications > Default App, duke zgjedhur Domain, siç tregohet nĂ« screenshotin mĂ« poshtĂ«:

Kthehu te mikroshërbimet me Istio. Pjesa 3

Shkruani 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 disponon kĂ«tĂ« burim, Pilot (njĂ« nga tre komponentĂ«t bazĂ« tĂ« Control Plane nĂ« Istio — shĂ«n. pĂ«rk.) konfiguron Envoy pĂ«r autentifikimin e kĂ«rkesave para se t'i dĂ«rgojĂ« ato te shĂ«rbimet: sa-web-app dhe sa-feedback. NĂ« tĂ« njĂ«jtĂ«n kohĂ«, konfigurimi nuk aplikohet te Envoy tĂ« shĂ«rbimit sa-frontend, duke na lejuar tĂ« lĂ«mĂ« frontendin pa autentifikim. 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Ă« faqen dhe bĂ«ni njĂ« kĂ«rkesĂ« — do tĂ« shihni se ajo do tĂ« pĂ«rfundojĂ« me statusin 401 Jo e autorizuar. Tani do tĂ« ridrejtojmĂ« pĂ«rdoruesit e frontend-it pĂ«r autentifikim me Auth0.

Autentifikimi i kërkesave me Auth0

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

Kthehu te mikroshërbimet me Istio. Pjesa 3

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

  • Audience: {YOUR_AUDIENCE}

Detajet e tjera tĂ« nevojshme ndodhen nĂ« Auth0 Portal nĂ« seksionin Applications — zgjidhni Test Application (krijohet automatikisht sĂ« bashku me API).

Këtu do të shkruajmë:

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

Rrokullisni në Test Application drejt fushës tekstuale Allowed Callback URLs (URL-të e lejuara për callback), ku do të përfshijmë URL-në, në të cilën duhen dërguar thirrjet pas përfundimit të autentifikimit. Në rastin tonë, kjo është:

http://{EXTERNAL_IP}/callback

Dhe për Allowed Logout URLs (URL-të e lejuara për shkëputje) do të shtojmë:

http://{EXTERNAL_IP}/logout

Le të kalojmë te frontend-i.

Përditësimi i frontend-it

Kaloni në degën auth0 repozitari [istio-mastery]. Në këtë degë kodi, frontend-i është ndryshuar për të ridrejtuar përdoruesit në Auth0 për autentifikim dhe për të përdorur JWT-token në kërkesat ndaj shërbimeve të tjera. Kjo e fundit realizohet 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ë 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 atje vlerat që kemi shkruar më sipër (Auth.js):

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

Aplikacioni është gati. Shënoni ID-në tuaj të Docker-it në komandat më poshtë gjatë ndërtimit dhe vendosjes së ndryshimeve të realizuara:

$ 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Ă« bĂ«sh log in (ose tĂ« regjistrohesh), pas sĂ« cilĂ«s do tĂ« kthehesh sĂ«rish nĂ« faqen nga e cila do tĂ« kryhen kĂ«rkesat e 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, i cili 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 për çfarë ka akses, nevojitet autorizimi. Istio ofron mjete edhe për këtë.

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

  • PĂ«rdoruesit (pĂ«rdoruesit) — me akses vetĂ«m nĂ« shĂ«rbimet SA-WebApp dhe SA-Frontend;
  • ModeratorĂ«t (moderatorĂ«t) — me akses nĂ« tĂ« tri shĂ«rbimet.

Kthehu te mikroshërbimet me Istio. Pjesa 3
Koncepcioni i autorizimit

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

Instalimi dhe konfigurimi i Auth0 Authorization

NĂ« portalin Auth0, kaloni tek shtesat (Extensions) dhe instaloni Auth0 Authorization. Pasi e keni instaluar, kaloni tek Authorization Extension, dhe aty — tek konfigurimi i tenant-it duke klikuar djathtas lartĂ« dhe duke zgjedhur opsionin pĂ«rkatĂ«s tĂ« menusĂ« (Configuration). Aktivizoni grupet (Groups) dhe shtypni butonin e publikimit tĂ« rregullave (Publish rule).

Kthehu te mikroshërbimet me Istio. Pjesa 3

Krijimi i grupeve

Në Authorization Extension kaloni në Grupet dhe krijoni grupin Moderators. Duke qenë se do t'i konsiderojmë të gjithë përdoruesit e autentikuar si përdorues të zakonshëm, nuk ka nevojë për krijimin e një grupi 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'u siguruar se aksesit për ta është ndaluar. (Përdorues të rinj mund të krijohen manualisht përmes Auth0 Portal > Users > Create User.)

Shtoni Group Claim në Access Token

Përdoruesit janë shtuar në grupe, megjithatë kjo informacion duhet të reflektohet gjithashtu në tokenët për qasje. Për të përmbushur OpenID Connect dhe njëkohësisht për të kthyer grupet që na nevojiten, tokeni do të kërkojë të shtojë pretendim personalizuar. Implementohet nëpërmjet rregullave Auth0.

Për të krijuar një rregull, shkoni në portalin Auth0 në Rregullat, klikoni në Krijo Rregull dhe zgjidhni një rregull të zbrazët nga shabllonet.

Kthehu te mikroshërbimet me Istio. Pjesa 3

Kopjoni kodin më poshtë dhe ruajeni si një rregull të ri Shtoni Grupin e Pretendimit (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ë Zgjerimin e Autorizimit, dhe e shton atë në access-token si një pretendim personalizuar (në hapësirën e tij të emrave, siç kërkon Auth0).

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

  • auth0-authorization-extension
  • Shtoni Grupin e Pretendimit

Rendi është i rëndësishëm, sepse fusha e grupit merr rregullin në mënyrë asinkrone auth0-authorization-extension dhe pastaj shtohet si një pretendim nga rregulli i dytë. Si rezultat, krijohet një access-token i tillë:

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

Tani është e nevojshme të konfigurojmë proxy-në Envoy për të verifikuar aksesin e përdoruesit, për të cilin grupi do të merret nga pretendimi (https://sa.io/group) në access-tokenin e kthyer. Ky është një temë për seksionin tjetër të artikullit.

Konfigurimi i autorizimit në Istio

Për të funksionuar autorizimi, është e nevojshme të aktivizoni RBAC për Istio. Për këtë, 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"

Shpjegime:

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

Do ta aplikojmë konfigurimin duke përdorur komandën:

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

Tani të gjitha shërbimet kërkojnë menaxhim 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ë rezultojë me përgjigjen RBAC: akses i ndaluar. Tani le të lejojmë qasjen 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 referohet kjo ServiceRole.

Për përdoruesit e zakonshëm, do të lejojmë qasje 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 ta 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 ata që nuk janë autentikuar do të kenë qasje në SA WebApp? Jo, politikat do të verifikojnë 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 qasjes për moderatorët

Për moderatorët, ne duam të përfshijmë qasje 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 që këto të drejta të jenë vetëm për ata përdorues, në tokenin e qasjes të cilëve ka claim https://sa.io/group me vlerën 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ë mbështetjes, mund të kërkohen disa minuta që rregullat e autorizimit të hyjnë në fuqi. Pas kësaj, ju do të jeni në gjendje të verifikoni se përdoruesit dhe moderatorët kanë nivele të ndryshme qasje.

Përfundimi i kësaj pjese

Pra, a keni parë ndonjëherë një qasje më të thjeshtë, pa përpjekje, të shkallueshme dhe të sigurt për autentikimin dhe autorizimin?

Pikërisht tre burime Istio (RbacConfig, ServiceRole dhe ServiceRoleBinding) ishin të nevojshme për të arritur një kontroll të imtësisë mbi autentikimin dhe autorizimin e qasjes së përdoruesve në shërbime.

Për më tepër, ne i kemi transferuar këto probleme nga shërbimet tona në envoy'e, duke arritur:

  • reduktimin e shumicĂ«s sĂ« kodit tĂ« zakonshĂ«m, ku mund tĂ« ketĂ« probleme tĂ« sigurisĂ« dhe defekte;
  • zhvlerĂ«simin e situatave tĂ« paqĂ«ndrueshme, nĂ« tĂ« cilat njĂ« endpoint ishte i qasshĂ«m nga jashtĂ« dhe harroi tĂ« raportonte pĂ«r kĂ«tĂ«;
  • eliminimin e nevojĂ«s pĂ«r tĂ« pĂ«rditĂ«suar tĂ« gjitha shĂ«rbimet me çdo shtesĂ« tĂ« re tĂ« rolit ose tĂ« drejtĂ«s;
  • qĂ« shĂ«rbimet e reja mbeten tĂ« thjeshta, tĂ« sigurta dhe tĂ« shpejta.

PĂ«rfundimi

Istio u lejon ekipeve të përqendrojnë burimet e tyre në detyra të rëndësishme për biznesin, pa shtuar ngarkesë të panevojshme shërbimeve, duke i kthyer ato në gjendjen "mikro".

Artikulli (në tri pjesë) ofroi njohuri bazë dhe një udhëzues praktik të gatshëm për të filluar punën me Istio në projekte të vërteta.

P.S. nga përkthyesi

Lexoni gjithashtu në blogun tonë:

Burimi: habr.com

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