Назад на микросервисите со Istio. Дел 3

Забелешка. превод.: Во првиот дел оваа серија беше посветена на запознавање со можностите на Истио и нивно демонстрирање на дело, Вториот — фино подесено рутирање и управување со мрежниот сообраќај. Сега ќе зборуваме за безбедноста: за да ги демонстрира основните функции поврзани со него, авторот ја користи услугата за идентитет Auth0, но другите провајдери може да се конфигурираат на сличен начин.

Поставивме кластер Kubernetes во кој распоредивме Istio и пример за микросервисна апликација, Sentiment Analysis, за да ги демонстрираме способностите на Istio.

Со Istio, можевме да ги задржиме нашите услуги мали бидејќи тие не треба да имплементираат слоеви како што се обиди, тајмути, прекинувачи на кола, следење, следење. Дополнително, користевме напредни техники за тестирање и распоредување: A/B тестирање, пресликување и пуштање канари.

Во новиот материјал ќе се занимаваме со последните слоеви на патот кон деловната вредност: автентикација и овластување - а во Истио тоа е вистинско задоволство!

Автентикација и овластување во Истио

Никогаш не би поверувал дека ќе бидам инспириран од автентикација и овластување. Што може да понуди Istio од технолошка перспектива за да ги направи овие теми забавни и, уште повеќе, инспиративни за вас?

Одговорот е едноставен: Istio ја префрла одговорноста за овие способности од вашите услуги на полномошникот Енвој. До моментот кога барањата стигнат до услугите, тие веќе се автентицирани и овластени, па се што треба да направите е да напишете код кој е корисен за бизнисот.

Звучи добро? Ајде да погледнеме внатре!

Автентикација со Auth0

Како сервер за управување со идентитет и пристап, ќе користиме Auth0, кој има пробна верзија, е интуитивен за користење и едноставно ми се допаѓа. Сепак, истите принципи може да се применат и на кој било друг Имплементации на OpenID Connect: KeyCloak, IdentityServer и многу други.

За да започнете, одете на Auth0 портал со вашата сметка, креирајте закупец (закупец - „закупец“, логичка единица за изолација, за повеќе детали видете документација - прибл. превод.) и оди на Апликации > Стандардна апликацијаизбор Домен, како што е прикажано на екранот подолу:

Наведете го овој домен во датотеката resource-manifests/istio/security/auth-policy.yaml (извор):

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

Со таков ресурс, Пилот (една од трите основни компоненти на контролната рамнина во Истио - прибл. превод.) го конфигурира Envoy да ги автентицира барањата пред да ги проследи до услугите: sa-web-app и sa-feedback. Во исто време, конфигурацијата не се применува на сервисните Емисии sa-frontend, овозможувајќи ни да го оставиме предниот дел неавтентициран. За да ја примените политиката, извршете ја командата:

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

Вратете се на страницата и направете барање - ќе видите дека завршува со статусот 401 Неовластено. Сега ајде да ги пренасочиме корисниците на предниот дел да се автентицираат со Auth0.

Автентикација на барања со Auth0

За да ги потврдите барањата на крајните корисници, треба да креирате API во Auth0 што ќе ги претставува автентицираните услуги (прегледи, детали и оценки). За да креирате API, одете на Auth0 Portal > APIs > Create API и пополнете го формуларот:

Важните информации овде се идентификатор, што ќе го користиме подоцна во сценариото. Ајде да го запишеме вака:

• Публика: {YOUR_AUDIENCE}

Останатите детали што ни се потребни се наоѓаат на порталот Auth0 во делот апликации — изберете Тест апликација (создаден автоматски заедно со API).

Тука ќе напишеме:

• Домен: {YOUR_DOMAIN}
• ИД на клиентот: {YOUR_CLIENT_ID}

Скролувајте до Тест апликација во полето за текст Дозволени URL-адреси за повратен повик (решени URL-адреси за повратен повик), во кои ја одредуваме URL-то каде што треба да се испрати повикот по завршувањето на автентикацијата. Во нашиот случај тоа е:

http://{EXTERNAL_IP}/callback

И за Дозволени URL-адреси за одјавување (дозволени URL-адреси за одјавување) додадете:

http://{EXTERNAL_IP}/logout

Ајде да продолжиме на предниот дел.

Ажурирање на предниот дел

Префрлете се на гранка auth0 складиште [istio-mastery]. Во оваа гранка, кодот на предниот дел се менува за да ги пренасочи корисниците на Auth0 за автентикација и да го користи токенот JWT во барањата до други услуги. Последново се спроведува на следниов начин (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));
}

За да го промените предниот дел да користи податоци за закупецот во Auth0, отворете sa-frontend/src/services/Auth.js и заменете ги во него вредностите што ги напишавме погоре (Auth.js):

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

Апликацијата е подготвена. Наведете го вашиот Docker ID во командите подолу при градење и имплементирање на направените промени:

$ 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

Пробајте ја апликацијата! Ќе бидете пренасочени на Auth0, каде што треба да се најавите (или да се регистрирате), по што ќе бидете вратени на страницата од која ќе бидат направени веќе автентицирани барања. Ако ги пробате командите споменати во првите делови од статијата со curl, ќе го добиете кодот 401 Статус код, сигнализирајќи дека барањето не е овластено.

Ајде да го направиме следниот чекор - да овластиме барања.

Овластување со Auth0

Автентикацијата ни овозможува да разбереме кој е корисник, но потребна е овластување за да се знае до што има пристап. Istio нуди алатки и за ова.

Како пример, ајде да создадеме две кориснички групи (видете го дијаграмот подолу):

• Членови (корисници) — со пристап само до услугите SA-WebApp и SA-Frontend;
• Модератори (модератори) — со пристап до сите три услуги.

Концепт за овластување

За да ги создадеме овие групи, ќе ја користиме екстензијата за авторизација Auth0 и ќе користиме Istio за да им обезбедиме различни нивоа на пристап.

Инсталација и конфигурација на овластување Auth0

Во порталот Auth0, одете до екстензии (Екстензии) и инсталирај Auth0 Овластување. По инсталацијата, одете на Продолжување на овластувањето, и таму - до конфигурацијата на закупецот со кликнување на горниот десен агол и избирање на соодветната опција од менито (Конфигурација). Активирајте групи (Групи) и кликнете на копчето за објавување правило (Објави правило).

Креирајте групи

Во Продолжението за овластување одете на групи и креирајте група Модератори. Бидејќи сите автентицирани корисници ќе ги третираме како редовни корисници, нема потреба да создаваме дополнителна група за нив.

Изберете група Модератори, Притиснете Додадете членови, додадете ја вашата главна сметка. Оставете некои корисници без група за да бидете сигурни дека им е забранет пристапот. (Нови корисници може да се креираат рачно преку Портал Auth0 > Корисници > Креирај корисник.)

Додајте групно барање во токен за пристап

Корисниците се додадени во групите, но оваа информација мора да се рефлектира и во токените за пристап. За да се усогласи со OpenID Connect и во исто време да ги вратиме групите што ни се потребни, токенот ќе треба да додаде свој прилагодено барање. Имплементиран преку правилата Auth0.

За да креирате правило, одете на Auth0 Portal to Правила, Притиснете Создадете правило и изберете празно правило од шаблоните.

Копирајте го кодот подолу и зачувајте го како ново правило Додадете групен приговор (namespacedGroup.js):

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

Имајте на ум: Овој код ја зема првата корисничка група дефинирана во Наставката за авторизација и ја додава во токенот за пристап како приспособено барање (под неговиот именски простор, како што бара Auth0).

Врати се на страницата Правила и проверете дали имате две правила напишани по следниот редослед:

• авторизација0-овластување-продолжување
• Додадете групен приговор

Редоследот е важен бидејќи групното поле го прима правилото асинхроно авторизација0-овластување-продолжување а после тоа се додава како побарување со второто правило. Резултатот е токен за пристап како овој:

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

Сега треба да го конфигурирате проксито Envoy за да го провери пристапот на корисникот, за што групата ќе биде повлечена од барањето (https://sa.io/group) во вратениот токен за пристап. Ова е темата за следниот дел од статијата.

Конфигурација на авторизација во Истио

За да функционира овластувањето, мора да овозможите RBAC за Istio. За да го направите ова, ќе ја користиме следнава конфигурација:

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" 

Објаснување:

• 1 — овозможете RBAC само за услугите и имињата наведени во полето Inclusion;
• 2 — наведуваме список на нашите услуги.

Ајде да ја примениме конфигурацијата со следнава команда:

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

Сите услуги сега бараат контрола на пристап заснована на улоги. Со други зборови, пристапот до сите услуги е забранет и ќе резултира со одговор RBAC: access denied. Сега да дозволиме пристап до овластени корисници.

Конфигурација за пристап за редовни корисници

Сите корисници мора да имаат пристап до услугите SA-Frontend и SA-WebApp. Имплементирано со користење на следните ресурси на Istio:

• Услужна улога — ги одредува правата што ги има корисникот;
• ServiceRoleBinding — одредува кому му припаѓа оваа услуга Улога.

За обичните корисници ќе дозволиме пристап до одредени услуги (сервисна улога.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: ["*"]

И потоа regular-user-binding примени ServiceRole на сите посетители на страницата (редовен кориснички сервис-улога-врзување.yaml):

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRoleBinding
metadata:
  name: regular-user-binding
  namespace: default
spec:
  subjects:
  - user: "*"
  roleRef:
    kind: ServiceRole
    name: "regular-user"

Дали „сите корисници“ значи дека неавтентицираните корисници исто така ќе имаат пристап до SA WebApp? Не, политиката ќе ја провери валидноста на токенот JWT.

Ајде да ги примениме конфигурациите:

$ 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

Конфигурација за пристап за модераторите

За модераторите, сакаме да овозможиме пристап до сите услуги (mod-service-role.yaml):

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

Но, ние сакаме такви права само за оние корисници чијшто токен за пристап содржи приговор https://sa.io/group со значење 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" 

Ајде да ги примениме конфигурациите:

$ 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

Поради кеширање на пратеници, може да потрае неколку минути за да стапат на сила правилата за овластување. Потоа можете да се осигурате дека корисниците и модераторите имаат различни нивоа на пристап.

Заклучок за овој дел

Сепак, сериозно, дали некогаш сте виделе поедноставен, без напор, скалабилен и безбеден пристап за автентикација и овластување?

Само три ресурси на Istio (RbacConfig, ServiceRole и ServiceRoleBinding) беа потребни за да се постигне ситно-грануларна контрола врз автентикацијата и овластувањето на пристапот на крајниот корисник до услугите.

Покрај тоа, ние се погриживме за овие прашања надвор од нашите пратенички служби, постигнувајќи:

• намалување на количината на генерички код што може да содржи безбедносни проблеми и грешки;
• намалување на бројот на глупави ситуации во кои една крајна точка се покажа дека е достапна однадвор и заборавила да ја пријави;
• елиминирање на потребата за ажурирање на сите услуги секогаш кога се додава нова улога или право;
• дека новите услуги остануваат едноставни, безбедни и брзи.

Излез

Istio им овозможува на тимовите да ги фокусираат своите ресурси на деловните клучни задачи без да додаваат трошоци на услугите, враќајќи ги во микро статус.

Статијата (во три дела) даде основни знаења и готови практични упатства за започнување со Istio во реални проекти.

PS од преведувач

Прочитајте и на нашиот блог:

• „Назад кон микросервисите со Истио“: дел 1 (вовед во главните карактеристики), дел 2 (маршрута, контрола на сообраќајот);
• «Проводник - лесна сервисна мрежа за Kubernetes";
• «Што е сервисна мрежа и зошто ми е потребна [за облак апликација со микросервиси]?".

Извор: www.habr.com