Istio көмегімен микросервистерге оралу. 3 бөлім

Ескерту. аударма: Бірінші бөлім бұл серия Истио мүмкіндіктерін білуге ​​және оларды іс-әрекетте көрсетуге арналған, екіншісі — дәл бапталған маршруттау және желілік трафикті басқару. Енді біз қауіпсіздік туралы айтатын боламыз: оған қатысты негізгі функцияларды көрсету үшін автор Auth0 сәйкестендіру қызметін пайдаланады, бірақ басқа провайдерлерді де дәл осылай конфигурациялауға болады.

Istio мүмкіндіктерін көрсету үшін біз Kubernetes кластерін орнаттық, онда Istio және мысал микросервис қолданбасы, Сезім талдауы, Istio мүмкіндіктерін көрсету.

Istio көмегімен біз қызметтерімізді кішігірім сақтай алдық, себебі олар қайталаулар, күту уақыттары, автоматты ажыратқыштар, бақылау, бақылау сияқты қабаттарды енгізудің қажеті жоқ. . Сонымен қатар, біз кеңейтілген тестілеу және орналастыру әдістерін қолдандық: A/B тестілеу, айна және канарларды шығару.

Жаңа материалда біз іскерлік құндылық жолындағы соңғы қабаттармен айналысамыз: аутентификация және авторизация - және Istio-да бұл нағыз рахат!

Istio-да аутентификация және авторизация

Мен аутентификация мен авторизациядан шабыт алатыныма ешқашан сенбес едім. Istio осы тақырыптарды қызықты және одан да шабыттандыратын технология тұрғысынан не ұсына алады?

Жауап қарапайым: Istio осы мүмкіндіктер үшін жауапкершілікті қызметтеріңізден Envoy проксиіне ауыстырады. Сұраулар қызметтерге жеткенше олар аутентификациядан өтіп, рұқсат етілген, сондықтан сізге тек бизнеске пайдалы код жазу жеткілікті.

Жақсы? Ішіне қарайық!

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

Осындай ресурспен, Ұшқыш (Istio ішіндегі үш негізгі Басқару жазықтығы құрамдастарының бірі – шамамен аудар.) Өкілді сұрауларды қызметтерге жібермес бұрын аутентификациялау үшін конфигурациялайды: 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 көмегімен сұрауларды аутентификациялау

Түпнұсқалық пайдаланушы сұрауларының түпнұсқалығын растау үшін аутентификацияланған қызметтерді (шолулар, мәліметтер және бағалаулар) көрсететін Auth0 ішінде API жасау керек. API жасау үшін мына мекенжайға өтіңіз Auth0 Порталы > API интерфейстері > API жасау және пішінді толтырыңыз:

Мұндағы маңызды ақпарат идентификатор, біз оны кейінірек сценарийде қолданамыз. Оны былай жазайық:

• Аудитория: {Your_AUDIENCE}

Бізге қажет қалған мәліметтер бөлімдегі Auth0 порталында орналасқан Бағдарламалар - таңдау Сынақ қолданбасы (API-мен бірге автоматты түрде жасалады).

Мұнда біз жазамыз:

• Домен: {YOUR_DOMAIN}
• Клиент идентификаторы: {YOUR_CLIENT_ID}

тармағына айналдырыңыз Сынақ қолданбасы мәтін өрісіне Рұқсат етілген кері шақыру URL мекенжайлары (кері қоңырау үшін шешілген URL мекенжайлары), онда аутентификация аяқталғаннан кейін қоңырау жіберілетін URL мекенжайын көрсетеміз. Біздің жағдайда бұл:

http://{EXTERNAL_IP}/callback

Және үшін Рұқсат етілген Шығу URL мекенжайлары (шығуға рұқсат етілген URL мекенжайлары) мынаны қосыңыз:

http://{EXTERNAL_IP}/logout

Алдыңғы жағына көшейік.

Frontend жаңартуы

Филиалға ауысу 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 идентификаторыңызды көрсетіңіз:

$ 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 порталына өтіңіз Ережелер, түймесін басыңыз Ереже жасау және үлгілерден бос ережені таңдаңыз.

Төмендегі кодты көшіріп, оны жаңа ереже ретінде сақтаңыз Топтық шағымды қосыңыз (namespacedGroup.js):

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

ескерту: Бұл код Авторизация кеңейтімінде анықталған бірінші пайдаланушы тобын қабылдайды және оны пайдаланушылық шағым ретінде қатынас белгісіне қосады (Auth0 талап еткендей оның аттар кеңістігінде).

Бетке оралу Ережелер және сізде келесі ретпен жазылған екі ереже бар екенін тексеріңіз:

• auth0-авторизация-кеңейту
• Топтық шағымды қосыңыз

Тапсырыс маңызды, себебі топ өрісі ережені асинхронды түрде қабылдайды auth0-авторизация-кеңейту ал одан кейін екінші ереже бойынша талап ретінде қосылады. Нәтиже келесідей қол жеткізу белгісі болып табылады:

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

Енді пайдаланушы рұқсатын тексеру үшін Envoy проксиін конфигурациялау керек, ол үшін топ шағымдан шығарылады (https://sa.io/group) қайтарылған қатынас белгісінде. Бұл мақаланың келесі тарауының тақырыбы.

Istio ішіндегі авторизация конфигурациясы

Авторизация жұмыс істеуі үшін Istio үшін RBAC қосу керек. Ол үшін келесі конфигурацияны қолданамыз:

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 ресурстарын пайдалану арқылы жүзеге асырылды:

• ServiceRole — пайдаланушының құқықтарын анықтайды;
• ServiceRoleBinding — бұл ServiceRole кімге тиесілі екенін анықтайды.

Қарапайым пайдаланушылар үшін біз белгілі бір қызметтерге қол жеткізуге рұқсат береміз (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: ["*"]

Ал кейін 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

Біздің блогта да оқыңыз:

• «Istio көмегімен микросервистерге оралу»: 1 бөлім (негізгі мүмкіндіктерге кіріспе), 2 бөлім (маршруттау, қозғалысты басқару);
• «Conduit - Kubernetes үшін жеңіл қызмет көрсету торы«;
• «Қызметтік тор дегеніміз не және ол маған не үшін қажет [микросервистері бар бұлттық қолданба үшін]?«.

Ақпарат көзі: www.habr.com