Назад на микроуслуге са Истиом. део 3

Белешка. трансл.: Први део ова серија је била посвећена упознавању могућности Истио-а и њиховом демонстрирању на делу, Други — фино подешено рутирање и управљање мрежним саобраћајем. Сада ћемо причати о безбедности: да би демонстрирао основне функције везане за то, аутор користи услугу идентитета Аутх0, али на сличан начин се могу конфигурисати и други провајдери.

Поставили смо Кубернетес кластер у који смо применили Истио и пример микросервисне апликације, Сентимент Аналисис, да бисмо демонстрирали Истио могућности.

Са Истио-ом, успели смо да задржимо наше услуге на малом нивоу јер не морају да имплементирају слојеве као што су Ретриес, Тимеоутс, Цирцуит Бреакерс, Трацинг, Мониторинг. Поред тога, користили смо напредне технике тестирања и примене: А/Б тестирање, пресликавање и увођење канараца.

У новом материјалу бавићемо се последњим слојевима на путу ка пословној вредности: аутентификацијом и ауторизацијом - а у Истио-у је право задовољство!

Аутентификација и ауторизација у Истио

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

Одговор је једноставан: Истио пребацује одговорност за ове могућности са ваших услуга на Енвои проки. Док захтеви стигну до сервиса, они су већ проверени и ауторизовани, тако да све што треба да урадите је да напишете пословни код.

Добро звучи? Хајде да погледамо унутра!

Аутентификација са Аутх0

Као сервер за управљање идентитетом и приступом, користићемо Аутх0, који има пробну верзију, интуитиван је за употребу и једноставно ми се свиђа. Међутим, исти принципи се могу применити на било који други Имплементације ОпенИД Цоннецт-а: КеиЦлоак, ИдентитиСервер и многи други.

Да бисте започели, идите на Аутх0 Портал са својим налогом, направите закупца (станар - „станар“, логичка јединица изолације, за више детаља види документација — прибл. превод) и идите на Апликације > Подразумевана апликацијаизбор Домен, као што је приказано на слици испод:

Наведите овај домен у датотеци 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

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

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

Вратите се на страницу и направите захтев - видећете да се завршава статусом КСНУМКС неовлашћено. Хајде сада да преусмеримо кориснике фронтенда на аутентификацију помоћу Аутх0.

Провера аутентичности захтева са Аутх0

Да бисте потврдили аутентичност захтева крајњих корисника, потребно је да креирате АПИ у Аутх0 који ће представљати проверене услуге (рецензије, детаљи и оцене). Да бисте креирали АПИ, идите на Аутх0 Портал > АПИ-ји > Креирај АПИ и попуните формулар:

Важна информација овде је идентификатор, који ћемо користити касније у скрипти. Хајде да то запишемо овако:

• Аудијенција: {ИОУР_АУДИЕНЦЕ}

Преостали детаљи који су нам потребни налазе се на порталу Аутх0 у одељку aplikacije — изаберите Тест Апплицатион (креира се аутоматски заједно са АПИ-јем).

Овде ћемо написати:

• Домен: {ИОУР_ДОМАИН}
• ИД клијента: {ИОУР_ЦЛИЕНТ_ИД}

Дођите до Тест Апплицатион у текстуално поље Дозвољене УРЛ адресе за повратни позив (разрешене УРЛ адресе за повратни позив), у којима наводимо УРЛ на који треба послати позив након што је аутентификација завршена. У нашем случају то је:

http://{EXTERNAL_IP}/callback

И за Дозвољене УРЛ адресе за одјаву (дозвољене УРЛ адресе за одјављивање) додајте:

http://{EXTERNAL_IP}/logout

Пређимо на фронтенд.

Фронтенд упдате

Пребаците се на грану auth0 репозиториа [istio-mastery]. У овој грани, фронтенд код је промењен како би се корисници преусмерили на Аутх0 за аутентификацију и користили ЈВТ токен у захтевима за друге услуге. Ово последње се спроводи на следећи начин (Апп.јс):

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));
}

Да бисте променили фронтенд да користи податке станара у Аутх0, отворите sa-frontend/src/services/Auth.js и замените у њему вредности које смо горе написали (Аутх.јс):

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

Апликација је спремна. Наведите свој Доцкер ИД у наредбама у наставку када правите и примењујете унете промене:

$ 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

Испробајте апликацију! Бићете преусмерени на Аутх0, где је потребно да се пријавите (или региструјете), након чега ћете бити враћени на страницу са које ће бити упућени већ проверени захтеви. Ако испробате команде поменуте у првим деловима чланка са цурл-ом, добићете код 401 Статус Цоде, сигнализирајући да захтев није овлашћен.

Хајдемо на следећи корак - ауторизовати захтеве.

Ауторизација са Аутх0

Аутентификација нам омогућава да разумемо ко је корисник, али је потребна ауторизација да бисмо знали чему има приступ. Истио такође нуди алате за ово.

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

• Чланови (корисници) — са приступом само сервисима СА-ВебАпп и СА-Фронтенд;
• Модератори (модератори) — са приступом све три услуге.

Концепт ауторизације

Да бисмо креирали ове групе, користићемо екстензију Аутх0 Аутхоризатион и користити Истио да бисмо им омогућили различите нивое приступа.

Инсталација и конфигурација Аутх0 ауторизације

На порталу Аутх0 идите на екстензије (екстензије) и инсталирајте Аутх0 Аутхоризатион. Након инсталације идите на Проширење ауторизације, а тамо - до конфигурације станара тако што ћете кликнути у горњем десном углу и изабрати одговарајућу опцију менија (Конфигурација). Активирајте групе (групе) и кликните на дугме за објављивање правила (Правило за објављивање).

Креирање група

У Проширење ауторизације идите на grupe и направите групу Модератори. Пошто ћемо све аутентификоване кориснике третирати као редовне кориснике, нема потребе за креирањем додатне групе за њих.

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

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

Корисници су додати у групе, али ове информације такође морају бити одражене у токенима за приступ. Да би се ускладио са ОпенИД Цоннецт и у исто време вратио групе које су нам потребне, токен ће морати да дода свој обичај потраживања. Имплементирано кроз Аутх0 правила.

Да бисте креирали правило, идите на Аутх0 Портал за Правила, Притисните Створи правило и изаберите празно правило из шаблона.

Копирајте код испод и сачувајте га као ново правило Додај групни захтев (намеспацедГроуп.јс):

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

Приметити: Овај код узима прву корисничку групу дефинисану у проширењу ауторизације и додаје је токену приступа као прилагођени захтев (у оквиру свог именског простора, како захтева Аутх0).

Повратак на страницу Правила и проверите да ли имате два правила написана следећим редоследом:

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

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

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

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

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

Да би ауторизација функционисала, морате омогућити РБАЦ за Истио. Да бисмо то урадили, користићемо следећу конфигурацију:

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 — омогући РБАЦ само за услуге и просторе имена наведене у пољу Inclusion;
• 2 — наводимо листу наших услуга.

Хајде да применимо конфигурацију следећом командом:

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

Све услуге сада захтевају контролу приступа засновану на улогама. Другим речима, приступ свим услугама је забрањен и резултираће одговором RBAC: access denied. Сада дозволимо приступ овлашћеним корисницима.

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

Сви корисници морају имати приступ услугама СА-Фронтенд и СА-ВебАпп. Имплементирано коришћењем следећих Истио ресурса:

• СервицеРоле — утврђује права која корисник има;
• СервицеРолеБиндинг — одређује коме припада ова СервицеРоле.

За обичне кориснике ћемо дозволити приступ одређеним услугама (сервицероле.иамл):

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 примени СервицеРоле на све посетиоце странице (регулар-усер-сервице-роле-биндинг.иамл):

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

Да ли „сви корисници“ значи да ће корисници без аутентификације такође имати приступ СА ВебАпп-у? Не, политика ће проверити валидност ЈВТ токена.

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

$ 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

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

За модераторе желимо да омогућимо приступ свим сервисима (мод-сервице-роле.иамл):

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

Али желимо таква права само за оне кориснике чији приступни токен садржи потраживање https://sa.io/group са значењем Moderators (мод-сервице-роле-биндинг.иамл):

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

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

Закључак о овом делу

Али озбиљно, да ли сте икада видели једноставнији, лакши, скалабилан и безбеднији приступ аутентификацији и ауторизацији?

Само три Истио ресурса (РбацЦонфиг, СервицеРоле и СервицеРолеБиндинг) су била потребна да би се постигла фино зрнаста контрола над аутентификацијом и ауторизацијом приступа крајњег корисника услугама.

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

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

Излаз

Истио омогућава тимовима да усредсреде своје ресурсе на пословне критичне задатке без додавања додатних трошкова услугама, враћајући их у микро статус.

Чланак (у три дела) пружа основна знања и готова практична упутства за почетак коришћења Истио-а у стварним пројектима.

ПС од преводиоца

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

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

Извор: ввв.хабр.цом