🥇Vissza a mikroszolgáltatásokhoz az Istio mellett. Harmadik rész

Megjegyzés fordítás.: Első rész Ez a ciklus az Istio lehetőségeinek megismerésére és azok működés közbeni bemutatására összpontosított. második — finomhangolt útválasztásra és a hálózati forgalom kezelésére. Most a biztonságról lesz szó: az ehhez kapcsolódó alapvető funkciók bemutatásához az író az Auth0 identitás-szolgáltatót használja, de más szolgáltatók is beállíthatók hasonló módon.

Beállítottunk egy Kubernetes klasztert, amelyben telepítettük az Istio-t és a Sentiment Analysis példamicroservice alkalmazást, — így bemutattuk az Istio lehetőségeit.

Az Istio segítségével sikerült megőriznünk a szolgáltatások kis méretét, mivel nem szükséges olyan ,,rétegeket'' megvalósítaniuk, mint a csatlakozási újrapróbálkozások (Retries), időkorlátok (Timeouts), automatikus áramkör megszakítók (Circuit Breakers), nyomkövetés (Tracing), monitorozás (Monitoring). Ezen kívül haladó tesztelési és telepítési technikákat is alkalmaztunk: A/B tesztelés, tükörképzés és kanári kiadások.

Az új anyagban a business value felé vezető végső rétegeket vesszük át: hitelesítés és engedélyezés — az Istio esetében ez igazi élvezet!

Hitelesítés és engedélyezés az Istio-ban

Soha nem gondoltam volna, hogy a hitelesítés és engedélyezés inspirálni fog. Mi az, amit technológiai szempontból az Istio nyújthat, hogy ezeket a témákat izgalmassá és még inkább inspirálóvá tegye?

A válasz egyszerű: az Istio áthelyezi ezen lehetőségek felelősségét az Ön szolgáltatásairól az Envoy proxira. Mire a kérések elérik a szolgáltatásokat, már hitelesítve és engedélyezve vannak, így neked már csak hasznos üzleti kódot kell írnod.

Jól hangzik? Nézzük meg hát a részleteket!

Hitelesítés az Auth0-val

Identitás- és hozzáféréskezelő szerverként az Auth0-t fogjuk használni, amelynek van egy próbaverziója, intuitív használata van, és egyszerűen tetszik nekem. Egyébként ugyanezeket az elveket bármely más OpenID Connect megvalósításra is alkalmazni lehet: KeyCloak, IdentityServer és még sok más.

Először is, lépj be az Auth0 Portal-ba a fiókoddal, hozz létre egy tenantot (tenant — 'bérlő', logikai izolációs egység, részletesebben lásd: az dokumentáció — a fordító megjegyzése) és lépj be a Applications > Default App, válaszd ki Domain, ahogy az alábbi képernyőképen látható:

Add meg ezt a domént a resource-manifests/istio/security/auth-policy.yaml fájlban (forráskódban):

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

Egy ilyen erőforrással a Pilot (az Istio Control Plane három alapvető komponensének egyike — a fordító megjegyzése) beállítja az Envoy-t, hogy hitelesítse a kéréseket, mielőtt azokat a szolgáltatásokhoz továbbítaná: sa-web-app és sa-feedback. Ugyanakkor a konfiguráció nem vonatkozik a szolgáltatás Envoy-jára, sa-frontendami lehetővé teszi számunkra, hogy a frontend ne legyen hitelesítve. A politika (Policy) alkalmazásához futtassa a következő parancsot:

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

Térjen vissza az oldalra és küldjön kérést — látni fogja, hogy az státuszra ér véget: 401 Unauthorized. Most irányítsuk a frontend felhasználókat az Auth0 hitelesítés felé.

Kérések hitelesítése Auth0-val

A végfelhasználó kéréseinek hitelesítéséhez egy API-t kell létrehozni az Auth0-ban, amely az hitelesített szolgáltatásokat képviseli (reviews, details és ratings). Az API létrehozásához lépjen a Auth0 Portal > APIs > Create API és töltse ki az űrlapot:

Fontos információ itt a Identifier, amelyet később a szkripthez fogunk használni. Írjuk le így:

Audience: {YOUR_AUDIENCE}

A szükséges többi részlet az Auth0 Portal-on található az Applications — válassza a Test Application (automatikusan létrejön az API-val együtt).

Itt feljegyezzük:

Domain: {YOUR_DOMAIN}
Client Id: {YOUR_CLIENT_ID}

Görgessen le a Test Application szöveges mezőhöz Allowed Callback URLs (engedélyezett URL-ek a callback számára), ahol megadjuk az URL-t, ahová a hívásnak mennie kell, miután a hitelesítés befejeződött. Ebben az esetben ez:

http://{EXTERNAL_IP}/callback

A Allowed Logout URLs (engedélyezett URL-ek a kijelentkezéshez) esetén hozzáadjuk:

http://{EXTERNAL_IP}/logout

Lépjünk a frontendhez.

Frontend frissítése

Váltson a auth0 repository [istio-mastery]. Ebben az ágon a frontend kódja megváltozott, hogy a felhasználók Auth0-ra irányuljanak a hitelesítéshez és JWT-token-t használjon a többi szolgáltatás kéréséhez. Az utóbbit így valósítják meg (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));
}

Ahhoz, hogy a frontend tenant adatait az Auth0-ban használja, nyissa meg sa-frontend/src/services/Auth.js és cserélje ki benne azokat az értékeket, amelyeket fentebb rögzítettünk (Auth.js):

const Config = {
    clientID: '{YOUR_CLIENT_ID}',
    domain:'{YOUR_DOMAIN}',
    audience: '{YOUR_AUDIENCE}',
    ingressIP: '{EXTERNAL_IP}' // A hitelesítés után történő átirányításhoz használva
}

Az alkalmazás készen áll. Adja meg a Docker ID-ját az alábbi parancsokban a módosítások felépítése és telepítése során:

$ 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

Próbálja ki az alkalmazást! Átirányítják az Auth0-ra, ahol be kell jelentkeznie (vagy regisztrálnia), majd visszakerül az oldalra, ahonnan már hitelesített kéréseket fog végezni. Ha azonban a cikk első részeiben említett curl parancsokat próbálja meg, akkor a következő kódot kapja 401 Status Code, ami azt jelzi, hogy a kérés nem hitelesített.

Tegyük meg a következő lépést – hitelesítsük a kéréseket.

Hitelesítés az Auth0-val

A hitelesítés lehetővé teszi számunkra, hogy megértsük, ki a felhasználó, de ahhoz, hogy megtudjuk, mihez van hozzáférése, szükség van a jogosultságok létesítésére. Az Istio eszközöket kínál erre is.

Példaként létrehozunk két felhasználói csoportot (lásd az alábbi ábrán):

Felhasználók (users) — akiknek csak a SA-WebApp és SA-Frontend szolgáltatásokhoz van hozzáférésük;
Moderátorok (moderators) — akiknek hozzáférésük van mindhárom szolgáltatáshoz.

A jogosultságok koncepciója

Ezeknek a csoportoknak a létrehozásához használja az Auth0 Authorization kiterjesztést, és az Istio segítségével különböző hozzáférési szinteket adjon nekik.

Az Auth0 Authorization telepítése és konfigurálása

Az Auth0 portálon lépjen az Extensions (Extensions) menüpontra, és telepítse Auth0 Authorization. A telepítés után lépjen az Authorization Extension, majd a konfigurációs tenant-ra a jobb felső sarokban található kattintással és a megfelelő menüopció kiválasztásával (Configuration). Aktiválja a csoportokat (Groups) és nyomja meg a szabály közzétételi gombját (Publish rule).

Csoportok létrehozása

Az Authorization Extension-ben lépjen a Csoportok és hozzon létre egy csoportot Moderators. Mivel minden hitelesített felhasználót normál felhasználónak fogunk tekinteni, nincs szükség egy külön csoport létrehozására számukra.

Válassza ki a csoportot, Moderatorsmajd kattintson az Add Members, adja hozzá a fő fiókját. Hagyjon néhány felhasználót csoport nélkül, hogy biztosan megakadályozza számukra a hozzáférést. (Új felhasználók manuálisan létrehozhatók a Auth0 Portal > Felhasználók > Felhasználó létrehozása.)

Adja hozzá a Csoport igénylést a Hozzáférési tokenhez

A felhasználók csoportokba vannak tetoválva, azonban ennek az információnak a hozzáférési tokenekben is tükröződnie kell. Az OpenID Connect megfelelés érdekében, és hogy a szükséges csoportokat vissza tudja adni, a tokennek hozzá kell adnia a testreszabott igényt. Ezt az Auth0 szabályok segítségével valósítják meg.

A szabály létrehozásához lépjen az Auth0 Portálra a Szabályokmajd kattintson az Szabály létrehozása és válassza ki az üres szabályt a sablonok közül.

Másolja be az alábbi kódot, és mentse el új szabályként Csoport igénylés hozzáadása (namespacedGroup.js):

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

Megjegyzés: ez a kód a felhasználóhoz rendelt első csoportot veszi, amely az Authorization Extensionben van definiálva, és hozzáadja a hozzáférési tokenhez mint testreszabott igényt (saját névtér alatt, ahogyan azt az Auth0 megköveteli).

Térjen vissza az oldalra Szabályok és ellenőrizze, hogy két szabály szerepel-e az alábbi sorrendben:

auth0-authorization-extension
Csoport igénylés hozzáadása

A sorrend fontos, mert a csoport mező aszinkron módon kapja meg a szabályt auth0-authorization-extension és aztán a második szabályként adódik hozzá, mint igény. Ennek eredményeként egy ilyen hozzáférési tokent kapunk:

{
 "https://sa.io/group": "Moderátorok",
 "iss": "https://sentiment-analysis.eu.auth0.com/",
 "sub": "google-oauth2|196405271625531691872"
 // [rövidítve a nagyobb áttekinthetőség kedvéért]
}

Most be kell állítania az Envoy proxy-t a felhasználói hozzáférés ellenőrzésére, aminek során a csoportot a tokenben visszakapott igényből fogják kinyerni (https://sa.io/group) a visszaadott hozzáférési tokenben. Ez a következő szakasz témája lesz.

Az Istio engedélyezési konfigurációja

Az engedélyezés működéséhez engedélyezni kell az RBAC-t az Istio számára. Ehhez a következő konfigurációt fogjuk használni:

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"

Magyarázatok:

1 — csak a szolgáltatásokra és névtartományokra vonatkozik, amelyeket az Inclusion mezőben soroltunk fel 2 — itt soroljuk fel a szolgáltatásainkat.;
Alkalmazzuk a konfigurációt a következő parancs segítségével:

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

Most minden szolgáltatás megköveteli a szerepkör alapú hozzáférés-ellenőrzést (Role-Based Access Control). Más szóval, a hozzáférés minden szolgáltatáshoz tilos, és a válasz a következő lesz:

RBAC: hozzáférés megtagadva RBAC: hozzáférés megtagadva. Most már engedélyezzük a hozzáférést a hitelesített felhasználók számára.

Hozzáférési konfiguráció a normál felhasználók számára

Minden felhasználónak hozzáféréssel kell rendelkeznie az SA-Frontend és SA-WebApp szolgáltatásokhoz. Ezt az Istio következő erőforrásaival valósítjuk meg:

ServiceRole — meghatározza a felhasználó jogait;
ServiceRoleBinding — meghatározza, hogy ez a ServiceRole kinek szól.

Normál felhasználók számára hozzáférést engedélyezünk bizonyos szolgáltatásokhoz (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: ["*"]

És a regular-user-binding alkalmazni fogjuk a ServiceRole-t az oldalletöltők minden látogatójára (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"

Jelenti-e az „összes felhasználó”, hogy a nem hitelesített felhasználók is hozzáférést kapnak az SA WebApp-hoz? Nem, a politika ellenőrzi a JWT-token érvényességét.

Alkalmazzuk a konfigurációkat:

$ 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

Hozzáférési konfiguráció a moderátorok számára

Moderátorok számára szeretnénk hozzáférést engedélyezni minden szolgáltatáshoz (mod-service-role.yaml):

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

De ilyen jogokat csak azoknak a felhasználóknak szeretnénk adni, akiknek a hozzáférési tokenjében szerepel a claim https://sa.io/group az értékkel 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"

Alkalmazzuk a konfigurációkat:

$ 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

Az envoy-ekben történő cache-elés miatt a jogosultsági szabályok érvénybe lépéséhez néhány perc szükséges. Ezután biztos lehet benne, hogy a felhasználóknak és moderátoroknak eltérő szintű hozzáférésük van.

Összegzés erre a részre

Na jó, komolyan: láttál valaha ennél egyszerűbb, igénytelenebb, skálázhatóbb és biztonságosabb megoldást az azonosításra és jogosultságkezelésre?

Mindössze három Istio erőforrásra (RbacConfig, ServiceRole és ServiceRoleBinding) volt szükség ahhoz, hogy a végfelhasználók szolgáltatásokhoz való hozzáférésének hitelesítését és engedélyezését finomítani tudjuk.

Ezen felül átvittük ezen problémák kezelését az envoy szolgáltatásainkból, elérve:

a potenciális biztonsági problémákat és hibákat tartalmazó kód mennyiségének csökkentését;
azoknak a buta helyzeteknek a csökkentését, ahol egy endpoint kívülről elérhetővé vált, és erről nem értesítettek;
a szükségesség eltüntetését, hogy minden szolgáltatást frissíteni kelljen, amikor új szerepre vagy jogosultságra kerül sor;
abban, hogy az új szolgáltatások egyszerűek, biztonságosak és gyorsak maradjanak.

Következtetés

Az Istio lehetővé teszi a csapatok számára, hogy erőforrásaikat a vállalkozás szempontjából fontos feladatokra összpontosítsák, anélkül hogy terhet rónának a szolgáltatásokra, visszaállítva őket a 'mikro' státuszra.

A cikk (három részben) alapvető ismereteket és kész gyakorlati útmutatót nyújtott a Istio valós projektekben történő alkalmazásához.