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):
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):
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:
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):
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:
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:
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):
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
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):
$ 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.