🥇 Torna à i microservizi cù Istio. Parte 3

Nota. transl.: Prima parte sta serie hè stata dedicata à cunnosce e capacità di Istio è dimustrà in l'azzione, u sicondu - routing finamente sintonizatu è gestione di u trafficu di a rete. Avà parlemu di a sicurità: per dimustrà e funzioni basiche ligati à questu, l'autore usa u serviziu d'identità Auth0, ma altri fornituri ponu esse cunfigurati in modu simili.

Avemu stabilitu un cluster Kubernetes in quale avemu implementatu Istio è un esempiu di applicazione di microserviziu, Sentiment Analysis, per dimustrà e capacità di Istio.

Cù Istio, pudemu mantene i nostri servizii chjuchi perchè ùn anu micca bisognu di implementà strati cum'è Retries, Timeouts, Circuit Breakers, Tracing, Monitoring. . In più, avemu usatu tecnichi avanzati di teste è di implementazione: test A/B, mirroring è rollouts canari.

In u novu materiale, avemu da trattà cù i strati finali nantu à a strada di u valore di l'affari: l'autentificazione è l'autorizazione - è in Istio hè un veru piacè!

Authentification et autorisation à Istio

Ùn aghju mai avutu cridutu chì avissi da esse inspiratu da l'autentificazione è l'autorizazione. Chì pò offre Istio da una perspettiva tecnologica per rende questi temi divertenti è, ancu di più, ispiranti per voi?

A risposta hè simplice: Istio cambia a rispunsabilità per queste capacità da i vostri servizii à u proxy Envoy. À u mumentu chì e richieste ghjunghjenu à i servizii, sò digià autentificate è autorizate, cusì tuttu ciò chì avete da fà hè di scrive un codice utili per l'affari.

Pare bè? Fighjemu un ochju à l'internu !

Autentificazione cù Auth0

Cum'è un servitore per a gestione di l'identità è l'accessu, useremu Auth0, chì hà una versione di prova, hè intuitivu à utilizà è mi piace solu. Tuttavia, i stessi principii ponu esse applicati à qualsiasi altru Implementazioni OpenID Connect: KeyCloak, IdentityServer è assai altri.

Prima, andate à Auth0 Portal cù u vostru contu, crea un inquilino (inquilino - "inquilino", unità logica di isolamentu, per più dettagli vede ducumentazione - ca. trad.) è vai à Applicazioni> App Defaultscelta Domain, cum'è mostra in a screenshot sottu:

Specificà stu duminiu in u schedariu resource-manifests/istio/security/auth-policy.yaml (fonte):

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

Cù una tale risorsa, Pilot (unu di i trè cumpunenti di u pianu di cuntrollu di basa in Istio - circa trad.) configura Envoy per autentificà e dumande prima di trasmette à i servizii: sa-web-app и sa-feedback. À u listessu tempu, a cunfigurazione ùn hè micca appiicata à l'Envoys di serviziu sa-frontend, chì ci permette di lascià u frontend micca autenticatu. Per applicà a Politica, eseguite u cumandimu:

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

Ritorna à a pagina è fà una dumanda - vi vede chì finisce cù u statutu 401 Unauthorized. Avà reindirizzemu l'utilizatori di frontend per autentificà cù Auth0.

Autentificà e dumande cù Auth0

Per autentificà e richieste di l'utilizatori finali, avete bisognu di creà una API in Auth0 chì rapprisentarà i servizii autentificati (recensioni, dettagli è valutazioni). Per creà una API, vai à Auth0 Portal > API > Crea API è compie u furmulariu:

L'infurmazione impurtante quì hè identificà, chì avemu aduprà più tardi in u script. Scrivemu cusì cusì:

Audience: {YOUR_AUDIENCE}

I dettagli rimanenti chì avemu bisognu sò situati in u Portal Auth0 in a sezione Travaux - selezziunà Applicazione di prova (creatu automaticamente cù l'API).

Quì scriveremu:

Domain: {YOUR_DOMAIN}
Id. di u cliente: {YOUR_CLIENT_ID}

Scorri à Applicazione di prova à u campu di testu URL di Callback permessi (URL risolti per a callback), in quale avemu specificatu l'URL induve a chjama deve esse mandata dopu chì l'autentificazione hè cumpleta. In u nostru casu hè:

http://{EXTERNAL_IP}/callback

E per URL di Logout permessi (URL permessi per u logu) aghjunghje:

http://{EXTERNAL_IP}/logout

Passemu à u frontend.

Actualizazione di u frontend

Cambia à a filiera auth0 repository [istio-mastery]. In questu ramu, u codice di frontend hè cambiatu per reindirizzà l'utilizatori à Auth0 per l'autentificazione è utilizate u token JWT in richieste à altri servizii. L'ultime hè implementatu cum'è seguita (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));
}

Per cambià u frontend per utilizà i dati di l'inquilanu in Auth0, apre sa-frontend/src/services/Auth.js è rimpiazzà in ellu i valori chì avemu scrittu sopra (Auth.js):

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

L'applicazione hè pronta. Specificate u vostru ID Docker in i cumandamenti sottu quandu custruite è implementate i cambiamenti fatti:

$ 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

Pruvate l'app! Serete reindirizzatu à Auth0, induve avete bisognu di login (o registrà), dopu chì sarete rimandatu à a pagina da quale seranu fatte e richieste digià autentificate. Sè vo pruvate i cumandamenti mintuatu in i primi parti di l 'articulu cù curl, vi tuccherà u codice Codice di Statu 401, signalendu chì a dumanda ùn hè micca autorizata.

Facemu u passu prossimu - autorizà e dumande.

Autorizazione cù Auth0

L'autentificazione ci permette di capisce quale hè un utilizatore, ma l'autorizazione hè necessaria per sapè ciò chì anu accessu. Istio offre strumenti ancu per questu.

Per esempiu, creamu dui gruppi d'utilizatori (vede u diagramma sottu):

Utilizatori (utilizatori) - cù accessu solu à i servizii SA-WebApp è SA-Frontend;
Moderatori (moderatori) - cù accessu à tutti i trè servizii.

Cuncepimentu di l'autorizazione

Per creà questi gruppi, useremu l'estensione Auth0 Authorization è aduprà Istio per furnisce li cù diversi livelli d'accessu.

Installazione è cunfigurazione di Auth0 Authorization

In u portale Auth0, andate à estensioni (Extensions) è stallà Auth0 Authorization. Dopu à a stallazione, vai à Extension d'autorizazione, è quì - à a cunfigurazione di l'inquilanu clicchendu in cima à a diritta è selezziunate l'opzione di menu approprita (Cunfigurazione). Attivate i gruppi (Gruppi) è cliccate nant'à u buttone publicà regula (Regula di publicazione).

Crià gruppi

In Authorization Extension andate à gruppi è creà un gruppu Moderators. Siccomu tratteremu tutti l'utilizatori autentificati cum'è utilizatori regulari, ùn ci hè bisognu di creà un gruppu supplementu per elli.

Sceglite un gruppu Moderators, Press Aghjunghje Membri, aghjunghje u vostru contu principale. Lascià certi utilizatori senza alcunu gruppu per assicurà ch'elli sò nigatu accessu. (U novu utilizatori ponu esse creati manualmente via Auth0 Portal> Users> Crea User.)

Aghjunghjite Reclamazione di Gruppu à Access Token

L'utilizatori sò stati aghjuntu à i gruppi, ma sta infurmazione deve esse ancu riflessa in tokens d'accessu. Per rispettà OpenID Connect è à u stessu tempu vultà i gruppi chì avemu bisognu, u token hà bisognu di aghjunghje u so propiu. reclamazione persunalizata. Implementatu attraversu e regule Auth0.

Per creà una regula, andate à Auth0 Portal à regulamentu, Press Crea una regula è selezziunate una regula viota da i mudelli.

Copia u codice quì sottu è salvà cum'è una nova regula Aghjunghjite una reclamazione di gruppu (namespacedGroup.js):

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

Vita: Stu codice piglia u primu gruppu d'utilizatori definitu in l'Extension d'Autorizazione è l'aghjunghje à u token d'accessu cum'è una pretesa persunalizata (sottu u so spaziu di nome, cum'è necessariu da Auth0).

Ritorna à a pagina regulamentu è verificate chì avete duie regule scritte in l'ordine seguente:

auth0-authorization-extension
Aghjunghjite una reclamazione di gruppu

L'ordine hè impurtante perchè u campu di u gruppu riceve a regula in modu asincronu auth0-authorization-extension è dopu hè aghjuntu cum'è una pretendenza da a seconda regula. U risultatu hè un token d'accessu cum'è questu:

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

Avà avete bisognu di cunfigurà u proxy Envoy per verificà l'accessu di l'utilizatori, per quale u gruppu serà tiratu da a reclamazione (https://sa.io/group) in u token d'accessu restituitu. Questu hè u tema per a prossima sezione di l'articulu.

Configurazione di l'autorizazione in Istio

Per l'autorizazione per travaglià, deve attivà RBAC per Istio. Per fà questu, usemu a seguente cunfigurazione:

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"

Пояснения:

1 - attivà RBAC solu per i servizii è i spazii di nomi listati in u campu Inclusion;
2 - listemu una lista di i nostri servizii.

Applichemu a cunfigurazione cù u cumandimu seguitu:

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

Tutti i servizii necessitanu avà u cuntrollu di l'accessu basatu in u rolu. In altre parolle, l'accessu à tutti i servizii hè pruibitu è risultà in una risposta RBAC: access denied. Avà permettemu l'accessu à l'utilizatori autorizati.

A cunfigurazione di l'accessu per l'utilizatori regulare

Tutti l'utilizatori devenu avè accessu à i servizii SA-Frontend è SA-WebApp. Implementatu cù e seguenti risorse Istio:

Service Role - determina i diritti chì l'utilizatore hà;
ServiceRoleBinding - determina à quale appartene stu ServiceRole.

Per l'utilizatori ordinali permetteremu l'accessu à certi servizii (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: ["*"]

È attraversu regular-user-binding applica ServiceRole à tutti i visitatori di a pagina (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"

"Tutti l'utilizatori" significa chì l'utilizatori micca autenticati anu ancu accessu à a WebApp SA? No, a pulitica verificarà a validità di u token JWT.

Applichemu e cunfigurazioni:

$ 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

A cunfigurazione di l'accessu per i moderatori

Per i moderatori, vulemu attivà l'accessu à tutti i servizii (mod-service-role.yaml):

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

Ma vulemu tali diritti solu per quelli utilizatori chì u token d'accessu cuntene reclamazione https://sa.io/group cun significatu 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"

Applichemu e cunfigurazioni:

$ 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

A causa di a caching in envoys, pò piglià un paru di minuti per e regule d'autorizazione per entra in vigore. Pudete tandu assicurà chì l'utilizatori è i moderatori anu diverse livelli d'accessu.

Conclusioni nantu à sta parte

Seriu però, avete mai vistu un approcciu più simplice, senza sforzu, scalabile è sicuru per l'autentificazione è l'autorizazione?

Solu trè risorse Istio (RbacConfig, ServiceRole, è ServiceRoleBinding) sò stati richiesti per ottene un cuntrollu finitu di l'autentificazione è l'autorizazione di l'accessu di l'utilizatori finali à i servizii.

Inoltre, avemu cura di sti prublemi fora di i nostri servizii di mandatu, ottenendu:

riducendu a quantità di codice genericu chì pò cuntene prublemi di sicurezza è bugs;
riducendu u nùmeru di situazioni stupidi in quale un puntu finale hè diventatu accessibile da l'esternu è scurdatu di rapportà;
eliminendu a necessità di aghjurnà tutti i servizii ogni volta chì un novu rolu o dirittu hè aghjuntu;
chì i novi servizii restanu simplici, sicuri è veloci.

cunchiusioni

Istio permette à e squadre di fucalizza e so risorse nantu à i travaglii critichi per l'affari senza aghjunghje overhead à i servizii, rinviendu à u micro status.

L'articulu (in trè parti) hà furnitu cunniscenze basi è struzzioni pratichi pronti per cumincià cù Istio in prughjetti reali.

PS da u traduttore

Leghjite puru nant'à u nostru blog:

"Torna à i microservizi cù Istio": parte 1 (introduzione à e caratteristiche principali), parte 2 (routing, cuntrollu di trafficu);
«Conduit - maglia di serviziu ligera per Kubernetes";
«Cosa hè una rete di serviziu è perchè ne aghju bisognu [per una applicazione in nuvola cù microservizi]?».

Source: www.habr.com

Torna à i microservizi cù Istio. Parte 3