Vissza a mikroszolgáltatásokhoz az Istio-val. 3. rész

Jegyzet. ford.: Első rész ennek a sorozatnak az volt a célja, hogy megismerjük az Istio képességeit és bemutatjuk azokat a gyakorlatban, második — finoman hangolt útválasztás és hálózati forgalomkezelés. Most a biztonságról lesz szó: a hozzá kapcsolódó alapvető funkciók bemutatására a szerző az Auth0 identitásszolgáltatást használja, de más szolgáltatók is hasonló módon konfigurálhatók.

Létrehoztunk egy Kubernetes-fürtöt, amelyben az Istio-t és egy példakénti mikroszolgáltatás-alkalmazást, a Sentiment Analysis-t telepítettük az Istio képességeinek bemutatására.

Az Istio segítségével szolgáltatásainkat kicsiben tudtuk tartani, mert nincs szükségük olyan rétegek megvalósítására, mint az Újrapróbálkozások, Időtúllépések, Árammegszakítók, Nyomkövetés, Figyelés. Ezenkívül fejlett tesztelési és telepítési technikákat alkalmaztunk: A/B tesztelést, tükrözést és kanári kiterjesztéseket.

Az új anyagban az üzleti érték felé vezető út utolsó rétegeivel fogunk foglalkozni: a hitelesítéssel és az engedélyezéssel – az Istióban pedig ez egy igazi öröm!

Hitelesítés és engedélyezés az Istióban

Soha nem hittem volna, hogy a hitelesítés és az engedélyezés inspirál. Mit tud nyújtani az Istio technológiai szempontból, hogy ezek a témák szórakoztatóak és még inkább inspirálóak legyenek az Ön számára?

A válasz egyszerű: az Istio ezekért a képességekért a felelősséget az Ön szolgáltatásairól az Envoy proxyra hárítja. Mire a kérések eljutnak a szolgáltatásokhoz, már hitelesítették és engedélyezve vannak, így nem kell mást tenni, mint megírni az üzletileg hasznos kódot.

Jól hangzik? Nézzünk befelé!

Hitelesítés az Auth0 segítségével

Az identitás- és hozzáférés-kezelés szervereként az Auth0-t fogjuk használni, amelynek próbaverziója van, használata intuitív, és egyszerűen tetszik. Ugyanezek az elvek azonban bármely másra is alkalmazhatók OpenID Connect implementációk: KeyCloak, IdentityServer és még sokan mások.

Először is menjen a Auth0 portál fiókjával hozzon létre egy bérlőt (bérlő - „bérlő”, logikai elkülönítési egység, további részletekért lásd dokumentáció - kb. fordítás.) és menj oda Alkalmazások > Alapértelmezett alkalmazásválasztva Domén, ahogy az alábbi képernyőképen is látható:

Adja meg ezt a tartományt a fájlban resource-manifests/istio/security/auth-policy.yaml (forrás):

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

Ilyen erőforrással, Pilot (az Istio három alapvető Vezérlősík komponensének egyike - kb. fordítás) beállítja az Envoy-t, hogy hitelesítse a kéréseket, mielőtt továbbítaná azokat a szolgáltatásoknak: sa-web-app и sa-feedback. Ugyanakkor a konfiguráció nem vonatkozik a szolgáltatási küldöttekre sa-frontend, ami lehetővé teszi számunkra, hogy a frontendet hitelesítetlenül hagyjuk. A házirend alkalmazásához futtassa a parancsot:

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

Térjen vissza az oldalra, és tegyen egy kérést - látni fogja, hogy az állapottal végződik 401 jogosulatlan. Most irányítsuk át a frontend felhasználókat az Auth0 segítségével történő hitelesítésre.

Kérések hitelesítése az Auth0 segítségével

A végfelhasználói kérések hitelesítéséhez létre kell hoznia egy API-t az Auth0-ban, amely képviseli a hitelesített szolgáltatásokat (vélemények, részletek és értékelések). API létrehozásához nyissa meg a következőt: Auth0 portál > API-k > API létrehozása és töltse ki az űrlapot:

Itt a fontos információ Azonosító, amelyet később a szkriptben fogunk használni. Írjuk le így:

• Közönség: {YOUR_AUDIENCE}

A további részletek, amelyekre szükségünk van, az Auth0 portálon találhatók Alkalmazási területek - válassza ki Tesztalkalmazás (automatikusan létrejön az API-val együtt).

Ide írjuk:

• Domén: {YOUR_DOMAIN}
• Ügyfélazonosító: {YOUR_CLIENT_ID}

Görgessen ide Tesztalkalmazás szövegmezőbe Engedélyezett visszahívási URL-ek (feloldott URL-ek a visszahíváshoz), amelyben megadjuk azt az URL-t, ahová a hívást el kell küldeni a hitelesítés befejezése után. A mi esetünkben ez:

http://{EXTERNAL_IP}/callback

És a Engedélyezett kijelentkezési URL-ek (engedélyezett URL-ek a kijelentkezéshez) add hozzá:

http://{EXTERNAL_IP}/logout

Térjünk át a frontendre.

Frontend frissítés

Váltás ágra auth0 adattár [istio-mastery]. Ebben az ágban a frontend kód úgy módosul, hogy a felhasználókat az Auth0-ra irányítsa át hitelesítés céljából, és használja a JWT-jogkivonatot más szolgáltatásokra irányuló kérésekben. Ez utóbbi a következőképpen valósul 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));
}

Ha módosítani szeretné a kezelőfelületet a bérlői adatok használatára az Auth0-ban, nyissa meg sa-frontend/src/services/Auth.js és cserélje ki benne a fent írt értékeket (Auth.js):

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

Az alkalmazás készen áll. Adja meg Docker azonosítóját az alábbi parancsokban a módosítások összeállításakor és üzembe helyezésekor:

$ 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áld ki az alkalmazást! Átirányítunk az Auth0 oldalra, ahol be kell jelentkezned (vagy regisztrálnod kell), majd visszakerülsz arra az oldalra, ahonnan a már hitelesített kéréseket intézik. Ha a cikk első részeiben említett parancsokat curl-lel próbálod ki, megkapod a kódot 401 Állapotkód, jelezve, hogy a kérés nem engedélyezett.

Tegyük meg a következő lépést – engedélyezzük a kéréseket.

Engedélyezés Auth0-val

A hitelesítés lehetővé teszi számunkra, hogy megértsük, ki a felhasználó, de engedély szükséges ahhoz, hogy tudjuk, mihez fér hozzá. Az Istio ehhez is kínál eszközöket.

Példaként hozzunk létre két felhasználói csoportot (lásd az alábbi diagramot):

• Tagok (felhasználók) — csak az SA-WebApp és SA-Frontend szolgáltatásokhoz való hozzáféréssel;
• Moderátorok (moderátorok) – hozzáféréssel mindhárom szolgáltatáshoz.

Engedélyezési koncepció

E csoportok létrehozásához az Auth0 Authorization bővítményt használjuk, és az Istio segítségével biztosítjuk számukra a különböző szintű hozzáférést.

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

Az Auth0 portálon lépjen a bővítményekhez (Extensions) és telepítse Auth0 engedélyezés. A telepítés után lépjen a következőre: Engedélykiterjesztés, és ott - a bérlő konfigurációjához kattintson a jobb felső sarokban, és válassza ki a megfelelő menüpontot (Konfiguráció). Csoportok aktiválása (Csoportok) és kattintson a szabály közzététele gombra (Szabály közzététele).

Csoportok létrehozása

Az Engedélyezés kiterjesztésében lépjen a következőre: Csoportok és hozzon létre egy csoportot A moderátorok. Mivel minden hitelesített felhasználót normál felhasználóként kezelünk, nincs szükség további csoport létrehozására számukra.

Válasszon egy csoportot A moderátorok, Nyomja meg Tagok hozzáadása, adja hozzá fő fiókját. Hagyjon néhány felhasználót csoport nélkül, hogy megtagadja a hozzáférést. (Új felhasználók manuálisan hozhatók létre a következőn keresztül Auth0 portál > Felhasználók > Felhasználó létrehozása.)

Csoportkövetelés hozzáadása a hozzáférési tokenhez

A felhasználók hozzáadva vannak a csoportokhoz, de ennek az információnak a hozzáférési jogkivonatokban is tükröződnie kell. Az OpenID Connect követelményeinek való megfeleléshez és a szükséges csoportok visszaküldéséhez a tokennek hozzá kell adnia a sajátját egyéni követelés. Auth0 szabályokon keresztül valósítva meg.

Szabály létrehozásához nyissa meg az Auth0 Portal to Szabályok, Nyomja meg Szabály létrehozása és válasszon ki egy üres szabályt a sablonok közül.

Másolja ki az alábbi kódot, és mentse el új szabályként Csoportos követelé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 az engedélyezési kiterjesztésben meghatározott első felhasználói csoportot veszi fel, és egyéni jogcímként hozzáadja a hozzáférési jogkivonathoz (a névterében, ahogy azt az Auth0 megköveteli).

Vissza az oldalra Szabályok és ellenőrizze, hogy két szabályt írt-e le a következő sorrendben:

• auth0-authorization-extension
• Csoportos követelés hozzáadása

A sorrend azért fontos, mert a csoport mező aszinkron módon kapja meg a szabályt auth0-authorization-extension és ezt követően a második szabály követelésként adja hozzá. Az eredmény egy ehhez hasonló hozzáférési token:

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

Most be kell állítania az Envoy proxyt, hogy ellenőrizze a felhasználói hozzáférést, amelyhez a csoport le lesz vonva a követelésből (https://sa.io/group) a visszaadott hozzáférési tokenben. Ez a téma a cikk következő részében.

Engedélyezési konfiguráció az Istióban

A működéshez engedélyeznie 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ázat:

• 1 — csak a mezőben felsorolt ​​szolgáltatásokhoz és névterekhez engedélyezze az RBAC-t Inclusion;
• 2 — felsoroljuk szolgáltatásaink listáját.

Alkalmazzuk a konfigurációt a következő paranccsal:

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

Mostantól minden szolgáltatáshoz szerepkör alapú hozzáférés-vezérlés szükséges. Más szavakkal, az összes szolgáltatáshoz való hozzáférés tilos, és válaszhoz vezet RBAC: access denied. Most engedjük meg a hozzáférést a jogosult felhasználóknak.

Hozzáférés konfigurációja 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. A következő Istio-erőforrások felhasználásával valósítva meg:

• ServiceRole — meghatározza a felhasználó jogait;
• ServiceRoleBinding — meghatározza, hogy kihez tartozik ez a ServiceRole.

A hétköznapi felhasználók számára hozzáférést biztosítunk 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 keresztül regular-user-binding alkalmazza a ServiceRole-ot az oldal összes 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"

A „minden felhasználó” azt jelenti, hogy a nem hitelesített felhasználók is hozzáférhetnek az SA WebApp-hoz? Nem, a szabályzat 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és a moderátorok konfigurációjához

A moderátorok számára engedélyezni akarjuk az összes szolgáltatáshoz való hozzáférést (mod-service-role.yaml):

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

De csak azoknak a felhasználóknak szeretnénk ilyen jogokat, akiknek a hozzáférési jogkivonata igényt tartalmaz https://sa.io/group jelentéssel 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

A küldöttek gyorsítótárazása miatt néhány percbe telhet, amíg az engedélyezési szabályok életbe lépnek. Ezután biztosíthatja, hogy a felhasználók és a moderátorok különböző szintű hozzáféréssel rendelkezzenek.

Következtetés erről a részről

De komolyan, látott már valaha egyszerűbb, könnyed, méretezhető és biztonságos megközelítést a hitelesítéshez és engedélyezéshez?

Mindössze három Istio-erőforrásra (RbacConfig, ServiceRole és ServiceRoleBinding) volt szükség a hitelesítés és a végfelhasználói szolgáltatásokhoz való hozzáférés engedélyezésének pontos ellenőrzéséhez.

Ezen túlmenően ezeket a kérdéseket is megoldottuk küldöttségünkből, elérve:

• az általános kódok mennyiségének csökkentése, amelyek biztonsági problémákat és hibákat tartalmazhatnak;
• azon hülye helyzetek számának csökkentése, amelyekben egy végpont kívülről hozzáférhetőnek bizonyult, és elfelejtették jelenteni;
• kiküszöböli az összes szolgáltatás frissítésének szükségességét minden új szerepkör vagy jog hozzáadásakor;
• hogy az új szolgáltatások egyszerűek, biztonságosak és gyorsak maradjanak.

Teljesítmény

Az Istio lehetővé teszi a csapatok számára, hogy erőforrásaikat az üzleti szempontból kritikus feladatokra összpontosítsák anélkül, hogy a szolgáltatások többletköltséget okoznának, és visszaállítanák azokat mikrostátuszba.

A cikk (három részben) alapvető ismereteket és kész gyakorlati útmutatást adott az Istio valós projektekben való elkezdéséhez.

PS a fordítótól

Olvassa el blogunkon is:

• "Vissza a mikroszolgáltatásokhoz az Istióval": 1. rész (bevezetés a főbb jellemzőkbe), 2. rész (útválasztás, forgalomirányítás);
• «Csővezeték - könnyű szervizháló a Kubernetes számára";
• «Mi az a szolgáltatásháló, és miért van szükségem rá [mikroszolgáltatásokkal rendelkező felhőalkalmazásokhoz]?".

Forrás: will.com