🥇Istioga tagasi mikroteenuste juurde. 3. osa

Märge. tõlge: Esimene osa see sari oli pühendatud Istio võimete tundmaõppimisele ja nende tegevuses demonstreerimisele, teine — peenhäälestatud marsruutimine ja võrguliikluse haldamine. Nüüd räägime turvalisusest: sellega seotud põhifunktsioonide demonstreerimiseks kasutab autor Auth0 identiteediteenust, kuid sarnaselt saab seadistada ka teisi pakkujaid.

Seadistasime Kubernetese klastri, milles juurutasime Istio ja mikroteenuse näidisrakenduse Sentiment Analysis, et näidata Istio võimeid.

Istio abil suutsime hoida oma teenused väikesena, kuna need ei pea rakendama selliseid kihte nagu korduskatsed, ajalõpud, kaitselülitid, jälgimine, jälgimine. Lisaks kasutasime täiustatud testimis- ja juurutamistehnikaid: A/B testimine, peegeldamine ja kanaari levitamine.

Uues materjalis käsitleme viimaseid kihte teel ärilise väärtuseni: autentimine ja autoriseerimine – ja Istios on see tõeline nauding!

Autentimine ja autoriseerimine Istios

Ma poleks kunagi uskunud, et autentimine ja autoriseerimine inspireerib mind. Mida saab Istio pakkuda tehnoloogia vaatenurgast, et muuta need teemad teie jaoks lõbusaks ja veelgi enam inspireerivaks?

Vastus on lihtne: Istio annab vastutuse nende võimaluste eest teie teenustelt Envoy puhverserverile. Selleks ajaks, kui päringud teenustesse jõuavad, on need juba autentitud ja volitatud, seega pole vaja teha muud, kui kirjutada äriliselt kasulik kood.

Kõlab hästi? Heidame pilgu sisse!

Auth0 autentimine

Identiteedi- ja juurdepääsuhalduse serverina kasutame Auth0, millel on prooviversioon, mida on intuitiivne kasutada ja see mulle lihtsalt meeldib. Samas saab samu põhimõtteid rakendada ka teiste puhul OpenID Connecti juurutused: KeyCloak, IdentityServer ja paljud teised.

Esiteks minge aadressile Auth0 portaal oma kontoga loo üürnik (üürnik - “üürnik”, loogiline isolatsiooniüksus, täpsemalt vt dokumentatsioon - u. tõlge.) ja minna juurde Rakendused > Vaikerakendusvalides Domeen, nagu on näidatud alloleval ekraanipildil:

Määrake failis see domeen 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 ressursi abil, Pilot (üks kolmest Istio juhtimistasandi põhikomponendist – umbes tõlge) konfigureerib saadiku autentima päringuid enne nende edastamist teenustele: sa-web-app и sa-feedback. Samal ajal ei rakendata konfiguratsiooni teenindussaadikutele sa-frontend, mis võimaldab meil jätta esiserva autentimata. Poliitika rakendamiseks käivitage käsk:

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

Naaske lehele ja esitage päring – näete, et see lõpeb olekuga 401 volitamata. Nüüd suuname kasutajaliidese kasutajad Auth0 abil autentima.

Taotluste autentimine rakendusega Auth0

Lõppkasutajate taotluste autentimiseks peate Auth0-s looma API, mis esindab autentitud teenuseid (arvustusi, üksikasju ja hinnanguid). API loomiseks minge aadressile Auth0 portaal > API-d > Loo API ja täitke vorm:

Siin on oluline teave Identifier, mida kasutame hiljem skriptis. Paneme selle kirja järgmiselt:

publik: {YOUR_AUDIENCE}

Ülejäänud andmed, mida vajame, asuvad Auth0 portaali jaotises Rakendused - vali Testirakendus (loodud automaatselt koos API-ga).

Siin me kirjutame:

Domeen: {YOUR_DOMAIN}
Kliendi ID: {YOUR_CLIENT_ID}

Kerige kuni Testirakendus tekstiväljale Lubatud tagasihelistamise URL-id (tagasihelistamise lahendatud URL-id), milles määrame URL-i, kuhu kõne tuleb pärast autentimise lõpetamist saata. Meie puhul on see:

http://{EXTERNAL_IP}/callback

Ja jaoks Lubatud väljalogimise URL-id (väljalogimiseks lubatud URL-id) lisage:

http://{EXTERNAL_IP}/logout

Liigume edasi frontendi juurde.

Frontendi värskendus

Lülitu harule auth0 hoidla [istio-mastery]. Selles harus muudetakse kasutajaliidese koodi, et suunata kasutajad autentimiseks Auth0-sse ja kasutada JWT-märki muude teenuste päringutes. Viimast rakendatakse 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));
}

Esiliidese muutmiseks rentnikuandmete kasutamiseks Auth0-s avage sa-frontend/src/services/Auth.js ja asendage selles väärtused, mille me ülal kirjutasime (Auth.js):

const Config = {
    clientID: '{YOUR_CLIENT_ID}',
    domain:'{YOUR_DOMAIN}',
    audience: '{YOUR_AUDIENCE}',
    ingressIP: '{EXTERNAL_IP}' // Используется для редиректа после аутентификации
}

Rakendus on valmis. Tehtud muudatuste loomisel ja juurutamisel määrake allolevates käskudes oma Dockeri 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

Proovi rakendust! Teid suunatakse Auth0-sse, kus tuleb sisse logida (või registreeruda), misjärel suunatakse tagasi lehele, kust tehakse juba autentitud päringuid. Kui proovite curl'iga artikli esimestes osades mainitud käske, saate koodi 401 Olekukood, mis annab märku, et päringut ei lubata.

Astume järgmise sammu – autoriseerime taotlusi.

Autoriseerimine Auth0-ga

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

Loome näiteks kaks kasutajarühma (vt allolevat diagrammi):

Liikmed (kasutajad) — juurdepääsuga ainult SA-WebAppi ja SA-Frontendi teenustele;
Moderaatorid (moderaatorid) — juurdepääsuga kõigile kolmele teenusele.

Autoriseerimise kontseptsioon

Nende rühmade loomiseks kasutame Auth0 autoriseerimise laiendust ja kasutame Istiot, et pakkuda neile eri juurdepääsutasemeid.

Auth0 autoriseerimise installimine ja konfigureerimine

Avage Auth0 portaalis laiendused (Extensions) ja installige Auth0 autoriseerimine. Pärast installimist minge aadressile Volituse laiendus, ja seal - rentniku konfiguratsioonile, klõpsates paremas ülanurgas ja valides sobiva menüüvaliku (Konfiguratsioon). Aktiveerige rühmad (Rühmad) ja klõpsake reegli avaldamise nuppu (Avalda reegel).

Loo rühmi

Minge jaotises Autoriseerimise laiendus aadressile grupid ja looge grupp Moderaatorid. Kuna me käsitleme kõiki autentitud kasutajaid tavakasutajatena, ei ole vaja neile täiendavat gruppi luua.

Valige rühm Moderaatorid, Vajutage Lisage liikmeid, lisage oma põhikonto. Jätke mõned kasutajad ilma ühegi rühmata, et veenduda, et neile ei anta juurdepääsu. (Uusi kasutajaid saab luua käsitsi kaudu Auth0 portaal > Kasutajad > Loo kasutaja.)

Lisage juurdepääsulubale rühmanõue

Kasutajaid on gruppidesse lisatud, kuid see teave peab kajastuma ka juurdepääsulubades. OpenID Connecti järgimiseks ja samal ajal vajalike rühmade tagastamiseks peab luba lisama oma kohandatud nõue. Rakendatud Auth0 reeglite kaudu.

Reegli loomiseks minge saidile Auth0 Portal to Reeglid, Vajutage Loo reegel ja valige mallidest tühi reegel.

Kopeerige allolev kood ja salvestage see uue reeglina Lisa rühmanõue (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 esimese autoriseerimislaiendis määratletud kasutajarühma ja lisab selle kohandatud nõudena juurdepääsulubale (selle nimeruumi all, nagu nõuab Auth0).

Tagasi lehele Reeglid ja kontrollige, kas teil on kaks reeglit kirjutatud järgmises järjekorras:

auth0-authorization-extension
Lisa rühmanõue

Järjestus on oluline, kuna rühmaväli saab reegli asünkroonselt auth0-authorization-extension ja pärast seda lisatakse see nõudena teise reegliga. Tulemuseks on selline juurdepääsuluba:

{
 "https://sa.io/group": "Moderators",
 "iss": "https://sentiment-analysis.eu.auth0.com/",
 "sub": "google-oauth2|196405271625531691872"
 // [сокращено для наглядности]
}

Nüüd peate konfigureerima saadiku puhverserveri, et kontrollida kasutajate juurdepääsu, mille jaoks grupp eemaldatakse nõudest (https://sa.io/group) tagastatud juurdepääsulubas. See on artikli järgmise jaotise teema.

Autoriseerimise konfiguratsioon Istios

Töötamiseks autoriseerimiseks peate lubama Istio jaoks RBAC-i. 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"

Selgitus:

1 — lubage RBAC ainult väljal loetletud teenuste ja nimeruumide jaoks Inclusion;
2 — loetleme oma teenuste loendi.

Rakendame konfiguratsiooni järgmise käsuga:

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

Kõik teenused nõuavad nüüd rollipõhist juurdepääsu juhtimist. Teisisõnu on juurdepääs kõikidele teenustele keelatud ja tulemuseks on vastus RBAC: access denied. Nüüd lubame juurdepääsu volitatud kasutajatele.

Juurdepääsu konfiguratsioon tavakasutajatele

Kõigil kasutajatel peab olema juurdepääs SA-Frontendi ja SA-WebAppi teenustele. Rakendatud järgmiste Istio ressursside abil:

Teenuse roll — määrab kasutaja õigused;
ServiceRoleBinding — määrab, kellele see ServiceRole kuulub.

Tavakasutajatele võimaldame 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 rakenda ServiceRole'i kõigile lehe külastajatele (tavakasutaja-teenuse-rolli-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 kasutajatel on juurdepääs SA WebAppile? Ei, poliitika kontrollib JWT märgi 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

Juurdepääs moderaatorite konfiguratsioonile

Moderaatoritele tahame võimaldada juurdepääsu kõikidele 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 tahame selliseid õigusi ainult neile kasutajatele, kelle juurdepääsuluba sisaldab nõuet https://sa.io/group tähendusega 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"

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

Seoses saadikute vahemällu salvestamisega võib autoriseerimisreeglite jõustumiseks kuluda paar minutit. Seejärel saate tagada, et kasutajatel ja moderaatoritel on erinevad juurdepääsutasemed.

Järeldus selle osa kohta

Tõsiselt, kas olete kunagi näinud lihtsamat, lihtsat, skaleeritavat ja turvalist lähenemist autentimisele ja autoriseerimisele?

Ainult kolme Istio ressurssi (RbacConfig, ServiceRole ja ServiceRoleBinding) oli vaja, et saavutada täpne kontroll autentimise ja lõppkasutaja teenustele juurdepääsu lubamise üle.

Lisaks oleme nende küsimuste eest hoolitsenud oma saadikuteenustest, saavutades:

turbeprobleeme ja vigu sisaldada võiva üldise koodi hulga vähendamine;
vähendada rumalate olukordade arvu, kus üks lõpp-punkt osutus väljastpoolt ligipääsetavaks ja unustas sellest teada anda;
kaob vajadus uuendada kõiki teenuseid iga kord, kui lisatakse uus roll või õigus;
et uued teenused oleksid lihtsad, turvalised ja kiired.

Väljund

Istio võimaldab meeskondadel suunata oma ressursid ärikriitilistele ülesannetele ilma teenustele lisakulusid lisamata, muutes need tagasi mikroolekusse.

Artikkel (kolmes osas) andis algteadmised ja valmis praktilised juhised Istioga pärisprojektides alustamiseks.

PS tõlkijalt

Loe ka meie blogist:

"Tagasi mikroteenuste juurde Istioga": 1. osa (peamiste funktsioonide sissejuhatus), 2. osa (marsruutimine, liikluskorraldus);
«Kanal – Kubernetese kerge hooldusvõrk";
«Mis on teenindusvõrk ja miks ma seda vajan [mikroteenustega pilverakenduse jaoks]?'.

Allikas: www.habr.com

Istioga tagasi mikroteenuste juurde. 3. osa