Înapoi la microservicii cu Istio. Partea 3

Notă. transl.: Prima parte această serie a fost dedicată cunoașterii capacităților lui Istio și demonstrarea lor în acțiune, în al doilea rând — rutare reglată fin și gestionarea traficului de rețea. Acum vom vorbi despre securitate: pentru a demonstra funcțiile de bază legate de aceasta, autorul folosește serviciul de identitate Auth0, dar alți furnizori pot fi configurați într-un mod similar.

Am creat un cluster Kubernetes în care am implementat Istio și un exemplu de aplicație de microservicii, Sentiment Analysis, pentru a demonstra capabilitățile Istio.

Cu Istio, am reușit să ne menținem serviciile mici, deoarece nu au nevoie să implementeze straturi precum Retries, Timeouts, Circuit Breakers, Tracing, Monitoring. În plus, am folosit tehnici avansate de testare și implementare: testare A/B, oglindire și lansări Canary.

În noul material, ne vom ocupa de ultimele straturi pe calea către valoarea afacerii: autentificare și autorizare - iar în Istio este o adevărată plăcere!

Autentificare și autorizare în Istio

Nu aș fi crezut niciodată că voi fi inspirat de autentificare și autorizare. Ce poate oferi Istio din perspectiva tehnologiei pentru a face aceste subiecte distractive și, cu atât mai mult, pentru a vă inspira?

Răspunsul este simplu: Istio transferă responsabilitatea pentru aceste capabilități de la serviciile dumneavoastră către proxy-ul Envoy. Până când solicitările ajung la servicii, acestea au fost deja autentificate și autorizate, așa că tot ce trebuie să faceți este să scrieți cod util pentru afaceri.

Sună bine? Să aruncăm o privire înăuntru!

Autentificare cu Auth0

Ca server pentru administrarea identității și accesului, vom folosi Auth0, care are o versiune de probă, este intuitiv de utilizat și pur și simplu îmi place. Cu toate acestea, aceleași principii pot fi aplicate oricărui altul Implementări OpenID Connect: KeyCloak, IdentityServer și multe altele.

Pentru a începe, accesați Auth0 Portal cu contul dvs., creați un chiriaș (chiriaș - „chiriaș”, unitate logică de izolare, pentru mai multe detalii vezi documentație - aprox. traducere) și du-te la Aplicații > Aplicație implicităalegerea domeniu, așa cum se arată în captura de ecran de mai jos:

Specificați acest domeniu în fișier resource-manifests/istio/security/auth-policy.yaml (sursă):

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

Cu o astfel de resursă, Pilot (una dintre cele trei componente de bază ale planului de control din Istio - aprox. traducere) configurează Envoy să autentifice cererile înainte de a le redirecționa către servicii: sa-web-app и sa-feedback. În același timp, configurația nu este aplicată pentru serviciul Envoys sa-frontend, permițându-ne să lăsăm interfața neautentificată. Pentru a aplica politica, rulați comanda:

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

Reveniți la pagină și faceți o cerere - veți vedea că se termină cu starea 401 neautorizat. Acum să redirecționăm utilizatorii de front-end pentru a se autentifica cu Auth0.

Autentificarea cererilor cu Auth0

Pentru a autentifica solicitările utilizatorilor finali, trebuie să creați un API în Auth0 care va reprezenta serviciile autentificate (recenzii, detalii și evaluări). Pentru a crea un API, accesați Auth0 Portal > API-uri > Creați API si completati formularul:

Informația importantă aici este Identifier, pe care îl vom folosi mai târziu în script. Să o scriem astfel:

• Public: {YOUR_AUDIENCE}

Restul detaliilor de care avem nevoie se află pe Portalul Auth0 din secțiunea aplicatii - Selectați Aplicație de testare (creat automat împreună cu API-ul).

Aici vom scrie:

• domeniu: {YOUR_DOMAIN}
• Cod client: {YOUR_CLIENT_ID}

Derulați la Aplicație de testare la câmpul de text Adrese URL de apel invers permise (URL-uri rezolvate pentru apel invers), în care specificăm adresa URL la care ar trebui trimis apelul după finalizarea autentificării. In cazul nostru este:

http://{EXTERNAL_IP}/callback

Și pentru Adrese URL de deconectare permise (adrese URL permise pentru deconectare) adăugați:

http://{EXTERNAL_IP}/logout

Să trecem la front-end.

Actualizare front-end

Comutați la ramură auth0 repertoriu [istio-mastery]. În această ramură, codul de front-end este modificat pentru a redirecționa utilizatorii către Auth0 pentru autentificare și pentru a utiliza jetonul JWT în cererile către alte servicii. Acesta din urmă este implementat după cum urmează (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));
}

Pentru a schimba frontend-ul pentru a utiliza datele chiriașilor în Auth0, deschideți sa-frontend/src/services/Auth.js și înlocuiți în el valorile pe care le-am scris mai sus (Auth.js):

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

Aplicația este gata. Specificați ID-ul dvs. Docker în comenzile de mai jos atunci când construiți și implementați modificările efectuate:

$ 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

Încearcă aplicația! Veți fi redirecționat către Auth0, unde trebuie să vă autentificați (sau să vă înregistrați), după care veți fi trimis înapoi pe pagina de pe care se vor face cererile deja autentificate. Dacă încerci comenzile menționate în primele părți ale articolului cu curl, vei obține codul 401 Cod de stare, semnalând că cererea nu este autorizată.

Să facem următorul pas - autorizarea solicitărilor.

Autorizare cu Auth0

Autentificarea ne permite să înțelegem cine este un utilizator, dar este necesară autorizarea pentru a ști la ce are acces. Istio oferă instrumente și pentru aceasta.

De exemplu, să creăm două grupuri de utilizatori (vezi diagrama de mai jos):

• utilizatori (utilizatori) — cu acces numai la serviciile SA-WebApp și SA-Frontend;
• Moderatori (moderatori) — cu acces la toate cele trei servicii.

Conceptul de autorizare

Pentru a crea aceste grupuri, vom folosi extensia Auth0 Authorization și vom folosi Istio pentru a le oferi diferite niveluri de acces.

Instalarea și configurarea Autorizării Auth0

În portalul Auth0, accesați extensii (Extensii) și instalați Auth0 Autorizare. După instalare, accesați Extensie de autorizare, și acolo - la configurația chiriașului făcând clic în dreapta sus și selectând opțiunea de meniu corespunzătoare (Configurare). Activați grupuri (Grupuri) și faceți clic pe butonul de publicare a regulii (Regula de publicare).

Creați grupuri

În Extensie de autorizare accesați grupuri și creați un grup moderatori. Deoarece vom trata toți utilizatorii autentificați ca utilizatori obișnuiți, nu este nevoie să creăm un grup suplimentar pentru ei.

Alegeți un grup moderatori, Presa Adăugați membri, adăugați contul dvs. principal. Lăsați unii utilizatori fără niciun grup pentru a vă asigura că li se refuză accesul. (Utilizatorii noi pot fi creați manual prin Auth0 Portal > Utilizatori > Creați utilizator.)

Adăugați revendicare de grup la Token de acces

Utilizatorii au fost adăugați în grupuri, dar aceste informații trebuie să se reflecte și în jetoanele de acces. Pentru a respecta OpenID Connect și, în același timp, a returna grupurile de care avem nevoie, tokenul va trebui să-și adauge propriul revendicare personalizată. Implementat prin regulile Auth0.

Pentru a crea o regulă, accesați Portalul Auth0 pentru Reguli, Presa Creați o regulă și selectați o regulă goală din șabloane.

Copiați codul de mai jos și salvați-l ca regulă nouă Adăugați revendicare de grup (namespacedGroup.js):

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

Nota: Acest cod preia primul grup de utilizatori definit în Extensia de autorizare și îl adaugă la jetonul de acces ca o revendicare personalizată (sub spațiul său de nume, așa cum este cerut de Auth0).

Reveniți la pagină Reguli și verificați dacă aveți două reguli scrise în următoarea ordine:

• auth0-autorizare-extensie
• Adăugați revendicare de grup

Ordinea este importantă deoarece câmpul grup primește regula în mod asincron auth0-autorizare-extensie iar după aceea se adaugă ca revendicare prin regula a doua. Rezultatul este un token de acces ca acesta:

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

Acum trebuie să configurați proxy-ul Envoy pentru a verifica accesul utilizatorului, pentru care grupul va fi scos din revendicare (https://sa.io/group) în jetonul de acces returnat. Acesta este subiectul pentru următoarea secțiune a articolului.

Configurare autorizare în Istio

Pentru ca autorizarea să funcționeze, trebuie să activați RBAC pentru Istio. Pentru a face acest lucru, vom folosi următoarea configurație:

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" 

Explicație:

• 1 — activați RBAC numai pentru serviciile și spațiile de nume listate în câmp Inclusion;
• 2 — listăm o listă a serviciilor noastre.

Să aplicăm configurația cu următoarea comandă:

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

Toate serviciile necesită acum controlul accesului bazat pe rol. Cu alte cuvinte, accesul la toate serviciile este interzis și va avea ca rezultat un răspuns RBAC: access denied. Acum să permitem accesul utilizatorilor autorizați.

Configurație de acces pentru utilizatorii obișnuiți

Toți utilizatorii trebuie să aibă acces la serviciile SA-Frontend și SA-WebApp. Implementat folosind următoarele resurse Istio:

• ServiceRole — stabilește drepturile de care dispune utilizatorul;
• ServiceRoleBinding — determină cui îi aparține acest ServiceRole.

Pentru utilizatorii obișnuiți vom permite accesul la anumite servicii (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: ["*"]

Și prin regular-user-binding aplicați ServiceRole tuturor vizitatorilor paginii (normal-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"

„Toți utilizatorii” înseamnă că și utilizatorii neautentificați vor avea acces la SA WebApp? Nu, politica va verifica validitatea simbolului JWT.

Să aplicăm configurațiile:

$ 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

Configurarea accesului pentru moderatori

Pentru moderatori, dorim să permitem accesul la toate serviciile (mod-service-role.yaml):

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

Dar dorim astfel de drepturi numai pentru acei utilizatori al căror simbol de acces conține revendicare https://sa.io/group cu sens 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" 

Să aplicăm configurațiile:

$ 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

Din cauza stocării în cache în envoys, poate dura câteva minute pentru ca regulile de autorizare să intre în vigoare. Vă puteți asigura apoi că utilizatorii și moderatorii au niveluri diferite de acces.

Concluzie pe această parte

Serios, totuși, ați văzut vreodată o abordare mai simplă, fără efort, scalabilă și sigură a autentificării și autorizării?

Doar trei resurse Istio (RbacConfig, ServiceRole și ServiceRoleBinding) au fost necesare pentru a obține un control fin asupra autentificării și autorizarea accesului utilizatorului final la servicii.

În plus, ne-am ocupat de aceste probleme din serviciile noastre de trimis, realizând:

• reducerea cantității de cod generic care poate conține probleme de securitate și bug-uri;
• reducerea numărului de situații stupide în care un punct final s-a dovedit a fi accesibil din exterior și a uitat să-l raporteze;
• eliminarea necesității actualizării tuturor serviciilor de fiecare dată când se adaugă un nou rol sau drept;
• că noile servicii rămân simple, sigure și rapide.

Producție

Istio permite echipelor să-și concentreze resursele asupra sarcinilor esențiale pentru afaceri fără a adăuga cheltuieli generale la servicii, revenindu-le la starea micro.

Articolul (în trei părți) a oferit cunoștințe de bază și instrucțiuni practice gata făcute pentru a începe cu Istio în proiecte reale.

PS de la traducator

Citește și pe blogul nostru:

• „Înapoi la microservicii cu Istio”: partea 1 (introducere în caracteristicile principale), partea 2 (traseu, controlul traficului);
• «Conduit - plasă de serviciu ușoară pentru Kubernetes»;
• «Ce este o plasă de servicii și de ce am nevoie de ea [pentru o aplicație cloud cu microservicii]?".

Sursa: www.habr.com