🥇Վերադարձ դեպի միկրոսերվիսներ Istio-ի հետ։ Մաս 3

Նշում. թարգմ.: Առաջին մասը այս շարքը նվիրված էր Istio-ի հնարավորություններին ծանոթանալուն և դրանք գործողության մեջ դրսևորելուն, երկրորդ — մանրակրկիտ կարգավորված երթուղի և ցանցային երթևեկության կառավարում: Այժմ մենք կխոսենք անվտանգության մասին. դրա հետ կապված հիմնական գործառույթները ցուցադրելու համար հեղինակն օգտագործում է Auth0 նույնականացման ծառայությունը, սակայն մյուս պրովայդերները կարող են կարգավորվել նմանատիպ ձևով:

Մենք ստեղծեցինք Kubernetes կլաստերը, որտեղ մենք տեղակայեցինք Istio-ն և օրինակ միկրոծառայության հավելված՝ Sentiment Analysis՝ ցուցադրելու Istio-ի հնարավորությունները:

Istio-ի հետ մենք կարողացանք փոքրացնել մեր ծառայությունները, քանի որ դրանք կարիք չունեն այնպիսի շերտերի ներդրման, ինչպիսիք են Կրկնական փորձերը, ժամանակի ընդհատումները, անջատիչները, հետագծումը, մոնիտորինգը: Բացի այդ, մենք օգտագործեցինք առաջադեմ փորձարկման և տեղակայման տեխնիկա.

Նոր նյութում մենք կզբաղվենք բիզնեսի արժեքի ուղու վերջնական շերտերով` վավերացում և թույլտվություն, իսկ Իստիոյում դա իսկական հաճույք է:

Նույնականացում և թույլտվություն 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-ում Կառավարման ինքնաթիռի երեք հիմնական բաղադրիչներից մեկը - մոտավորապես թարգմ.) կարգավորում է Բանագնացներին, որպեսզի նույնականացնեն հարցումները՝ նախքան դրանք ծառայություններ ուղարկելը. sa-web-app и sa-feedback. Միևնույն ժամանակ, կոնֆիգուրացիան չի կիրառվում սպասարկող Envoys-ի վրա 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 > Ստեղծել 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-ով

Նույնականացումը մեզ թույլ է տալիս հասկանալ, թե ով է օգտատերը, սակայն թույլտվություն է պահանջվում՝ իմանալու համար, թե ինչն է նրանց հասանելի: Istio-ն առաջարկում է նաև գործիքներ դրա համար:

Որպես օրինակ, եկեք ստեղծենք երկու օգտվողների խումբ (տես ստորև ներկայացված դիագրամը).

Անդամներ (օգտատերեր) — միայն SA-WebApp և SA-Frontend ծառայություններին հասանելիությամբ.
Մոդերատորներ (մոդերատորներ) — բոլոր երեք ծառայությունների հասանելիությամբ:

Լիազորման հայեցակարգ

Այս խմբերը ստեղծելու համար մենք կօգտագործենք Auth0 Authorization ընդլայնումը և կօգտագործենք Istio՝ նրանց հասանելիության տարբեր մակարդակներ տրամադրելու համար:

Auth0 թույլտվության տեղադրում և կազմաձևում

Auth0 պորտալում անցեք ընդարձակումներ (Ստուգման) և տեղադրել Auth0 թույլտվություն. Տեղադրվելուց հետո անցեք Թույլտվության երկարաձգումև այնտեղ՝ դեպի վարձակալի կոնֆիգուրացիա՝ սեղմելով վերևի աջ կողմում և ընտրելով ցանկի համապատասխան տարբերակը (Կազմաձևում). Ակտիվացրեք խմբերը (Խմբեր) և սեղմեք հրապարակման կանոնի կոճակը (Հրապարակել կանոնը).

Խմբերի ստեղծում

Թույլտվության ընդլայնման մեջ գնացեք Խմբեր և ստեղծել խումբ Մոդերատորներ. Քանի որ մենք բոլոր վավերացված օգտվողներին կվերաբերվենք որպես սովորական օգտատերերի, նրանց համար լրացուցիչ խումբ ստեղծելու կարիք չկա:

Ընտրեք խումբ Մոդերատորներ, մատնանշեք Ավելացնել անդամներ, ավելացրեք ձեր հիմնական հաշիվը: Որոշ օգտատերերի թողեք առանց որևէ խմբի՝ համոզվելու համար, որ նրանց մուտքն արգելված է: (Նոր օգտվողները կարող են ձեռքով ստեղծվել միջոցով Auth0 պորտալ > Օգտագործողներ > Ստեղծել օգտվող.)

Ավելացնել խմբային հայցը Access Token-ին

Օգտատերերը ավելացվել են խմբերին, սակայն այս տեղեկատվությունը պետք է արտացոլվի նաև մուտքի նշաններում: OpenID Connect-ին համապատասխանելու և միևնույն ժամանակ մեզ անհրաժեշտ խմբերը վերադարձնելու համար նշանը պետք է ավելացնի իրը մաքսային պահանջ. Իրականացվում է Auth0 կանոնների միջոցով:

Կանոն ստեղծելու համար անցեք Auth0 Portal դեպի Կանոններ, մատնանշեք Ստեղծել կանոն և կաղապարներից ընտրեք դատարկ կանոն:

Պատճենեք ստորև նշված կոդը և պահպանեք այն որպես նոր կանոն Ավելացնել խմբային հայց (namespacedGroup.js):

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

ՆշումԱյս կոդը վերցնում է օգտատերերի առաջին խումբը, որը սահմանված է Թույլտվության ընդլայնման մեջ և ավելացնում այն մուտքի նշանին որպես հատուկ պահանջ (իր անվանատարածքի տակ, ինչպես պահանջվում է Auth0-ի կողմից):

Վերադառնալ էջ Կանոններ և ստուգեք, որ ունեք հետևյալ հաջորդականությամբ գրված երկու կանոն.

auth0-authorization-extension
Ավելացնել խմբային հայց

Պատվերը կարևոր է, քանի որ խմբային դաշտը կանոնը ստանում է ասինխրոն կերպով auth0-authorization-extension իսկ դրանից հետո որպես պահանջ ավելացվում է երկրորդ կանոնով. Արդյունքն այսպիսի մուտքի նշան է.

{
 "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 — որոշում է, թե ում է պատկանում այս 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 էջի բոլոր այցելուներին (regular-user-service-role-binding.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 (երթուղի, երթևեկության վերահսկում);
«Խողովակ - թեթև սպասարկման ցանց Kubernetes-ի համար";
«Ի՞նչ է սպասարկման ցանցը և ինչո՞ւ է այն ինձ անհրաժեշտ [միկրոծառայությունների հետ ամպային հավելվածի համար]:.

Source: www.habr.com

Վերադարձ դեպի միկրոսերվիսներ Istio-ով։ Մաս 3