Naspäť k mikroslužbám spolu s Istio. Časť 3

Pozn. prekl.: Prvá časť Tento cyklus byl věnován seznámení s možnostmi Istio a jejich praktickým předvedením. druhá — jemně konfigurovatelnému směrování a řízení síťového provozu. Nyní se budeme bavit o bezpečnosti: pro předvedení souvisejících základních funkcí autor používá identity službu Auth0, avšak obdobně mohou být nastaveny i jiní poskytovatelé.

Nastavili jsme Kubernetes cluster, ve kterém jsme nasadili Istio a příklad mikroservisní aplikace Sentiment Analysis, — tak byly demonstrovány možnosti Istio.

Díky Istio se nám podařilo udržet malé rozměry služeb, protože nepotřebují implementaci takových „úrovní“, jako jsou opakované pokusy o připojení (Retries), časové limity (Timeouts), automatické jističe (Circuit Breakers), sledování (Tracing), monitorování (Monitoring). Kromě toho jsme použili techniky pokročilého testování a nasazení: A/B testování, zrcadlení a kanárková vydání.

V novém materiálu se podíváme na konečné úrovně na cestě k business value: autentizaci a autorizaci — a v Istio je to opravdový požitek!

Autentizace a autorizace v Istio

Nikdy bych nevěřil, že mě autentizace a autorizace inspirují. Co může Istio z technologického hlediska nabídnout, aby tyto témata učinilo zajímavými a dokonce aby vás inspirovalo?

Odpověď je jednoduchá: Istio přenáší odpovědnost za tyto možnosti z vašich služeb na proxy Envoy. Když požadavky dosáhnou služeb, jsou již autentizovány a autorizovány, takže vám zbývá jen psát kód užitečný pro podnikání.

Zní to dobře? Pojďme se tedy podívat dovnitř!

Autentizace s Auth0

Jako server pro správu identity a přístupu budeme používat Auth0, který má zkušební verzi, je intuitivně použitelný a jednoduše se mi líbí. Nicméně, ty samé principy lze aplikovat i na jakoukoli jinou implementaci OpenID Connect: KeyCloak, IdentityServer a mnoho dalších.

Nejprve se přihlaste na Auth0 Portal se svým účtem, vytvořte tenant (tenant — „nájemce“, logická jednotka izolace, podrobněji viz) dokumenácie — pozn. prekl.) a přejděte do Applications > Default App, vyberte Doména, jak je znázorněno na níže uvedeném snímku obrazovky:

Zadejte tuto doménu do souboru resource-manifests/istio/security/auth-policy.yaml (zdroje):

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

S takýmto zdrojom Pilot (jedna z troch základných komponentov Control Plane v Istio — pozn. prekl.) nastavuje Envoy na autentifikáciu požiadaviek predtým, ako ich presmeruje na služby: sa-web-app a sa-feedback. Zároveň konfigurácia nie je aplikovaná na Envoye služby sa-frontend, čo nám umožňuje neautentifikovať frontend. Na aplikovanie politiky (Policy) vykonajte príkaz:

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

Vráťte sa na stránku a vykonajte požiadavku — uvidíte, že skončí so statusom 401 Unauthorized. Teraz presmerujeme užívateľov frontendu na autentifikáciu pomocou Auth0.

Autentifikácia požiadaviek s Auth0

Aby ste autentifikovali požiadavky koncového používateľa, musíte vytvoriť API v Auth0, ktoré bude predstavovať autentifikované služby (reviews, details a ratings). Na vytvorenie API prejdite do Auth0 Portal > APIs > Create API a vyplňte formulár:

Dôležitou informáciou je Identifier, ktorý neskôr použijeme v skripte. Zapíšte si ho nasledovne:

• Audience: {YOUR_AUDIENCE}

Ostatné potrebné detaily sú umiestnené na Auth0 Portal v sekcii Applications — vyberte Test Application (vytvára sa automaticky spolu s API).

Tu zapíšeme:

• Doména: {YOUR_DOMAIN}
• Client Id: {YOUR_CLIENT_ID}

Posuňte sa k Test Application textovému poľu Allowed Callback URLs (povolené URL pre callback), v ktorom uvedieme URL, na ktoré by sa mala odoslať výzva po dokončení autentifikácie. V našom prípade je to:

http://{EXTERNAL_IP}/callback

A pre Allowed Logout URLs (povolené URL na odhlásenie) pridáme:

http://{EXTERNAL_IP}/logout

Prejdime na frontend.

Aktualizácia frontendu

Prepnite na vetvu auth0 repozitória [istio-mastery]. V tejto vetve bol kód frontendu zmenený tak, aby presmerovával používateľov do Auth0 na autentifikáciu a používal JWT token v požiadavkách na ostatné služby. Posledné je implementované nasledovne (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));
}

Aby sme prešli na použitie údajov tenant'a v Auth0, otvorte sa-frontend/src/services/Auth.js a nahraďte v ňom hodnoty, ktoré sme zapísali vyššie (Auth.js):

const Config = {
    clientID: '{YOUR_CLIENT_ID}',
    domain:'{YOUR_DOMAIN}',
    audience: '{YOUR_AUDIENCE}',
    ingressIP: '{EXTERNAL_IP}' // Používa sa na presmerovanie po autentifikácii
}

Aplikácia je pripravená. Uveďte svoje Docker ID v príkazoch nižšie pri zostavovaní a nasadzovaní vykonaných zmien:

$ 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

Vyskúšajte aplikáciu! Budete presmerovaný na Auth0, kde sa musíte prihlásiť (alebo zaregistrovať), po čom vás pošlú späť na stránku, z ktorej budú prebiehať už autentifikované požiadavky. Ak sa pokúsite o príkazy uvedené v predchádzajúcich častiach článku s curl, dostanete kód 401 Status Code, ktorý signalizuje, že požiadavka nie je autorizovaná.

Urobíme ďalší krok — autorizujeme požiadavky.

Autorizácia s Auth0

Autentifikácia nám umožňuje pochopiť, kým je používateľ, ale na to, aby sme zistili, k čomu má prístup, je potrebná autorizácia. Istio ponúka nástroje aj na to.

Ako príklad vytvoríme dve skupiny používateľov (pozri schému nižšie):

• Používatelia (users) — s prístupom iba k službám SA-WebApp a SA-Frontend;
• Moderátori (moderators) — s prístupom ku všetkým trom službám.

Koncepcia autorizácie

Na vytvorenie týchto skupín využijeme rozšírenie Auth0 Authorization a pomocou Istio im poskytneme rôzne úrovne prístupu.

Inštalácia a konfigurácia Auth0 Authorization

Na portáli Auth0 prejdite k rozšíreniam (Extensions) a nainštalujte Auth0 Authorization. Po inštalácii prejdite k Authorization Extension, a tam — k konfigurácii tenant’a kliknutím vpravo hore a výberom príslušnej možnosti menu (Configuration). Aktivujte skupiny (Groups) a kliknite na tlačidlo publikovania pravidla (Publish rule).

Vytvorenie skupín

V Authorization Extension prejdite do Skupiny a vytvorte skupinu Moderators. Pretože všetkých autentifikovaných používateľov budeme považovať za bežných, potrebu vytvoriť pre nich ďalšiu skupinu nemáme.

Vyberte skupinu Moderators, kliknite na Add Members, pridajte svoj hlavný účet. Nechajte niektorých používateľov bez akejkoľvek skupiny, aby ste sa uistili, že ich prístup je zakázaný. (Nových používateľov môžete vytvoriť ručne cez Auth0 Portal > Users > Create User.)

Pridajte Group Claim do Access Token

Používatelia boli pridaní do skupín, avšak tieto informácie musia byť odrazené aj v prístupových tokenoch. Aby sme vyhoveli OpenID Connect a zároveň vrátili požadované skupiny, token bude potrebovať pridávať svoj vlastný nárok. Realizuje sa cez pravidlá Auth0.

Pre vytvorenie pravidla prejdite na portál Auth0 na Pravidlá, kliknite na Vytvoriť pravidlo a vyberte prázdne pravidlo zo šablón.

Skopírujte kód nižšie a uložte ho ako nové pravidlo Pridať skupinový nárok (namespacedGroup.js):

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

Poznámka: tento kód berie prvú skupinu používateľa definovanú v Authorization Extension a pridáva ju do access-tokenu ako vlastný nárok (pod vlastným menným priestorom, ako to vyžaduje Auth0).

Vráťte sa na stránku Pravidlá a skontrolujte, že máte dve pravidlá, zapísané v nasledujúcom poradí:

• auth0-authorization-extension
• Pridať skupinový nárok

Poradie je dôležité, pretože pole skupiny asynchrónne získava pravidlo auth0-authorization-extension a následne sa pridáva ako nárok druhým pravidlom. V dôsledku toho je access-token nasledujúci:

{
 "https://sa.io/group": "Moderators",
 "iss": "https://sentiment-analysis.eu.auth0.com/",
 "sub": "google-oauth2|196405271625531691872"
 // [skrátené pre prehľadnosť]
}

Teraz je potrebné nastaviť proxy Envoy na kontrolu prístupu používateľov, na čo bude skupina vytiahnutá z nároku (https://sa.io/group) v vrátenom access-tokenu. Toto je téma pre ďalšiu časť článku.

Konfigurácia autorizácie v Istio

Aby autorizácia fungovala, je potrebné povoliť RBAC pre Istio. Na to využijeme nasledujúcu konfiguráciu:

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" 

Vysvetlenia:

• 1 — zapneme RBAC len pre služby a namespace uvedené v poli Inclusion;
• 2 — uvádzame zoznam našich služieb.

Aplikujeme konfiguráciu touto príkazom:

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

Teraz všetky služby vyžadujú spravovanie prístupu na základe rolí (Role-Based Access Control). Inými slovami, prístup ku všetkým službám je zakázaný a povedie k odpovedi RBAC: prístup odmietnutý. Teraz povolíme prístup autorizovaným používateľom.

Konfigurácia prístupu pre bežných používateľov

Všetci používatelia by mali mať prístup k službám SA-Frontend a SA-WebApp. Realizuje sa pomocou nasledujúcich zdrojov Istio:

• ServiceRole — určuje práva, ktoré má používateľ;
• ServiceRoleBinding — určuje, ku komu sa táto ServiceRole vzťahuje.

Pre bežných používateľov povolíme prístup k určitým službám (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: ["*"]

A cez regular-user-binding aplikujeme ServiceRole na všetkých návštevníkov stránky (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"

Znamená „všetci používatelia“, že aj neautentifikovaní používatelia získajú prístup k SA WebApp? Nie, politika overí platnosť JWT tokenu.

Aplikujeme konfigurácie:

$ 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

Konfigurácia prístupu pre moderátorov

Pre moderátorov chceme povoliť prístup ku všetkým službám (mod-service-role.yaml):

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

Ale chceme tieto práva len pre tých používateľov, ktorých access token obsahuje claim https://sa.io/group s hodnotou 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" 

Aplikujeme konfigurácie:

$ 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

Z dôvodu caching v envoy-och môže trvať niekoľko minút, než sa pravidlá autorizácie prejavia. Po tom si budete môcť overiť, že užívatelia a moderátori majú rôzne úrovne prístupu.

Záver k tejto časti

No vážne: kedy ste videli jednoduchší, bezproblémový, škálovateľný a bezpečný prístup k autentifikácii a autorizácii?

Na dosiahnutie jemného riadenia autentifikácie a autorizácie prístupu koncových užívateľov k službám stačili tri zdroje Istio (RbacConfig, ServiceRole a ServiceRoleBinding).

Navyše sme sa postarali o tieto problémy z našich služieb do envoy-ov, čím sme dosiahli:

• zniženie množstva typového kódu, kde môžu vzniknúť bezpečnostné problémy a chyby;
• zniženie počtu hlúpych situácií, kedy bol jeden endpoint dostupný navonok a zabudol o tom informovať;
• odstránenie potreby aktualizovať všetky služby pri každom pridaní novej úlohy alebo oprávnenia;
• pričom nové služby zostávajú jednoduché, bezpečné a rýchle.

Záver

Istio umožňuje tímom sústrediť svoje zdroje na dôležité obchodné úlohy bez zvyšovania nákladov na služby, vracajúc ich späť do stavu "mikro".

Článok (v troch častiach) poskytol základné znalosti a pripravený praktický návod na začatie práce s Istio v reálnych projektoch.

P.S. od prekladateľa

Prečítajte si tiež na našom blogu:

• „Späť k mikroslužbám s Istio“: časť 1 (zoznámenie sa s hlavnými funkciami), časť 2 (smerovanie, správa prevádzky);
• «Conduit — ľahký service mesh pre Kubernetes»;
• «Čo je service mesh a prečo ho potrebujem [pre cloudovú aplikáciu s mikroservisami]?».

Zdroj: habr.com