🥇Nazaj k mikroservisom z Istio. Del 3

Op. prev.: Prvi del Ta cikel je bil posvečen spoznavanju zmožnosti Istio in njihovemu prikazu v akciji, dva — natančno prilagodljivi usmerjanju in upravljanju omrežnega prometa. Zdaj pa se bomo osredotočili na varnost: za prikaz osnovnih povezanih funkcij avtor uporablja identitetni servis Auth0, vendar pa se lahko po analogiji nastavljajo tudi drugi ponudniki.

Nastavili smo Kubernetes-klaster, v katerem smo namestili Istio in primer mikrostoritvenega aplikacije Sentiment Analysis, — tako so bile prikazane zmožnosti Istio.

S pomočjo Istio smo uspeli ohraniti majhno velikost storitev, saj ne potrebujejo izvajanja takšnih "plasti", kot so ponovni poskusi povezovanja (Retries), časovne omejitve (Timeouts), avtomatski prekinjevalniki (Circuit Breakers), sledenje (Tracing), spremljanje (Monitoring). Poleg tega smo uporabili tehnike naprednega testiranja in uvajanja: A/B-testiranje, zrcaljenje in kanarčne uvedbe.

V novem gradivu bomo raziskali končne plasti na poti do poslovne vrednosti: avtentikacijo in avtorizacijo — in v Istio je to pravo veselje!

Avtentikacija in avtorizacija v Istio

Nikoli ne bi verjel, da me lahko navdihne avtentikacija in avtorizacija. Kaj pa lahko Istio ponudi s tehnološkega vidika, da bi te teme naredilo zanimive in celo navdihujoče tudi za vas?

Odgovor je preprost: Istio prenaša odgovornost za te zmožnosti z vaših storitev na proxy Envoy. Do trenutka, ko zahtevki dosežejo storitve, so že avtenticirani in avtorizirani, tako da vam ostane le še pisati kodo, koristno za poslovanje.

Zveni dobro? Poglejmo notranjost!

Avtentikacija z Auth0

Kot strežnik za upravljanje identitete in dostopa bomo uporabljali Auth0, ki ima preizkusno različico, ki je intuitivna za uporabo in mi je preprosto všeč. Vendar pa iste principe lahko uporabite tudi za katero koli drugo implementacijo OpenID Connect: KeyCloak, IdentityServer in mnoge druge.

Za začetek pojdite na Auth0 Portal s svojim računom, ustvarite najemnika (najemnik — "tenant", logična enota izolacije, več informacij v dokumenti — op. prev.) in pojdite v Applications > Default App, izberite Domena, kot je prikazano na spodnji sliki:

Domeno navedite v datoteki resource-manifests/istio/security/auth-policy.yaml (izvor):

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

Having this resource, Pilot (one of the three basic components of the Control Plane in Istio — editor's note) configures Envoys to authenticate requests before redirecting them to services: sa-web-app in sa-feedback. At the same time, the configuration does not apply to the service Envoys sa-frontend, allowing us to keep the frontend unauthenticated. To apply the policy, run the command:

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

Return to the page and make a request — you will see that it finishes with status 401 Unauthorized. Now we will redirect frontend users to authenticate with Auth0.

Authenticating requests with Auth0

To authenticate end-user requests, you need to create an API in Auth0 that will represent the authenticated services (reviews, details, and ratings). To create the API, go to Auth0 Portal > APIs > Create API and fill out the form:

An important piece of information here is Identifier, which we will later use in the script. Let's note it like this:

Audience: {YOUR_AUDIENCE}

The remaining details we need are located on the Auth0 Portal in the section Applications — choose Test Application (automatically created together with the API).

Here we will note:

Domena: {YOUR_DOMAIN}
Client Id: {YOUR_CLIENT_ID}

Scroll down to the text field Test Application Allowed Callback URLs (allowed URLs for callback), where we will specify the URL to which the call should be sent after authentication is complete. In our case, it is: http://{EXTERNAL_IP}/callback

And for

Allowed Logout URLs (allowed URLs for logout) we will add: http://{EXTERNAL_IP}/logout

Let's move to the frontend.

Frontend updates

auth0

Preklopite na vejo repository. In this branch, the frontend code has been modified to redirect users to Auth0 for authentication and use the JWT token in requests to other services. The last part is implemented like this ( [istio-mastery]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)); }App.js):

To switch the frontend to use data from the tenant in Auth0, open

. sa-frontend/src/services/Auth.js in ga spremenite vrednosti, ki smo jih zapisali zgoraj (Auth.js):

const Config = {
    clientID: '{YOUR_CLIENT_ID}',
    domain:'{YOUR_DOMAIN}',
    audience: '{YOUR_AUDIENCE}',
    ingressIP: '{EXTERNAL_IP}' // Uporablja se za preusmeritev po avtentikaciji
}

Aplikacija je pripravljena. V spodnjih ukazih navedite svoj Docker ID pri sestavljanju in nameščanju opravljenih sprememb:

$ 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

Preizkusite aplikacijo! Preusmerili vas bodo na Auth0, kjer se morate prijaviti (ali registrirati), nato pa vas bodo vrnili na stran, s katere bodo potekali že avtorizirani zahtevki. Če pa poskusite prej omenjene ukaze s curl – boste dobili kodo 401 Statusna koda, ki signalizira, da zahteva ni avtorizirana.

Naredimo naslednji korak – avtorizirajmo zahteve.

Avtorizacija z Auth0

Avtifikacija nam omogoča, da razumemo, kdo je uporabnik, toda za to, da izvemo, do česa ima dostop, potrebujemo avtorizacijo. Istio ponuja orodja tudi za to.

Kot primer bomo ustvarili dve skupini uporabnikov (glejte shemo spodaj):

Korisnici (uporabniki) — z dostopom samo do storitev SA-WebApp in SA-Frontend;
Moderatorji (moderatorji) — z dostopom do vseh treh storitev.

Koncept avtorizacije

Za ustvarjanje teh skupin bomo uporabili razširitev Auth0 Authorization in z uporabo Istio zagotovili različne ravni dostopa.

Namestitev in konfiguracija Auth0 Authorization

Na portalu Auth0 prejdite na razširitve (Razširitve) in namestite Auth0 Authorization. Po namestitvi preidite na Razširitev za avtorizacijo, in nato k konfiguraciji najema s klikom na desni zgornji del in izbiro ustrezne možnosti iz menija (Konfiguracija). Aktivirajte skupine (Skupine) in kliknite gumb za objavo pravil (Objavi pravilo).

Ustvarjanje skupin

V razširitvi za avtorizacijo prejdite na Skupine in ustvarite skupino Moderatorji.Ker bomo vse avtorizirane uporabnike obravnavali kot običajne, potreba po ustvarjanju dodatne skupine zanje ni.

Izberite skupino Moderatorji., kliknite na Dodaj člane, dodajte svoj glavni račun. Nekaterih uporabnikov pustite brez katere koli skupine, da se prepričate, da jim je dostop prepovedan. (Nove uporabnike lahko ustvarite ročno prek Auth0 Portal > Uporabniki > Ustvari uporabnika.)

Dodajte Group Claim v Access Token

Uporabniki so bili dodani v skupine, vendar morajo biti te informacije odražene tudi v dostopnih žetonih. Da bi ustrezali OpenID Connect in hkrati vračali skupine, ki jih potrebujemo, bo žetonu potrebno dodati svojo prilagojeno trditev. To se uresničuje preko pravil Auth0.

Za ustvarjanje pravila pojdite na Auth0 Portal k Pravila, kliknite na Ustvari pravilo in izberite prazno pravilo iz predlog.

Kopirajte spodnjo kodo in jo shranite kot novo pravilo Dodaj skupinsko trditev (namespacedGroup.js):

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

Napomena: ta koda vzame prvo skupino uporabnika, določeno v razširitvi za avtentikacijo, in jo doda v dostopni žeton kot prilagojeno trditev (pod svojim prostorom imen, kot to zahteva Auth0).

Vrni se na stran Pravila in preverite, da imate dva pravila zapisana v naslednjem vrstnem redu:

auth0-authorization-extension
Dodaj skupinsko trditev

Vrstni red je pomemben, ker polje skupine asinkrono pridobi pravilo auth0-authorization-extension in se nato doda kot trditev drugim pravilom. Posledično imamo tak dostopni žeton:

{
 "https://sa.io/group": "Moderators",
 "iss": "https://sentiment-analysis.eu.auth0.com/",
 "sub": "google-oauth2|196405271625531691872"
 // [skrajšano za preglednost]
}

Sedaj je potrebno konfigurirati Envoy-proxy za preverjanje uporabniškega dostopa, za kar se bo skupina pridobila iz trditve (https://sa.io/group) v vrnjenem dostopnem žetonu. To je tema za naslednji del članka.

Konfiguracija avtentikacije v Istio

Da avtentikacija deluje, je potrebno vključiti RBAC za Istio. Uporabili bomo naslednjo konfiguracijo:

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"

Pojasnila:

1 — vključujemo RBAC samo za storitve in prostorske imene, navedene na polju Inclusion;
2 — naštevanje našega seznama storitev.

Konfiguracijo bomo uporabili s to ukazno vrstico:

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

Sedaj vse storitve zahtevajo upravljanje dostopa na osnovi vlog (Role-Based Access Control). Z drugimi besedami, dostop do vseh storitev je prepovedan in bo privedel do odgovora RBAC: dostop zavrnjen. Zdaj bomo dovolili dostop pooblaščenim uporabnikom.

Konfiguracija dostopa za običajne uporabnike

Vsi uporabniki morajo imeti dostop do storitev SA-Frontend in SA-WebApp. To se uresničuje s pomočjo naslednjih virov Istio:

ServiceRole — določajo pravice, ki jih ima uporabnik;
ServiceRoleBinding — določa, na koga se ta ServiceRole nanaša.

Za običajne uporabnike bomo dovolili dostop do določenih storitev (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: ["*"]

In preko regular-user-binding bomo uporabili ServiceRole za vse obiskovalce strani (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"

Ali pomeni "vse uporabnike", da bodo tudi neavtorizirani uporabniki imeli dostop do SA WebApp? Ne, politika bo preverila veljavnost JWT žetona.

Uporabimo konfiguracije:

$ 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

Konfiguracija dostopa za moderatorje

Za moderatorje želimo omogočiti dostop do vseh storitev (mod-service-role.yaml):

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

Ampak želimo take pravice samo za tiste uporabnike, katerih access-žeton vsebuje claim https://sa.io/group z vrednostjo Moderatorji. (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"

Uporabimo konfiguracije:

$ 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

Zaradi predpomnjenja v envoy-ih lahko traja nekaj minut, da začnejo veljati pravila avtentikacije. Po tem boste lahko preverili, da imajo uporabniki in moderatorji različne ravni dostopa.

Zaključek tega dela

Ali ste kdaj videli bolj preprost, brez napora, razširljiv in varen pristop k avtentikaciji in avtorizaciji?

Samo tri vire Istio (RbacConfig, ServiceRole in ServiceRoleBinding) so potrebni za dosego natančnega nadzora nad avtentikacijo in avtorizacijo dostopa končnih uporabnikov do storitev.

Poleg tega smo te težave prenesli iz naših storitev na envoy-e, s čimer smo dosegli:

zmanjšanje količine standardne kode, kjer lahko pride do varnostnih težav in napak;
zmanjšanje števila neumnosti, v katerih je bil en endpoint dostopen od zunaj in je to pozabil sporočiti;
odstranitev potrebe po posodabljanju vseh storitev ob vsakem dodajanju nove vloge ali pravice;
da novi sistemi ostanejo preprosti, varni in hitri.