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

Эскертүү. котормо.: биринчи бөлүгү бул серия Истионун мүмкүнчүлүктөрү менен таанышууга жана аларды иш жүзүндө көрсөтүүгө арналган, экинчи — такталган маршрутизация жана тармактык трафикти башкаруу. Эми биз коопсуздук жөнүндө сүйлөшөбүз: ага байланыштуу негизги функцияларды көрсөтүү үчүн автор Auth0 идентификация кызматын колдонот, бирок башка провайдерлерди да ушундай эле конфигурациялоого болот.

Istio'нун мүмкүнчүлүктөрүн көрсөтүү үчүн биз Istio жана мисал микросервис тиркемесин, Сезим талдоосун орноткон Kubernetes кластерин орноттук.

Istio менен биз кызматтарыбызды кичине сактай алдык, анткени алар кайра аракет кылуу, күтүү убакыты, автоматтык өчүргүчтөр, байкоо, мониторинг сыяктуу катмарларды ишке ашыруунун кереги жок. Мындан тышкары, биз өнүккөн тестирлөө жана жайылтуу ыкмаларын колдондук: A/B тестирлөө, чагылдыруу жана канарларды чыгаруу.

Жаңы материалда биз бизнестин баалуулугуна карай жолдун акыркы катмарлары менен алектенебиз: аутентификация жана авторизация - жана Истиодо бул чыныгы ырахат!

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

Аутентификациядан жана авторизациядан шыктанам деп эч качан ишенген эмесмин. 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

Мындай ресурс менен, Pilot (Istio ичиндеги үч негизги Control Plane компоненттеринин бири - болжол менен котормо.) Өтүнүчтөрдү кызматтарга жөнөтүүдөн мурун аныктыгын текшерүү үчүн Элчи конфигурациялайт: 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}
• Кардар ID: {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 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 менен авторизация

Аутентификация колдонуучу ким экенин түшүнүүгө мүмкүндүк берет, бирок алар эмнеге кире аларын билүү үчүн авторизация талап кылынат. Isio да бул үчүн куралдарды сунуш кылат.

Мисал катары, эки колдонуучу тобун түзөлү (төмөндөгү диаграмманы караңыз):

• колдонуучулар (колдонуучулар) — SA-WebApp жана SA-Frontend кызматтарына гана жетүү менен;
• Алып баруучулар (модераторлор) — бардык үч кызматтын жеткиликтүүлүгү менен.

Авторизация концепциясы

Бул топторду түзүү үчүн биз Auth0 Authorization кеңейтүүсүн колдонобуз жана аларга ар кандай мүмкүнчүлүктөрдү берүү үчүн Istio колдонобуз.

Auth0 авторизациясын орнотуу жана конфигурациялоо

Auth0 порталында кеңейтүүлөргө өтүңүз (Extensions) жана орнотуу 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"
 // [сокращено для наглядности]
}

Эми сиз Колдонуучунун проксисин конфигурациялашыңыз керек, ал үчүн топ дооматтан чыгарылат (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-сервис-рол-милдеттүү.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 үчүн жеңил кызматтык тор";
• «Кызматтык тор деген эмне жана ал мага эмне үчүн керек [микросервистери бар булут колдонмосу үчүн]?«.

Source: www.habr.com