Tagasi mikroteenustele koos Istio'ga. Osa 3

Märk. tõlge.: Esimene osa selle tsükli eesmärk oli tutvustada Istio võimalusi ning neid praktikas demonstreerida, teine — peene häälestusega marsruutimise ja võrgu liikluse haldamise kaudu. Nüüd keskendume turvalisusele: selleks, et demonstreerida sellega seotud põhifunktsioone, kasutab autor identity-teenust Auth0, kuid samasuguseid seadistusi saab teha ka teiste pakkujatega.

Me seadsime üles Kubernetes-klastrit, kus käivitasime Istio ja näidis mikroteenuste rakenduse Sentiment Analysis, — nii demonstreeriti Istio võimalusi.

Istio abil suutsime säilitada teenuste väikese suuruse, kuna need ei vaja selliste „kihtide“ rakendamist nagu taaskäivitus (Retries), ajapiirangud (Timeouts), automaatsed katkestajad (Circuit Breakers), jälgimine (Tracing), monitooring (Monitoring). Lisaks kasutasime arenenud testimise ja juurutamise tehnikaid: A/B-testimine, peegeldamine ja kanarulli väljalaskmine.

Uues materjalis uurime viimaseid kihti, mis viivad äriväärtuseni: autentimise ja autoriseerimise — ja Istios on see tõeline nauding!

Autentimine ja autoriseerimine Istios

Ma ei oleks kunagi uskunud, et mind inspireerivad autentimine ja autoriseerimine. Mida tehniliselt võib Istio pakkuda, et muuta need teemad põnevaks ja veelgi enam — et need inspireeriksid ka sind?

Lihtne! Istio hõlbustab nende võimaluste vastutust teie teenustelt Envoy proxyle. Kui päringud jõuavad teenusteni, on need juba autentitud ja autoriseeritud, nii et teil jääb vaid äri jaoks kasuliku koodi kirjutamine.

Kas kõlab hästi? Vaadakem siis lähemalt!

Autentimine Auth0-ga

Identiteedi ja juurdepääsu haldamise serverina kasutame Auth0, millel on prooviversioon, mis on intuitiivselt kasutatav ja lihtsalt meeldib mulle. Siiski saab samu põhimõtteid rakendada ka mistahes muu OpenID Connect rakenduse: KeyCloak, IdentityServer ja paljusid teisi.

Alustuseks minge Auth0 portaali oma kontoga, looge tenant (tenant - „ühendus”, loogiline eraldamise üksus, vt lähemalt dokumentatsioonis — kt. tõlge) ja minge Rakendused > Vaikimisi rakendus, valides Domeen, nagu on näidatud alloleval ekraanipildil:

Määrake see domeen failis resource-manifests/istio/security/auth-policy.yaml (allikas):

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

Selle ressursiga, Pilot (üks kolmest põhilisest Control Plane'i komponendist Istios — toimetaja märkus.) konfigureerib Envoy'de autentimise päringute jaoks enne nende suunamist teenustele: sa-web-app ja sa-feedback. Samal ajal ei rakendata konfiguratsiooni teenuse Envoy'dele sa-frontend, võimaldades meil jätta frontend autentimata. Poliitika rakendamiseks käivitage käsk:

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

Tagasi minge lehele ja tehke päring — näete, et see lõppeb staatusega 401 Unauthorized. Nüüd suuname frontendi kasutajad autentimisele Auth0 kaudu.

Päringute autentimine Auth0-ga

Kasutaja päringute autentimiseks peate looma API Auth0-s, mis esindab autentitud teenuseid (reviews, details ja ratings). API loomiseks minge Auth0 Portal > APIs > Create API ja täitke vorm:

Oluline teave siin on Tuvustus, mida hiljem skriptis kasutame. Kirjutame selle endale nii:

• Si audience: {YOUR_AUDIENCE}

Vajalikud üksikasjad asuvad Auth0 Portaalis jaotises Rakendused — vali Testi rakendus (loodud automaatselt koos API-ga).

Siin kirjutame:

• Domeen: {YOUR_DOMAIN}
• Klient ID: {YOUR_CLIENT_ID}

Kerige alla Testi rakendus tekstivälja Lubatud Callback URL-id (lubatud URL-id callback'ile), kus määrame URL-i, kuhu kutse saadetakse pärast autentimise lõppemist. Meie juhul on see:

http://{EXTERNAL_IP}/callback

Ja jaoks Lubatud Logout URL-id (lubatud URL-id väljaregistreerimiseks) lisame:

http://{EXTERNAL_IP}/logout

Liigume frontendi juurde.

Frontendi värskendamine

Lülituge harule auth0 reposiitiumist [istio-mastery]. Selles harus on frontendi kood muudetud nii, et see suunab kasutajad Auth0-sse autentimiseks ja kasutab JWT-märgendit, et teha päringuid teistele teenustele. See on realiseeritud järgmiselt (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));
}

Et viia front end Tenant'i andmetele Auth0-s, avage sa-frontend/src/services/Auth.js ja asendage selles väärtused, mille me ülal registreerisime (Auth.js):

const Config = {
    clientID: '{YOUR_CLIENT_ID}',
    domain:'{YOUR_DOMAIN}',
    audience: '{YOUR_AUDIENCE}',
    ingressIP: '{EXTERNAL_IP}' // Kasutatakse ümber suunamiseks pärast autentimist
}

Rakendus on valmis. Täiendage oma Docker ID-d allpool toodud käskudes, kui ehitate ja juurutate tehtud muudatusi:

$ 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

Proovige rakendust! Teid suunatakse Auth0-le, kus peate sisse logima (või registreerima), pärast mida saadetakse teid tagasi lehele, millelt tehakse juba autentitud päringud. Kui proovite esimeses osas mainitud käsklusi koos curl'iga, saate koodi 401 Status Code, mis näitab, et päring ei ole autoriseeritud.

Liigume järgmise sammuga — autoriseerime päringud.

Autoriseerimine Auth0-ga

Autentimine võimaldab meil mõista, kes kasutaja on, kuid selleks, et teada saada, millele tal on juurdepääs, on vajalik autoriseerimine. Istio pakub ka selleks tööriistu.

Näiteks loome kaks kasutajagruppi (vt schemat allpool):

• Kasutajad (kasutajad) — juurdepääs ainult SA-WebApp ja SA-Frontend teenustele;
• Moderaatorid (moderaatorid) — juurdepääs kõigile kolmele teenusele.

Autoriseerimise kontseptsioon

Nende gruppide loomiseks kasutame Auth0 Authorization laiendust ning Istio kaudu anname neile erinevad juurdepääsutasemed.

Auth0 Authorization seadistamine ja konfigureerimine

Auth0 portaalis varuge aega laiendustele (Laiendid) ja installige Auth0 Authorization. Pärast installimist minge Authorization Extension, ja sealt minge tenant'i konfigureerimise juurde, klikkides paremal ülal ja valides vastava menüüvaliku (Konfigureerimine). Aktiveerige grupid (Grupid) ja vajutage reeglite avaldamise nuppu (Avalda reegel).

Grupide loomine

Authorization Extension'is minge Groups ja looge grupp Moderaatorid. Kuna käsitleme kõiki autentitud kasutajaid kui tavakasutajaid, ei ole vajadust luua neile täiendavat gruppi.

Valige grupp Moderaatorid, klikkige Lisa liikmeid, lisage oma põhikonto. Jätke mõned kasutajad ilma igasuguse grupita, et veenduda, et nende juurdepääs on keelatud. (Uusi kasutajaid saab luua käsitsi läbi Auth0 Portaal > Kasutajad > Loo kasutaja.)

Lisage Group Claim Access Tokenisse

Kasutajad on lisatud gruppidesse, kuid see teave peab olema peegeldatud ka juurdepääsu tokenites. Et vastata OpenID Connect nõuetele ja samal ajal tagastada vajalikud grupid, vajab token oma kohandatud claim'i. See rakendatakse läbi Auth0 reeglite.

Reegli loomiseks minge Auth0 Portaalis Reeglid, klikkige Loo reegel ja valige tühjad reeglid mallidest.

Kopeerige allolev kood ja salvestage see uue reeglina Lisage grupi claim (namespacedGroup.js):

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

Märkus: see kood võtab kasutaja esimese grupi, mis on määratletud Authorization Extensionis, ja lisab selle access-tokenisse kohandatud claim'ina (oma nimerruumis, nagu nõuab Auth0).

Naaske lehele Reeglid ja kontrollige, et teil on kaks reeglit, kirja pandud järgmises järjekorras:

• auth0-authorization-extension
• Lisage grupi claim

Järjekord on oluline, kuna grupi väli saadakse asünkroonselt reegliga auth0-authorization-extension ja lisatakse see seejärel nõudena teise reegliga. Tulemuseks on järgmine access-token:

{
 "https://sa.io/group": "Moderaatorid",
 "iss": "https://sentiment-analysis.eu.auth0.com/",
 "sub": "google-oauth2|196405271625531691872"
 // [lühendatud selguse huvides]
}

Nüüd tuleb seadistada Envoy-proksi, et kontrollida kasutaja juurdepääsu, mille jaoks rühm saadakse claim-st (https://sa.io/group) tagastatavas access-tokenis. See on teema järgmises jaos artiklis.

Autentimise konfigureerimine Istios

Kuna autentimine peab töötama, tuleb RBAC Istios lubada. Selleks kasutame järgmist konfiguratsiooni:

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" 

Selgitused:

• 1 — lubame RBAC-i ainult teenuste ja nimede ruumide jaoks, mis on loetletud väljaandes Inclusion;
• 2 — loetleme oma teenuste nimekirja.

Rakendame konfiguratsiooni järgmise käsuga:

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

Nüüd nõuavad kõik teenused juurdepääsu haldamist rollide põhjal (Role-Based Access Control). Teisisõnu, juurdepääs kõigile teenustele on keelatud ja viib vastuseni RBAC: access denied. Nüüd lubame juurdepääsu volitatud kasutajatele.

Tavakasutajate juurdepääsu konfiguratsioon

Kõigil kasutajatel peab olema ligipääs SA-Frontend ja SA-WebApp teenustele. Selle rakendamine toimub järgmiste Istio ressursside abil:

• ServiceRole — määratleb õigused, mis kasutajal on;
• ServiceRoleBinding — määratleb, kellele see ServiceRole kehtib.

Tavalistele kasutajatele lubame ligipääsu teatud teenustele (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: ["*"]

Ja läbi regular-user-binding rakendame ServiceRole kõigile lehe külastajatele (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"

Kas „kõik kasutajad“ tähendab, et ka mitteautentitud kasutajad saavad SA WebApp’ile ligipääsu? Ei, poliitika kontrollib JWT-tokeni kehtivust.

Rakendame konfiguratsioone:

$ 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

Ligipääsu konfiguratsioon moderaatoritele

Moderaatorite jaoks soovime lubada ligipääsu kõigile teenustele (mod-service-role.yaml):

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

Kuid me soovime neid õigusi ainult nende kasutajate jaoks, kelle access-token'is on claim https://sa.io/group väärtusega Moderaatorid (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" 

Rakendame konfiguratsioone:

$ 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

Envoy’des esineva vahemälu tõttu võib autoriseerimisreeglite jõustumine võtta paar minutit. Pärast seda saate veenduda, et kasutajatel ja moderaatoritel on erinevad ligipääsutasemed.

Järeldus selle osa kohta

Aga tõsiselt: kas olete kuskil näinud lihtsamat, pingutuseta, skaleeritavat ja turvalist lähenemist autentimisele ja autoriseerimisele?

Vajame lihtsalt kolme Istio ressurssi (RbacConfig, ServiceRole ja ServiceRoleBinding), et saavutada täpne kontroll lõppkasutajate autentimise ja autoriseerimise üle teenustele pääsemiseks.

Lisaks oleme need probleemid oma teenustelt välja viinud envoy’desse, saavutades:

• koodistandardeid, kus võivad esineda turvaprobleemid ja vead;
• vähenenud võimalusi rumalaks olukordadeks, kus üks endpoint on väljastpoolt ligipääsetav ja on unustatud sellest teavitada;
• vajadus uuendada kõiki teenuseid igakord uue rolli või õiguse lisamisel;
• tagada, et uued teenused jäävad lihtsateks, turvaliseks ja kiireks.

Kokkuvõte

Istio võimaldab meeskondadel keskenduda oma ressursid äri kõige olulisematele ülesannetele, lisamata teenustele lisakulusid, tagades nende staatuse 'mikroteenused'.

Artikkel (kolmes osas) pakkus põhiteadmisi ja valmis praktiseerimiseks mõeldud juhiseid Istio kasutuselevõtmiseks reaalsetes projektides.

P.S. tõlkija märkused

Lugege ka meie blogist:

• „Tagasi mikroteenuste juurde koos Istio’ga“: osa 1 (tutvumine põhifunktsioonidega), osa 2 (suunamine, liikluse haldamine);
• «Conduit — kerge teenuste võrk Kuberneteselt»;
• «Mis on service mesh ja miks see on vajalik [kogukonna rakendusele, mis põhineb mikroteenustel]?».

Allikas: habr.com