🥇Rudi kwenye huduma ndogo ukitumia Istio. Sehemu ya 3

Kumbuka. tafsiri.: sehemu ya kwanza mfululizo huu ulijitolea kujua uwezo wa Istio na kuwaonyesha kwa vitendo, pili - uelekezaji uliopangwa vyema na usimamizi wa trafiki wa mtandao. Sasa tutazungumza juu ya usalama: ili kuonyesha kazi za kimsingi zinazohusiana nayo, mwandishi hutumia huduma ya kitambulisho cha Auth0, lakini watoa huduma wengine wanaweza kusanidiwa kwa njia sawa.

Tulianzisha kundi la Kubernetes ambamo tulituma Istio na mfano wa maombi ya huduma ndogo, Uchambuzi wa Sentiment, ili kuonyesha uwezo wa Istio.

Tukiwa na Istio, tuliweza kufanya huduma zetu kuwa ndogo kwa sababu hazihitaji kutekeleza safu kama vile Majaribu tena, Muda wa Kuisha, Vivunja Mzunguko, Ufuatiliaji, Ufuatiliaji. . Zaidi ya hayo, tulitumia mbinu za kina za majaribio na kupeleka: majaribio ya A/B, uakisi na uchapishaji wa canary.

Katika nyenzo mpya, tutashughulika na tabaka za mwisho kwenye njia ya thamani ya biashara: uthibitishaji na idhini - na katika Istio ni furaha ya kweli!

Uthibitishaji na uidhinishaji katika Istio

Sikuwahi kuamini kwamba ningehamasishwa na uthibitishaji na uidhinishaji. Je, Istio inaweza kutoa nini kutoka kwa mtazamo wa teknolojia ili kufanya mada hizi kuwa za kufurahisha na, hata zaidi, kukutia moyo?

Jibu ni rahisi: Istio huhamisha wajibu wa uwezo huu kutoka kwa huduma zako hadi kwa wakala wa Mjumbe. Kufikia wakati maombi yanapofikia huduma, tayari yameidhinishwa na kuidhinishwa, kwa hivyo unachotakiwa kufanya ni kuandika msimbo wa manufaa wa kibiashara.

Inasikika vizuri? Hebu tuangalie ndani!

Uthibitishaji na Auth0

Kama seva ya utambulisho na udhibiti wa ufikiaji, tutatumia Auth0, ambayo ina toleo la majaribio, rahisi kutumia na ninaipenda kwa urahisi. Hata hivyo, kanuni sawa zinaweza kutumika kwa nyingine yoyote Utekelezaji wa OpenID Connect: KeyCloak, IdentityServer na wengine wengi.

Ili kuanza, nenda kwa Auth0 Portal kwa akaunti yako, unda mpangaji (mpangaji - "mpangaji", kitengo cha kimantiki cha kutengwa, kwa maelezo zaidi tazama nyaraka - takriban. tafsiri.) na kwenda Programu > Programu Chaguomsingikuchagua Domain, kama inavyoonyeshwa kwenye picha ya skrini hapa chini:

Bainisha kikoa hiki kwenye faili resource-manifests/istio/security/auth-policy.yaml (chanzo):

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

Na rasilimali kama hiyo, Pilot (mojawapo ya vipengele vitatu vya msingi vya Ndege ya Kudhibiti katika Istio - takriban. transl.) husanidi Mjumbe ili kuthibitisha maombi kabla ya kuyasambaza kwa huduma: sa-web-app и sa-feedback. Wakati huo huo, usanidi hautumiki kwa Wajumbe wa huduma sa-frontend, ikituruhusu kuondoka sehemu ya mbele bila kuthibitishwa. Ili kutumia Sera, endesha amri:

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

Rudi kwenye ukurasa na ufanye ombi - utaona kwamba inaisha na hali 401 haidhinishwi. Sasa hebu tuelekeze upya watumiaji wa mandhari ya mbele ili kuthibitisha na Auth0.

Kuthibitisha maombi na Auth0

Ili kuthibitisha maombi ya mtumiaji wa mwisho, unahitaji kuunda API katika Auth0 ambayo itawakilisha huduma zilizoidhinishwa (maoni, maelezo na ukadiriaji). Ili kuunda API, nenda kwa Auth0 Portal > API > Unda API na ujaze fomu:

Taarifa muhimu hapa ni kutambua, ambayo tutatumia baadaye kwenye hati. Hebu tuandike kama hii:

Watazamaji: {Watazamaji_WAKO}

Maelezo yaliyosalia tunayohitaji yanapatikana kwenye Tovuti ya Auth0 katika sehemu hiyo matumizi - chagua Maombi ya Mtihani (iliyoundwa kiotomatiki pamoja na API).

Hapa tutaandika:

Domain: {YOUR_DOMAIN}
Kitambulisho cha Mteja: {KITAmbulisho_chako_chako}

Tembeza hadi Maombi ya Mtihani kwa uwanja wa maandishi URL za Kupiga Simu Zinazoruhusiwa (URL zilizotatuliwa za upigaji simu), ambamo tunabainisha URL ambapo simu inapaswa kutumwa baada ya uthibitishaji kukamilika. Kwa upande wetu ni:

http://{EXTERNAL_IP}/callback

Na kwa URL za Ondoka zinazoruhusiwa (URL zinazoruhusiwa za kuondoka) ongeza:

http://{EXTERNAL_IP}/logout

Hebu tuendelee kwenye mstari wa mbele.

Sasisho la mbele

Badilisha hadi tawi auth0 hazina [istio-mastery]. Katika tawi hili, msimbo wa mbele hubadilishwa ili kuelekeza watumiaji kwa Auth0 kwa uthibitishaji na kutumia tokeni ya JWT katika maombi ya huduma zingine. Mwisho unatekelezwa kama ifuatavyo (Programu.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));
}

Ili kubadilisha sehemu ya mbele ili kutumia data ya mpangaji katika Auth0, fungua sa-frontend/src/services/Auth.js na ubadilishe ndani yake maadili ambayo tuliandika hapo juu (Auth.js):

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

Programu iko tayari. Bainisha Kitambulisho chako cha Docker katika amri zilizo hapa chini wakati wa kujenga na kupeleka mabadiliko yaliyofanywa:

$ 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

Jaribu programu! Utaelekezwa kwa Auth0, ambapo unahitaji kuingia (au kujiandikisha), baada ya hapo utarejeshwa kwenye ukurasa ambao maombi yaliyothibitishwa tayari yatafanywa. Ikiwa unajaribu amri zilizotajwa katika sehemu za kwanza za makala na curl, utapata msimbo 401 Msimbo wa Hali, ikiashiria kwamba ombi halijaidhinishwa.

Hebu tuchukue hatua inayofuata - kuidhinisha maombi.

Uidhinishaji na Auth0

Uthibitishaji huturuhusu kuelewa mtumiaji ni nani, lakini idhini inahitajika ili kujua anachoweza kufikia. Istio inatoa zana kwa hili pia.

Kama mfano, wacha tuunde vikundi viwili vya watumiaji (tazama mchoro hapa chini):

Watumiaji (watumiaji) - na ufikiaji wa huduma za SA-WebApp na SA-Frontend pekee;
Wasimamizi (wasimamizi) — na ufikiaji wa huduma zote tatu.

Dhana ya idhini

Ili kuunda vikundi hivi, tutatumia kiendelezi cha Uidhinishaji wa Auth0 na kutumia Istio kuwapa viwango tofauti vya ufikiaji.

Ufungaji na usanidi wa Auth0 Authorization

Katika lango la Auth0, nenda kwa viendelezi (Upanuzi) na usakinishe Uidhinishaji0. Baada ya ufungaji, nenda kwa Upanuzi wa Uidhinishaji, na huko - kwa usanidi wa mpangaji kwa kubofya kulia juu na kuchagua chaguo sahihi la menyu. (Usanidi). Washa vikundi (Vikundi) na ubofye kitufe cha sheria cha kuchapisha (Chapisha sheria).

Kuunda vikundi

Katika Kiendelezi cha Uidhinishaji nenda kwa Vikundi na kuunda kikundi Wasimamizi. Kwa kuwa tutawachukulia watumiaji wote walioidhinishwa kama watumiaji wa kawaida, hakuna haja ya kuwaundia kikundi cha ziada.

Chagua kikundi Wasimamizi, Bonyeza Ongeza Wanachama, ongeza akaunti yako kuu. Waache baadhi ya watumiaji bila kikundi chochote ili kuhakikisha kuwa wamenyimwa ufikiaji. (Watumiaji wapya wanaweza kuundwa kwa mikono kupitia Auth0 Portal > Watumiaji > Unda Mtumiaji.)

Ongeza Dai la Kikundi kwenye Tokeni ya Ufikiaji

Watumiaji wameongezwa kwa vikundi, lakini habari hii lazima pia ionekane katika tokeni za ufikiaji. Ili kuzingatia OpenID Connect na wakati huo huo kurudisha vikundi tunavyohitaji, ishara itahitaji kuongeza yake mwenyewe. madai maalum. Inatekelezwa kupitia sheria za Auth0.

Ili kuunda sheria, nenda kwa Auth0 Portal kwa Sheria, Bonyeza Tengeneza Kanuni na uchague sheria tupu kutoka kwa violezo.

Nakili msimbo ulio hapa chini na uuhifadhi kama sheria mpya Ongeza Dai la Kikundi (namespacedGroup.js):

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

Kumbuka: Msimbo huu huchukua kikundi cha kwanza cha mtumiaji kilichobainishwa katika Kiendelezi cha Uidhinishaji na kuiongeza kwenye tokeni ya ufikiaji kama dai maalum (chini ya nafasi yake ya jina, kama inavyotakiwa na Auth0).

Rudi kwenye ukurasa Sheria na hakikisha kuwa una sheria mbili zilizoandikwa kwa mpangilio ufuatao:

auth0-idhini-kiendelezi
Ongeza Dai la Kikundi

Agizo ni muhimu kwa sababu uga wa kikundi hupokea sheria kwa usawa auth0-idhini-kiendelezi na baada ya hapo inaongezwa kama dai na kanuni ya pili. Matokeo yake ni ishara ya ufikiaji kama hii:

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

Sasa unahitaji kusanidi mwakilishi wa Mjumbe ili kuangalia ufikiaji wa mtumiaji, ambayo kikundi kitatolewa kutoka kwa dai (https://sa.io/group) katika tokeni ya ufikiaji iliyorejeshwa. Hii ndio mada ya sehemu inayofuata ya kifungu hicho.

Usanidi wa uidhinishaji katika Istio

Ili uidhinishaji ufanye kazi, lazima uwashe RBAC kwa Istio. Ili kufanya hivyo, tutatumia usanidi ufuatao:

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"

Maelezo:

1 — wezesha RBAC kwa huduma na nafasi za majina zilizoorodheshwa tu kwenye uwanja Inclusion;
2 - tunaorodhesha orodha ya huduma zetu.

Wacha tutumie usanidi kwa amri ifuatayo:

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

Huduma zote sasa zinahitaji Udhibiti wa Ufikiaji wa Wajibu. Kwa maneno mengine, ufikiaji wa huduma zote ni marufuku na itasababisha jibu RBAC: access denied. Sasa hebu turuhusu ufikiaji kwa watumiaji walioidhinishwa.

Usanidi wa ufikiaji kwa watumiaji wa kawaida

Watumiaji wote lazima wapate huduma za SA-Frontend na SA-WebApp. Inatekelezwa kwa kutumia rasilimali zifuatazo za Istio:

HudumaWajibu - huamua haki ambazo mtumiaji anazo;
HudumaRoleBinding - huamua Huduma hii ni ya nani.

Kwa watumiaji wa kawaida tutaruhusu ufikiaji wa huduma fulani (huduma.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: ["*"]

Na kupitia regular-user-binding tumia ServiceRole kwa wageni wote wa ukurasa (kawaida-mtumiaji-huduma-jukumu-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"

Je, "watumiaji wote" inamaanisha kuwa watumiaji ambao hawajaidhinishwa pia watapata ufikiaji wa SA WebApp? Hapana, sera itaangalia uhalali wa tokeni ya JWT.

Wacha tutumie usanidi:

$ 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

Mipangilio ya ufikiaji kwa wasimamizi

Kwa wasimamizi, tunataka kuwezesha ufikiaji wa huduma zote (mod-service-jukumu.yaml):

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

Lakini tunataka haki kama hizo kwa wale tu watumiaji ambao tokeni ya ufikiaji ina dai https://sa.io/group yenye maana Moderators (mod-service-jukumu-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"

Wacha tutumie usanidi:

$ 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

Kwa sababu ya kuweka akiba kwa wajumbe, inaweza kuchukua dakika kadhaa kwa sheria za uidhinishaji kutekelezwa. Kisha unaweza kuhakikisha kuwa watumiaji na wasimamizi wana viwango tofauti vya ufikiaji.

Hitimisho kwa sehemu hii

Hata hivyo, je, umewahi kuona njia rahisi, isiyo na juhudi, hatari na salama ya uthibitishaji na uidhinishaji?

Nyenzo tatu pekee za Istio (RbacConfig, ServiceRole, na ServiceRoleBinding) zilihitajika kufikia udhibiti mzuri wa uthibitishaji na uidhinishaji wa ufikiaji wa mtumiaji wa mwisho kwa huduma.

Kwa kuongezea, tumeshughulikia maswala haya kutoka kwa huduma za wajumbe wetu, na kufikia:

kupunguza kiasi cha msimbo wa jumla ambao unaweza kuwa na matatizo ya usalama na hitilafu;
kupunguza idadi ya hali ya kijinga ambayo mwisho mmoja uligeuka kupatikana kutoka nje na kusahau kuripoti;
kuondoa hitaji la kusasisha huduma zote kila wakati jukumu au haki mpya inapoongezwa;
kwamba huduma mpya zibaki kuwa rahisi, salama na za haraka.

Pato

Istio inaruhusu timu kuelekeza rasilimali zao kwenye kazi muhimu za biashara bila kuongeza huduma, kuzirejesha kwa hali ndogo.

Nakala (katika sehemu tatu) ilitoa maarifa ya kimsingi na maagizo ya vitendo yaliyotengenezwa tayari ya kuanza na Istio katika miradi halisi.

PS kutoka kwa mtafsiri

Soma pia kwenye blogi yetu:

"Rudi kwa huduma ndogo na Istio": Sehemu ya 1 (utangulizi wa sifa kuu), Sehemu ya 2 (kuelekeza, kudhibiti trafiki);
«Mfereji - mesh ya huduma nyepesi kwa Kubernetes";
«Mesh ya huduma ni nini na kwa nini ninaihitaji [kwa programu ya wingu iliyo na huduma ndogo]?'.

Chanzo: mapenzi.com

Rudi kwa huduma ndogo na Istio. Sehemu 3