🥇Takaisin mikropalveluihin Istion kanssa. Osa 3

Huomautus. käännös: Ensimmäinen osa tämä sarja oli omistettu Istion kykyjen tuntemiseen ja niiden näyttämiseen toiminnassa, toinen — Hienosäädetty reititys ja verkkoliikenteen hallinta. Nyt puhutaan turvallisuudesta: siihen liittyvien perustoimintojen esittelyyn kirjoittaja käyttää Auth0-identiteettipalvelua, mutta muut palveluntarjoajat voidaan konfiguroida samalla tavalla.

Perustimme Kubernetes-klusterin, jossa otimme käyttöön Istion ja esimerkkimikropalvelusovelluksen, Sentiment Analysis -sovelluksen, osoittamaan Istion kykyjä.

Istion avulla pystyimme pitämään palvelumme pieninä, koska niiden ei tarvitse toteuttaa tasoja, kuten uudelleenyritykset, aikakatkaisut, katkaisijat, jäljitys, valvonta. Lisäksi käytimme kehittyneitä testaus- ja käyttöönottotekniikoita: A/B-testausta, peilausta ja kanaarin käyttöönottoa.

Uudessa materiaalissa käsittelemme viimeisiä kerroksia matkalla kohti liikearvoa: autentikointia ja valtuutusta - ja Istiossa se on todellinen ilo!

Todennus ja valtuutus Istiossa

En olisi koskaan uskonut, että todennus ja valtuutus inspiroivat minua. Mitä Istio voi tarjota teknologian näkökulmasta tehdäkseen näistä aiheista hauskoja ja ennen kaikkea inspiroivia sinulle?

Vastaus on yksinkertainen: Istio siirtää vastuun näistä ominaisuuksista palveluistasi Envoy-välityspalvelimelle. Kun pyynnöt saapuvat palveluihin, ne on jo todennettu ja valtuutettu, joten sinun tarvitsee vain kirjoittaa yritykselle hyödyllinen koodi.

Kuulostaa hyvältä? Katsotaanpa sisäänpäin!

Todennus Auth0:lla

Palvelimena identiteetin ja pääsyn hallintaan käytämme Auth0:aa, joka on kokeiluversio, on intuitiivinen käyttää ja pidän siitä yksinkertaisesti. Samoja periaatteita voidaan kuitenkin soveltaa mihin tahansa muuhun OpenID Connect -toteutukset: KeyCloak, IdentityServer ja monet muut.

Aloita siirtymällä kohtaan Auth0-portaali luo vuokralainen tililläsi (vuokralainen - "vuokralainen", looginen eristysyksikkö, katso lisätietoja dokumentointi - noin käännös.) ja mene kohtaan Sovellukset > Oletussovellusvalitsemalla Domain, kuten alla olevassa kuvakaappauksessa näkyy:

Määritä tämä verkkotunnus tiedostossa resource-manifests/istio/security/auth-policy.yaml (lähde):

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

Tällaisella resurssilla, Pilot (yksi kolmesta Istion ohjaustason peruskomponentista - noin käännös.) määrittää lähettiläät todentamaan pyynnöt ennen niiden välittämistä palveluille: sa-web-app и sa-feedback. Samanaikaisesti konfiguraatiota ei sovelleta palvelulähettiläisiin sa-frontend, jolloin voimme jättää käyttöliittymän todentamatta. Käytä käytäntöä suorittamalla komento:

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

Palaa sivulle ja tee pyyntö - näet, että se päättyy tilaan 401 luvaton. Ohjataan nyt käyttöliittymän käyttäjät todentamaan Auth0:lla.

Pyyntöjen todennus Auth0:lla

Loppukäyttäjien pyyntöjen todentamiseksi sinun on luotava Auth0:ssa API, joka edustaa todennettuja palveluita (arvostelut, tiedot ja arviot). Luo API siirtymällä osoitteeseen Auth0-portaali > API:t > Luo sovellusliittymä ja täytä lomake:

Tärkeä tieto tässä on tunnistaa, jota käytämme myöhemmin käsikirjoituksessa. Kirjoitetaan se muistiin näin:

yleisö: {YOUR_AUDIENCE}

Muut tarvitsemamme tiedot löytyvät Auth0-portaalin osiosta Sovellukset - valitse Testisovellus (luodaan automaattisesti API:n kanssa).

Täällä kirjoitetaan:

Domain: {YOUR_DOMAIN}
Asiakastunnus: {YOUR_CLIENT_ID}

Vieritä kohtaan Testisovellus tekstikenttään Sallitut takaisinsoitto-URL-osoitteet (ratkaistut URL-osoitteet takaisinsoittoa varten), jossa määritämme URL-osoitteen, johon puhelu lähetetään, kun todennus on suoritettu. Meidän tapauksessamme se on:

http://{EXTERNAL_IP}/callback

Ja sillä Sallitut uloskirjautumisen URL-osoitteet (sallitut URL-osoitteet uloskirjautumista varten) lisää:

http://{EXTERNAL_IP}/logout

Jatketaan etuosaan.

Käyttöliittymän päivitys

Vaihda haaraan auth0 arkisto [istio-mastery]. Tässä haarassa käyttöliittymän koodi muutetaan ohjaamaan käyttäjät Auth0:aan todennusta varten ja käyttämään JWT-tunnusta muiden palvelujen pyynnöissä. Jälkimmäinen toteutetaan seuraavasti (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));
}

Jos haluat vaihtaa käyttöliittymän käyttämään vuokraajan tietoja Auth0:ssa, avaa sa-frontend/src/services/Auth.js ja korvaa siinä arvot, jotka kirjoitimme yllä (Auth.js):

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

Sovellus on valmis. Määritä Docker-tunnuksesi alla olevissa komennoissa, kun rakennat ja otat käyttöön tehtyjä muutoksia:

$ 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

Kokeile sovellusta! Sinut ohjataan sivulle Auth0, jossa sinun tulee kirjautua sisään (tai rekisteröityä), jonka jälkeen sinut ohjataan takaisin sivulle, jolta tehdään jo todennettuja pyyntöjä. Jos kokeilet artikkelin alkuosissa mainittuja komentoja curlilla, saat koodin 401 Tilakoodi, ilmaisee, että pyyntöä ei ole valtuutettu.

Otetaan seuraava askel – hyväksy pyynnöt.

Valtuutus Auth0:lla

Todennuksen avulla voimme ymmärtää, kuka käyttäjä on, mutta valtuutus vaaditaan, jotta voimme tietää, mihin heillä on pääsy. Istio tarjoaa työkaluja myös tähän.

Luodaan esimerkiksi kaksi käyttäjäryhmää (katso alla oleva kaavio):

Jäsenet (käyttäjät) — pääsy vain SA-WebApp- ja SA-Frontend-palveluihin;
Moderaattorit (moderaattorit) — pääsy kaikkiin kolmeen palveluun.

Valtuutuksen käsite

Näiden ryhmien luomiseen käytämme Auth0 Authorization -laajennusta ja Istiota tarjoamaan heille eri käyttöoikeustasot.

Auth0-valtuutuksen asennus ja konfigurointi

Siirry Auth0-portaalissa laajennuksiin (Laajennukset) ja asenna Auth0-valtuutus. Asennuksen jälkeen siirry kohtaan Valtuutuksen laajennus, ja sieltä - vuokralaisen asetuksiin napsauttamalla oikeaa yläkulmaa ja valitsemalla sopiva valikkovaihtoehto (Kokoonpano). Aktivoi ryhmät (Ryhmät) ja napsauta julkaise sääntö -painiketta (Julkaise sääntö).

Luo ryhmiä

Siirry kohtaan Valtuutuslaajennus Ryhmät ja luo ryhmä Moderaattorit. Koska käsittelemme kaikkia todennettuja käyttäjiä tavallisina käyttäjinä, heille ei tarvitse luoda lisäryhmää.

Valitse ryhmä Moderaattorit, Lehdistö Lisää jäseniä, lisää päätilisi. Jätä osa käyttäjistä ilman ryhmää varmistaaksesi, että heiltä evätään pääsy. (Uusia käyttäjiä voidaan luoda manuaalisesti kautta Auth0-portaali > Käyttäjät > Luo käyttäjä.)

Lisää ryhmävaatimus pääsytunnukseen

Käyttäjiä on lisätty ryhmiin, mutta näiden tietojen tulee näkyä myös käyttöoikeuksissa. Tokenin on lisättävä omansa, jotta se noudattaa OpenID Connectia ja palauttaa samalla tarvitsemamme ryhmät mukautettu vaatimus. Toteutettu Auth0-sääntöjen kautta.

Luo sääntö siirtymällä Auth0-portaaliin Säännöt, Lehdistö Luo sääntö ja valitse tyhjä sääntö malleista.

Kopioi alla oleva koodi ja tallenna se uutena sääntönä Lisää ryhmävaatimus (namespacedGroup.js):

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

Huomata: Tämä koodi ottaa ensimmäisen valtuutuslaajennuksessa määritellyn käyttäjäryhmän ja lisää sen käyttöoikeustunnukseen mukautettuna vaatimuksena (nimiavaruudessaan, kuten Auth0 vaatii).

Palaa sivulle Säännöt ja tarkista, että olet kirjoittanut kaksi sääntöä seuraavassa järjestyksessä:

auth0-authorization-extension
Lisää ryhmävaatimus

Järjestys on tärkeä, koska ryhmäkenttä vastaanottaa säännön asynkronisesti auth0-authorization-extension ja sen jälkeen se lisätään vaatimuksena toisella säännöllä. Tuloksena on tällainen käyttöoikeustunnus:

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

Nyt sinun on määritettävä Envoy-välityspalvelin tarkistamaan käyttäjien pääsy, jota varten ryhmä poistetaan vaatimuksesta (https://sa.io/group) palautetussa käyttöoikeustunnuksessa. Tämä on artikkelin seuraavan osan aihe.

Valtuutusmääritys Istiossa

Jotta valtuutus toimisi, sinun on otettava RBAC käyttöön Istiolle. Käytämme tätä varten seuraavaa kokoonpanoa:

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"

Selitys:

1 — ota RBAC käyttöön vain kentässä luetelluissa palveluissa ja nimiavaruuksissa Inclusion;
2 — luettelemme palveluistamme.

Otetaan kokoonpano käyttöön seuraavalla komennolla:

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

Kaikki palvelut edellyttävät nyt roolipohjaista pääsynhallintaa. Toisin sanoen pääsy kaikkiin palveluihin on kielletty ja johtaa vastaukseen RBAC: access denied. Sallitaan nyt pääsy valtuutetuille käyttäjille.

Pääsymääritykset tavallisille käyttäjille

Kaikilla käyttäjillä on oltava pääsy SA-Frontend- ja SA-WebApp-palveluihin. Toteutettu käyttämällä seuraavia Istion resursseja:

Palvelurooli — määrittää käyttäjän oikeudet;
ServiceRoleBinding — määrittää, kenelle tämä palvelurooli kuuluu.

Tavallisille käyttäjille sallimme pääsyn tiettyihin palveluihin (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 jälkeen regular-user-binding käytä ServiceRolea kaikille sivun vierailijoille (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"

Tarkoittaako "kaikki käyttäjät" sitä, että myös todentamattomat käyttäjät pääsevät käyttämään SA WebAppia? Ei, käytäntö tarkistaa JWT-tunnuksen voimassaolon.

Otetaan käyttöön kokoonpanot:

$ 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

Pääsymääritykset valvojille

Moderaattoreille haluamme sallia pääsyn kaikkiin palveluihin (mod-service-role.yaml):

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

Mutta haluamme tällaiset oikeudet vain niille käyttäjille, joiden käyttöoikeustunnus sisältää vaatimuksen https://sa.io/group arvoilla 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"

Otetaan käyttöön kokoonpanot:

$ 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

Lähettilöiden välimuistiin tallentamisen vuoksi valtuutussääntöjen voimaantulo voi kestää muutaman minuutin. Tämän jälkeen voit varmistaa, että käyttäjillä ja valvojilla on eri käyttöoikeustasot.

Johtopäätös tästä osasta

Vakavasti, oletko koskaan nähnyt yksinkertaisempaa, vaivatonta, skaalautuvaa ja turvallisempaa lähestymistapaa todentamiseen ja valtuutukseen?

Vain kolme Istio-resurssia (RbacConfig, ServiceRole ja ServiceRoleBinding) vaadittiin todennuksen ja palvelujen valtuutuksen tarkkaan valvontaan.

Lisäksi olemme hoitaneet nämä asiat lähettipalveluistamme ja saavuttaneet:

vähentää yleisen koodin määrää, joka saattaa sisältää tietoturvaongelmia ja -virheitä;
vähennetään niiden typerien tilanteiden määrää, joissa yksi päätepiste osoittautui ulkopuolelta saavutettavaksi ja unohti ilmoittaa siitä;
poistaa tarpeen päivittää kaikkia palveluita aina, kun uusi rooli tai oikeus lisätään;
että uudet palvelut pysyvät yksinkertaisina, turvallisina ja nopeina.

johtopäätös

Istio antaa tiimeille mahdollisuuden keskittää resurssinsa liiketoimintakriittisiin tehtäviin ilman, että ne lisäävät palveluihin ylimääräisiä kustannuksia ja palauttavat ne mikrotilanteeseen.

Artikkeli (kolmiosainen) antoi perustiedot ja valmiita käytännön ohjeita Istion aloittamiseen todellisissa projekteissa.

PS kääntäjältä

Lue myös blogistamme:

"Takaisin mikropalveluihin Istion kanssa": osa 1 (johdanto pääominaisuuksiin), osa 2 (reititys, liikenteenohjaus);
«Conduit - kevyt huoltoverkko Kubernetesille";
«Mikä on palveluverkko ja miksi tarvitsen sitä [pilvisovellukselle, jossa on mikropalvelut]?'.

Lähde: will.com

Takaisin mikropalveluihin Istion kanssa. Osa 3