Tagasi teenustesse koos Istio’ga. Osa 3

Märkus tõlke kohta.: Esimene osa selle seeria keskendus Istio võimaluste tutvustamisele ja nende demonstreerimisele toimimas, teine — peene seadistamise suunamise ja võrgu liikluse juhtimise osas. Nüüd räägime turvalisusest: demonstreerimiseks kasutab autor sellega seotud põhifunktsioone identity-teenuse Auth0, kuid selle põhimõtete alusel saab seadistada ka teisi pakkujaid.

Oleme seadistanud Kubernetes klastrit, kuhu oleme paiknenud Istio ja näidis mikroteenuste rakenduse Sentiment Analysis, — sellega demonstreeriti Istio võimalusi.

Istio abil suutsime hoida teenuste väikest suurust, kuna need ei vaja selliste „kihtide“ nagu korduskatsetused (Retries), ajaülesanded (Timeouts), automaatsed katkestajad (Circuit Breakers), jälgimine (Tracing), monitooring (Monitoring) rakendamist. Lisaks kasutasime edasijõudnud testimise ja kasutuselevõtu tehnikaid: A/B-testimist, peegeldamist ja kanarbiku väljalaskmist.

Uues materjalis uurime viimaseid kihte teel äri väärtuseni: autentimist ja autoriseerimist — ja Istios on see puhas rõõm!

Autentimine ja autoriseerimine Istios

Ma poleks kunagi uskunud, et mind inspireerib autentimine ja autoriseerimine. Mida tehniliselt võib Istio pakkuda, et muuta need teemad huvitavaks ja isegi nii, et nad inspireeriksid ka teid?

Vastus on lihtne: Istio kannab nende võimaluste vastutuse teie teenustelt proksile Envoy. Aja jooksul, mil päringud jõuavad teenusteni, on need juba autentitud ja autoriseeritud, nii et teil jääb lihtsalt kirjutada kasulik ärikood.

Kostab hästi? Vaatame siis lähemalt!

Autentimine Auth0-ga

Identiteedi ja ligipääsu haldamiseks kasutame Auth0, millel on prooviversioon, mis on intuitiivne kasutada ja mis mulle lihtsalt meeldib. Siiski, samu põhimõtteid saab rakendada ka mistahes teise OpenID Connect rakenduse: KeyCloak, IdentityServer ja paljusid teisi.

Esialgu minge Auth0 Portaal oma kontoga, looge tenant (tenant — "üürnik", loogiline isolatsioonüksus, vt lähemalt dokumentatsioon — toimetaja märkus) ja minge Rakendused > Vaikimisi rakendus, valides Domeen, nagu on kujutatud 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

Sellise ressursiga seadistab Pilot (üks kolmest põhi komponentidest Control Plane'is Istios — tõlge.) Envoy'ide autentimise seadistamine enne nende suunamist teenustele: sa-web-app ja sa-feedback. Samal ajal ei rakendata seadistust teenuse Envoy'idele 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" loodud

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

Päringute autentimine Auth0-ga

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

Siin on oluline info Identifier, mida hiljem oma skriptis kasutame. Kirjutame selle endale üles:

• Audience: {YOUR_AUDIENCE}

Kõik vajalikud detailid asuvad Auth0 Portalis jaotises Applications — valige Test Application (loodud automaatselt koos API-ga).

Siin kirjutame:

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

Kerige alla Test Application kuni tekstiväljani Allowed Callback URLs (lubatud URL-id callback'ide jaoks), kuhu peame määrama URL-i, kuhu kutse saadetakse pärast autentimise lõpetamist. Meie puhul on see:

http://{EXTERNAL_IP}/callback

Ja Allowed Logout URLs (lubatud URL-id väljalogimiseks) lisage:

http://{EXTERNAL_IP}/logout

Liigume frontendi juurde.

Frontend'i värskendamine

Lülituge harule auth0 repositsioon [istio-mastery]. Käesolevas harus on frontend kood muudetud, et suunata kasutajad Auth0-sse autentimiseks ja kasutada JWT-tokenit päringutesse teiste teenuste poole. Viimane 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));
}

Kuna frontend muuta autentimise andmete kasutamiseks Auth0-s, avage sa-frontend/src/services/Auth.js ja asendage seal väärtused, mille me varem kirja panime (Auth.js):

const Config = {
    clientID: '{YOUR_CLIENT_ID}',
    domain:'{YOUR_DOMAIN}',
    audience: '{YOUR_AUDIENCE}',
    ingressIP: '{EXTERNAL_IP}' // Kasutatakse autentimise järel suunamiseks
}

Rakendus on valmis. Palun sisestage oma Docker ID allpool olevates käskudes, kui koostate ja juurutate 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), seejärel saadetakse teid tagasi lehele, kust tehakse juba autentitud päringud. Kui proovite alguses mainitud käsklusi curl’iga, saate koodi 401 Status Code, mis näitab, et päring ei ole autentitud.

Teeme järgmise sammu — autentime päringud.

Autentimine Auth0-ga

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

Näiteks loome kaks kasutajarühma (vt alloleval skeemil):

• Kasutajad (users) — kellel on juurdepääs ainult SA-WebApp ja SA-Frontend teenustele;
• Moderaatorid (moderators) — kellel on juurdepääs kõigile kolmele teenusele.

Autoriseerimise kontseptsioon

Nende rühmade loomiseks kasutame Auth0 Autoriseerimise laiendust ning Istio kaudu anname neile erinevad juurdepääsu tasemed.

Auth0 Autoriseerimise installimine ja konfigureerimine

Auth0 portaalis minge laienduste juurde (Extensions) ja installige Auth0 Autorization. Pärast installimist minge Autoriseerimise laiendusse, seejärel paremal ülal nupule klõpsates valige vastav menüüvalik (Configuration). Aktiveerige rühmad (Groups) ja klõpsake reegli avaldamise nuppu (Publish rule).

Rühmade loomine

Autoriseerimise laienduses minge Rühmad ja looge rühm ModeraatoridKuna me käsitleme kõiki autentitud kasutajaid tavakasutajatena, ei ole vajalik nende jaoks lisagruppide loomine.

Valige grupp Moderaatorid, vajutage Lisa liikmed, lisage oma peamine konto. Jätke mõned kasutajad ilma igasuguste gruppideta, et veenduda, et nende juurdepääs on keelatud. (Uusi kasutajaid saab luua käsitsi läbi Auth0 Portaal > Kasutajad > Lisa kasutaja.)

Lisage grupi väide juurdepääsulubadusse

Kasutajad on gruppidesse lisatud, kuid see teave peab olema kajastatud ka juurdepääsulubades. OpenID Connect'ile vastamiseks ja samal ajal vajalikke hulki tagastamiseks, peab lubadal olema selle kohandatud väide. Seda teostatakse läbi Auth0 reeglite.

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

Kopeerige allolev kood ja salvestage see uue reegli alla Lisa grupi väide (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ääratud autoriseerimise laienduses, ja lisab selle juurdepääsulubadesse kui kohandatud väite (oma nimeruumi all, nagu nõuab Auth0).

Pöörduge tagasi lehe Reeglid ja kontrollige, et teil on kaks reeglit, mis on kirjutatud järgmises järjekorras:

• auth0-autoriseerimise-laiendus
• Lisa grupi väide

Järjekord on oluline, kuna grupi väli saab reegli asünkroonselt auth0-autoriseerimise-laiendus ja seejärel lisatakse see teise reegli kui väide. Selle tulemuseks on selline juurdepääsuluba:

{
 "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 vaheproksi kasutaja juurdepääsu kontrollimiseks, mille jaoks grupp tõmmatakse välja väitest (https://sa.io/group) tagastatud juurdepääsulubes. See on teema järgmises jaotises.

Autoriseerimise seadistamine Istios

Et autoriseerimine töötaks, tuleb Istios RBAC sisse lülitada. Selleks kasutame järgmist seadistust:

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 — lülitame RBAC sisse ainult teenustele ja nimedele, mis on loetletud väites Inclusion;
• 2 — loetleme meie teenuste nimekirja.

Rakendame seadistuse sellise käsuga:

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

Nüüd vajavad kõik teenused rollipõhist juurdepääsu haldust (Role-Based Access Control). Teisisõnu, juurdepääs kõigile teenustele on keelatud ja toob kaasa vastuse RBAC: juurdepääs keelatud. Nüüd lubame juurdepääsu autoriseeritud kasutajatele.

Juhtimiskonfiguratsioon tavakasutajatele

Kõigil kasutajatel peab olema juurdepääs teenustele SA-Frontend ja SA-WebApp. See teostatakse järgmiste Istio ressursside abil:

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

Tavakasutajatele lubame juurdepää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 autentimata kasutajad saavad juurdepääsu SA WebApp-ile? Ei, poliitika kontrollib JWT-tokeni kehtivust.

Rakendame konfiguratsioonid:

$ 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

Juhtimiskonfiguratsioon moderaatoritele

Moderaatoritele soovime lubada juurdepää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 selliseid õigusi ainult nendele kasutajatele, kelle access-tokenis 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 konfiguratsioonid:

$ 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

Kuna envoy'des toimuvad vahemällu salvestamised, võib autoriseerimisreeglite jõustumiseks kuluda paar minutit. Pärast seda saate veenduda, et kasutajatel ja moderaatoritel on erinevad juurdepääsutasemed.

Kokkuvõte selle osa kohta

Tõsiselt, kas olete näinud kusagil lihtsamat, vaeva nägemata, skaleeritavat ja turvalist lähenemist autentimisele ja autoriseerimisele?

Vaid ainult kolm Istio ressursi (RbacConfig, ServiceRole ja ServiceRoleBinding) olid vajalikud, et saavutada peen regulatsioon lõppkasutajate autentimise ja autoriseerimise üle teenustele.

Lisaks tõime nende probleemide haldamise meie teenustest välja envoy’dele, saavutades:

• tüüpkoodeksi vähenemise, kus võivad esineda turvaprobleemid ja vead;
• rumalate olukordade vähenemise, kus üks endpoint oli väljastpoolt ligipääsetav ja unustasid sellest teatada;
• vajaduse elimineerimise, et uuendada kõiki teenuseid iga kord, kui lisatakse uus roll või õigus;
• uute teenuste lihtsuse, turvalisuse ja kiirus.

Kokkuvõte

Istio võimaldab meeskondadel keskenduda oma ressursid olulistele äritegevustele, lisamata teenustele täiendavaid kulusid, tuues need tagasi "mikro" staatusesse.

Artikkel (kolmes osas) pakkus põhiteadmisi ja valmis praktilisi juhiseid Istio kasutamiseks reaalses projektis.

P.S. tõlkijalt

Lugege ka meie blogist:

• "Tagasi mikroteenustele koos Istio": osa 1 (tutvumine põhifunktsioonidega), osa 2 (marsruutimine, liikluse haldamine);
• «Conduit — kerge service mesh Kubernetes'ile»;
• «Mis on service mesh ja miks on see mulle vajalik [pilveäppi mikroteenuste jaoks]?».

Allikas: habr.com