Zpět k mikroslužbám s Istio. Část 3

Poznámka. přel.: První část tato série byla věnována poznávání schopností Istio a jejich demonstraci v akci, druhý — jemně vyladěné směrování a správa síťového provozu. Nyní budeme hovořit o bezpečnosti: k demonstraci základních funkcí s tím souvisejících autor využívá službu identity Auth0, ale podobně lze nakonfigurovat i další poskytovatele.

Nastavili jsme cluster Kubernetes, ve kterém jsme nasadili Istio a ukázkovou aplikaci mikroslužeb Sentiment Analysis, abychom demonstrovali schopnosti Istio.

S Istio jsme byli schopni udržet naše služby malé, protože nepotřebují implementovat vrstvy, jako jsou opakování, časové limity, jističe, sledování, monitorování. Kromě toho jsme použili pokročilé techniky testování a nasazení: A/B testování, zrcadlení a canary rollouts.

V novém materiálu se budeme zabývat posledními vrstvami na cestě k obchodní hodnotě: autentizací a autorizací – a v Istio je to opravdové potěšení!

Autentizace a autorizace v Istio

Nikdy bych nevěřil, že se nechám inspirovat autentizací a autorizací. Co může Istio nabídnout z technologického hlediska, aby pro vás tato témata byla zábavná a ještě více inspirativní?

Odpověď je jednoduchá: Istio přesouvá odpovědnost za tyto schopnosti z vašich služeb na Envoy proxy. Ve chvíli, kdy se požadavky dostanou ke službám, jsou již ověřeny a autorizovány, takže vše, co musíte udělat, je napsat obchodně užitečný kód.

To zní dobře? Pojďme se podívat dovnitř!

Autentizace pomocí Auth0

Jako server pro správu identit a přístupu použijeme Auth0, který má zkušební verzi, je intuitivní a jednoduše se mi líbí. Stejné principy však lze aplikovat na kteroukoli jinou Implementace OpenID Connect: KeyCloak, IdentityServer a mnoho dalších.

Chcete-li začít, přejděte na stránku Portál Auth0 se svým účtem vytvořte tenanta (nájemce - „nájemce“, logická jednotka izolace, více viz dokumentace - Cca. překlad.) a jít do Aplikace > Výchozí aplikacevýběr Doména, jak je znázorněno na snímku obrazovky níže:

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

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 takovým zdrojem, Pilote (jedna ze tří základních komponent Control Plane v Istio – cca překlad) konfiguruje Envoy tak, aby ověřoval požadavky před jejich předáním službám: sa-web-app и sa-feedback. Zároveň se konfigurace nepoužije na služby Envoys sa-frontend, což nám umožňuje ponechat frontend bez ověření. Chcete-li použít zásady, spusťte příkaz:

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

Vraťte se na stránku a požádejte - uvidíte, že to končí stavem 401 Neautorizováno. Nyní přesměrujeme uživatele frontendu k ověření pomocí Auth0.

Ověřování požadavků pomocí Auth0

Chcete-li ověřit požadavky koncových uživatelů, musíte vytvořit API v Auth0, které bude reprezentovat ověřené služby (recenze, podrobnosti a hodnocení). Chcete-li vytvořit rozhraní API, přejděte na Portál Auth0 > Rozhraní API > Vytvořit rozhraní API a vyplňte formulář:

Zde jsou důležité informace identifikátor, který použijeme později ve skriptu. Zapišme si to takto:

• Publikum: {VAŠE_AUDIENCE}

Zbývající podrobnosti, které potřebujeme, jsou umístěny na portálu Auth0 v sekci Aplikace - vybrat Testovací aplikace (vytvořeno automaticky spolu s API).

Zde budeme psát:

• Doména: {VAŠE_DOMÉNA}
• ID klienta: {YOUR_CLIENT_ID}

Přejděte na Testovací aplikace do textového pole Povolené adresy URL zpětného volání (vyřešené adresy URL pro zpětné volání), ve kterých specifikujeme URL, kam má být volání po dokončení autentizace odesláno. V našem případě je to:

http://{EXTERNAL_IP}/callback

A pro Povolené adresy URL pro odhlášení (povolené adresy URL pro odhlášení) přidat:

http://{EXTERNAL_IP}/logout

Pojďme k frontendu.

Aktualizace frontendu

Přepnout na pobočku auth0 úložiště [istio-mastery]. V této větvi se změní kód frontendu tak, aby přesměroval uživatele na Auth0 pro ověření a použil token JWT v požadavcích na jiné služby. Ten je implementován následovně (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));
}

Chcete-li změnit frontend tak, aby používal data tenanta v Auth0, otevřete sa-frontend/src/services/Auth.js a nahraďte v něm hodnoty, které jsme napsali výše (Auth.js):

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

Aplikace je připravena. Při vytváření a nasazování provedených změn zadejte své Docker ID v příkazech níže:

$ 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

Vyzkoušejte aplikaci! Budete přesměrováni na Auth0, kde se musíte přihlásit (nebo zaregistrovat), načež budete přesměrováni zpět na stránku, ze které budou již ověřené požadavky. Pokud vyzkoušíte příkazy uvedené v prvních částech článku s curl, získáte kód 401 Stavový kód, což signalizuje, že požadavek není autorizován.

Udělejme další krok – autorizujte žádosti.

Autorizace s Auth0

Autentizace nám umožňuje pochopit, kdo je uživatel, ale abychom věděli, k čemu mají přístup, je nutná autorizace. Istio k tomu nabízí nástroje.

Jako příklad vytvoříme dvě skupiny uživatelů (viz schéma níže):

• Členové (uživatelé) — s přístupem pouze ke službám SA-WebApp a SA-Frontend;
• Moderátoři (moderátoři) — s přístupem ke všem třem službám.

Autorizační koncept

K vytvoření těchto skupin použijeme rozšíření Auth0 Authorization a pomocí Istio jim poskytneme různé úrovně přístupu.

Instalace a konfigurace autorizace Auth0

Na portálu Auth0 přejděte na rozšíření (Rozšíření) a nainstalujte Autorizace Auth0. Po instalaci přejděte na Rozšíření autorizacea tam - do konfigurace tenanta kliknutím vpravo nahoře a výběrem příslušné možnosti nabídky (Konfigurace). Aktivujte skupiny (Skupiny) a klikněte na tlačítko publikovat pravidlo (Pravidlo publikování).

Vytvořte skupiny

V Rozšíření autorizace přejděte na Skupiny a vytvořit skupinu Moderátoři. Vzhledem k tomu, že se všemi ověřenými uživateli budeme zacházet jako s běžnými uživateli, není třeba pro ně vytvářet další skupinu.

Vyberte skupinu Moderátoři, Lis Přidat členy, přidejte svůj hlavní účet. Ponechte některé uživatele bez jakékoli skupiny, abyste se ujistili, že jim bude odepřen přístup. (Nové uživatele lze vytvořit ručně pomocí Portál Auth0 > Uživatelé > Vytvořit uživatele.)

Přidejte nárok skupiny k přístupovému tokenu

Uživatelé byli přidáni do skupin, ale tyto informace se musí promítnout i do přístupových tokenů. Abychom vyhověli OpenID Connect a zároveň vrátili skupiny, které potřebujeme, bude muset token přidat vlastní vlastní reklamace. Implementováno prostřednictvím pravidel Auth0.

Chcete-li vytvořit pravidlo, přejděte na portál Auth0 pravidla, Lis Vytvoření pravidla a vyberte ze šablon prázdné pravidlo.

Zkopírujte níže uvedený kód a uložte jej jako nové pravidlo Přidat 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 převezme první skupinu uživatelů definovanou v rozšíření autorizace a přidá ji k přístupovému tokenu jako vlastní deklaraci (pod jejím jmenným prostorem, jak vyžaduje Auth0).

Návrat na stránku pravidla a zkontrolujte, zda máte napsaná dvě pravidla v následujícím pořadí:

• auth0-authorization-extension
• Přidat skupinový nárok

Pořadí je důležité, protože pole skupiny přijímá pravidlo asynchronně auth0-authorization-extension a poté je přidán jako nárok podle druhého pravidla. Výsledkem je přístupový token takto:

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

Nyní musíte nakonfigurovat proxy Envoy pro kontrolu uživatelského přístupu, pro který bude skupina vytažena z nároku (https://sa.io/group) ve vráceném přístupovém tokenu. Toto je téma pro další část článku.

Konfigurace autorizace v Istio

Aby autorizace fungovala, musíte povolit RBAC pro Istio. K tomu použijeme následující konfiguraci:

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" 

Vysvětlení:

• 1 — povolit RBAC pouze pro služby a jmenné prostory uvedené v poli Inclusion;
• 2 — uvádíme seznam našich služeb.

Aplikujme konfiguraci pomocí následujícího příkazu:

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

Všechny služby nyní vyžadují Role-Based Access Control. Jinými slovy, přístup ke všem službám je zakázán a bude mít za následek odpověď RBAC: access denied. Nyní povolme přístup oprávněným uživatelům.

Konfigurace přístupu pro běžné uživatele

Všichni uživatelé musí mít přístup ke službám SA-Frontend a SA-WebApp. Implementováno pomocí následujících zdrojů Istio:

• Servisní role — určuje práva, která má uživatel;
• ServiceRoleBinding — určuje, komu tato servisní role patří.

Běžným uživatelům umožníme přístup k určitým službám (servisní role.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 skrz regular-user-binding použít ServiceRole na všechny návštěvníky 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šichni uživatelé“, že k SA WebApp budou mít přístup také neověření uživatelé? Ne, zásady zkontrolují platnost tokenu JWT.

Aplikujme konfigurace:

$ 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

Konfigurace přístupu pro moderátory

Pro moderátory chceme umožnit přístup ke všem 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 taková práva chceme pouze pro ty uživatele, jejichž přístupový 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" 

Aplikujme konfigurace:

$ 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

Kvůli ukládání do mezipaměti v envoys může trvat několik minut, než pravidla autorizace vstoupí v platnost. Poté můžete zajistit, aby uživatelé a moderátoři měli různé úrovně přístupu.

Závěr k této části

Ale vážně, viděli jste někdy jednodušší, snadnější, škálovatelný a bezpečný přístup k ověřování a autorizaci?

Pouze tři zdroje Istio (RbacConfig, ServiceRole a ServiceRoleBinding) byly zapotřebí k dosažení jemné kontroly nad ověřováním a autorizací přístupu koncových uživatelů ke službám.

Kromě toho jsme se o tyto záležitosti postarali z našich služeb vyslanců a dosáhli jsme:

• snížení množství generického kódu, který může obsahovat bezpečnostní problémy a chyby;
• snížení počtu hloupých situací, kdy se jeden koncový bod ukázal být přístupný zvenčí a zapomněl ho nahlásit;
• odstranění potřeby aktualizovat všechny služby pokaždé, když je přidána nová role nebo právo;
• že nové služby zůstávají jednoduché, bezpečné a rychlé.

Výkon

Istio umožňuje týmům soustředit své zdroje na kritické obchodní úkoly, aniž by přidávaly režii na služby, a vrátily je do mikro stavu.

Článek (ve třech částech) poskytl základní znalosti a hotové praktické návody, jak začít s Istio v reálných projektech.

PS od překladatele

Přečtěte si také na našem blogu:

• "Zpět na mikroslužby s Istio": část 1 (úvod do hlavních funkcí), část 2 (trasování, řízení dopravy);
• «Conduit – lehká servisní síť pro Kubernetes";
• «Co je to síť služeb a proč ji potřebuji [pro cloudovou aplikaci s mikroslužbami]?".

Zdroj: www.habr.com