Werom nei mikrotsjinsten mei Istio. Diel 3

Noat. transl.: Earste diel dizze searje wie wijd oan it learen fan de mooglikheden fan Istio en demonstrearje se yn aksje, de twadde - fyn ôfstimd routing en netwurkferkearbehear. No sille wy prate oer feiligens: om de basisfunksjes dêrmei te demonstrearjen, brûkt de auteur de identiteitstsjinst Auth0, mar oare providers kinne op deselde manier konfigureare wurde.

Wy hawwe in Kubernetes-kluster ynsteld wêryn't wy Istio en in foarbyld fan mikrotsjinstapplikaasje, Sentiment Analysis, ynset hawwe om de mooglikheden fan Istio te demonstrearjen.

Mei Istio koene wy ​​ús tsjinsten lyts hâlde, om't se gjin lagen hoege te ymplementearjen lykas Retries, Timeouts, Circuit Breakers, Tracing, Monitoring. . Dêrnjonken brûkten wy avansearre test- en ynsettechniken: A / B-testen, spegeljen en kanaryske rollouts.

Yn it nije materiaal sille wy omgean mei de lêste lagen op it paad nei saaklike wearde: autentikaasje en autorisaasje - en yn Istio is it in echte wille!

Autentikaasje en autorisaasje yn Istio

Ik soe nea hawwe leaud dat ik soe wurde ynspirearre troch autentikaasje en autorisaasje. Wat kin Istio biede út in technologysk perspektyf om dizze ûnderwerpen leuk en, noch mear, ynspirearjend foar jo te meitsjen?

It antwurd is ienfâldich: Istio ferpleatst de ferantwurdlikens foar dizze mooglikheden fan jo tsjinsten nei de Envoy-proxy. Tsjin 'e tiid dat de oanfragen de tsjinsten berikke, binne se al authentisearre en autorisearre, dus alles wat jo hoege te dwaan is in saaklike brûkbere koade te skriuwen.

Klinkt goed? Litte wy nei binnen sjen!

Ferifikaasje mei Auth0

As tsjinner foar identiteit- en tagongsbehear sille wy Auth0 brûke, dy't in proefferzje hat, is yntuïtyf te brûken en ik fyn it gewoan leuk. Deselde prinsipes kinne lykwols tapast wurde op elke oare Implementaasjes fan OpenID Connect: KeyCloak, IdentityServer en in protte oaren.

Earst gean nei Auth0 Portal mei jo akkount, meitsje in hierder (hierder - "hierder", logyske ienheid fan isolemint, sjoch foar mear details dokumintaasje - ca. oerset.) en gean nei Applikaasjes > Standert appkiezen domein, lykas werjûn yn 'e skermôfbylding hjirûnder:

Spesifisearje dit domein yn it bestân resource-manifests/istio/security/auth-policy.yaml (boarne):

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

Mei sa'n boarne, Pilot (ien fan de trije basis Control Plane komponinten yn Istio - likernôch transl.) konfigurearret Envoy om fersiken te authentisearjen foardat se trochstjoerd wurde nei tsjinsten: sa-web-app и sa-feedback. Tagelyk wurdt de konfiguraasje net tapast op tsjinst Envoys sa-frontend, wêrtroch't wy de frontend unauthentisearre litte kinne. Om it belied oan te passen, fier it kommando út:

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

Gean werom nei de side en meitsje in fersyk - jo sille sjen dat it einiget mei de status 401 Net autorisearre. Litte wy no frontend-brûkers omliede om te ferifiearjen mei Auth0.

Ferifikaasje fan fersiken mei Auth0

Om fersiken fan einbrûkers te ferifiearjen, moatte jo in API yn Auth0 oanmeitsje dy't de ferifiearre tsjinsten (resinsjes, details en wurdearrings) fertsjintwurdigje. Om in API te meitsjen, gean nei Auth0 Portal > API's > API oanmeitsje en folje it formulier yn:

De wichtige ynformaasje hjir is identifisearje, dy't wy letter yn it skript sille brûke. Litte wy it sa opskriuwe:

• publyk: {YOUR_AUDIENCE}

De oerbleaune details dy't wy nedich binne lizze op it Auth0 Portal yn 'e seksje Oanfraach - útkieze Test Applikaasje (automatysk makke tegearre mei de API).

Hjir sille wy skriuwe:

• domein: {YOUR_DOMAIN}
• Client ID: {YOUR_CLIENT_ID}

Skow nei Test Applikaasje nei tekstfjild Tastiene werombel-URL's (besochte URL's foar it werombeljen), wêryn wy de URL oantsjutte wêr't de oprop ferstjoerd wurde moat neidat de autentikaasje foltôge is. Yn ús gefal is it:

http://{EXTERNAL_IP}/callback

En foar Tastean ôfmelde URL's (taste URL's foar ôfmelden) tafoegje:

http://{EXTERNAL_IP}/logout

Litte wy trochgean nei it frontend.

Frontend update

Wikselje nei branch auth0 repository [istio-mastery]. Yn dizze tûke wurdt de frontend-koade feroare om brûkers te ferwizen nei Auth0 foar autentikaasje en it JWT-token te brûken yn fersiken nei oare tsjinsten. Dat lêste wurdt útfierd as folget (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));
}

Om de frontend te feroarjen om hierdergegevens te brûken yn Auth0, iepenje sa-frontend/src/services/Auth.js en ferfange dêryn de wearden dy't wy hjirboppe skreaun hawwe (Auth.js):

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

De applikaasje is klear. Spesifisearje jo Docker ID yn 'e kommando's hjirûnder by it bouwen en ynsetten fan de makke wizigingen:

$ 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

Besykje de app! Jo wurde omlaat nei Auth0, wêr't jo moatte oanmelde (of registrearje), wêrnei't jo weromstjoerd wurde nei de side wêrfan al authentisearre oanfragen makke wurde. As jo ​​besykje de kommando's neamd yn 'e earste dielen fan it artikel mei curl, krije jo de koade 401 Status Code, sinjalearjen dat it fersyk net autorisearre is.

Litte wy de folgjende stap nimme - oanfragen autorisearje.

Autorisaasje mei Auth0

Autentikaasje lit ús begripe wa't in brûker is, mar autorisaasje is nedich om te witten wêr't se tagong ta hawwe. Istio biedt hjir ek ark foar.

As foarbyld, litte wy twa brûkersgroepen oanmeitsje (sjoch it diagram hjirûnder):

• Brûkers (brûkers) - mei tagong allinich ta SA-WebApp en SA-Frontend tsjinsten;
• Moderators (moderators) - mei tagong ta alle trije tsjinsten.

Autorisaasje konsept

Om dizze groepen te meitsjen, sille wy de Auth0 Authorization-útwreiding brûke en Istio brûke om se ferskate nivo's fan tagong te jaan.

Ynstallaasje en konfiguraasje fan Auth0 Authorization

Gean yn it Auth0-portaal nei tafoegings (Tafoegings) en ynstallearje Auth0 Autorisaasje. Nei ynstallaasje gean nei Autorisaasje Extension, en dêr - nei de konfiguraasje fan 'e hierder troch rjochtsboppe te klikken en de passende menuopsje te selektearjen (Konfiguraasje). Aktivearje groepen (Groepen) en klikje op de knop publisearje regel (Regel publisearje).

It meitsjen fan groepen

Yn Autorisaasje Extension gean nei groepen en meitsje in groep Moderators. Om't wy alle autentike brûkers sille behannelje as gewoane brûkers, is it net nedich om in ekstra groep foar har te meitsjen.

Kies in groep Moderators, Druk Leden tafoegje, foegje jo haadakkount ta. Lit guon brûkers sûnder groep litte om te soargjen dat se tagong wurde wegere. (Nije brûkers kinne manuell oanmakke wurde fia Auth0 Portal > Brûkers > Meitsje brûker.)

Foegje groepclaim ta ta tagongstoken

Brûkers binne tafoege oan groepen, mar dizze ynformaasje moat ek wjerspegele wurde yn tagongstokens. Om te foldwaan oan OpenID Connect en tagelyk de groepen werom te jaan dy't wy nedich binne, sil it token har eigen tafoegje moatte oanpaste claim. Implementearre fia Auth0 regels.

Om in regel te meitsjen, gean nei Auth0 Portal nei regels, Druk Meitsje regel en selektearje in lege regel út de sjabloanen.

Kopiearje de koade hjirûnder en bewarje it as in nije regel Add Group Claim (namespacedGroup.js):

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

remark: Dizze koade nimt de earste brûkersgroep definieare yn 'e Autorisaasjeútwreiding en foeget it ta oan it tagongstoken as in oanpaste claim (ûnder syn nammeromte, lykas fereaske troch Auth0).

Werom nei side regels en kontrolearje dat jo twa regels hawwe skreaun yn 'e folgjende folchoarder:

• auth0-autorisaasje-útwreiding
• Add Group Claim

De folchoarder is wichtich om't it groepsfjild de regel asynchronysk ûntfangt auth0-autorisaasje-útwreiding en dêrnei wurdt it tafoege as oanspraak troch de twadde regel. It resultaat is in tagongstoken lykas dit:

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

No moatte jo de Envoy-proxy ynstelle om brûkerstagong te kontrolearjen, wêrfoar de groep sil wurde lutsen fan claim (https://sa.io/group) yn it weromjûne tagongstoken. Dit is it ûnderwerp foar de folgjende seksje fan it artikel.

Autorisaasje konfiguraasje yn Istio

Foar autorisaasje om te wurkjen, moatte jo RBAC ynskeakelje foar Istio. Om dit te dwaan, sille wy de folgjende konfiguraasje brûke:

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" 

Explanations:

• 1 - RBAC allinich ynskeakelje foar tsjinsten en nammeromten neamd yn it fjild Inclusion;
• 2 - wy listje in list fan ús tsjinsten.

Litte wy de konfiguraasje tapasse mei it folgjende kommando:

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

Alle tsjinsten fereaskje no rol-basearre tagongskontrôle. Mei oare wurden, tagong ta alle tsjinsten is ferbean en sil resultearje yn in antwurd RBAC: access denied. Litte wy no tagong ta autorisearre brûkers tastean.

Tagong konfiguraasje foar reguliere brûkers

Alle brûkers moatte tagong hawwe ta de tsjinsten fan SA-Frontend en SA-WebApp. Implementearre mei de folgjende Istio-boarnen:

• ServiceRole - bepaalt de rjochten dy't de brûker hat;
• ServiceRoleBinding - bepaalt wa't dizze ServiceRole heart.

Foar gewoane brûkers sille wy tagong ta bepaalde tsjinsten tastean (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: ["*"]

En nei regular-user-binding tapasse ServiceRole op alle sidebesikers (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"

Betsjut "alle brûkers" dat net-autentikearre brûkers ek tagong krije ta de SA WebApp? Nee, it belied sil de jildichheid fan it JWT-token kontrolearje.

Litte wy de konfiguraasjes tapasse:

$ 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

Tagongskonfiguraasje foar moderators

Foar moderators wolle wy tagong ta alle tsjinsten ynskeakelje (mod-service-role.yaml):

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

Mar wy wolle sokke rjochten allinnich foar dy brûkers waans tagong token befettet claim https://sa.io/group mei de betsjutting 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" 

Litte wy de konfiguraasjes tapasse:

$ 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

Fanwege caching yn gesanten kin it in pear minuten duorje foardat de autorisaasjeregels effekt hawwe. Jo kinne dan derfoar soargje dat brûkers en moderators ferskillende nivo's fan tagong hawwe.

Konklúzje oer dit diel

Mar serieus, hawwe jo oait in ienfâldiger, sûnder muoite, skalberbere en feilige oanpak sjoen foar ferifikaasje en autorisaasje?

Allinich trije Istio-boarnen (RbacConfig, ServiceRole, en ServiceRoleBinding) wiene nedich om fynkorrelige kontrôle te berikken oer autentikaasje en autorisaasje fan tagong fan ein brûkers ta tsjinsten.

Derneist hawwe wy dizze problemen fersoarge út ús gesanttsjinsten, en berikke:

• it ferminderjen fan it bedrach fan generike koade dy't feiligensproblemen en bugs befetsje kin;
• ferminderjen fan it oantal domme situaasjes wêryn't ien einpunt fan bûten berikber blykt te wêzen en fergeat te melden;
• elimineren de needsaak om te aktualisearjen alle tsjinsten eltse kear in nije rol of rjocht wurdt tafoege;
• dat nije tsjinsten ienfâldich, feilich en fluch bliuwe.

konklúzje

Istio lit teams har boarnen rjochtsje op saaklike krityske taken sûnder overhead ta te foegjen oan tsjinsten, en weromsette se nei mikrostatus.

It artikel (yn trije dielen) levere basiskennis en klearebare praktyske ynstruksjes om te begjinnen mei Istio yn echte projekten.

PS fan oersetter

Lês ek op ús blog:

• "Werom nei mikrotsjinsten mei Istio": diel 1 (ynlieding ta de haadfunksjes), diel 2 (routing, ferkearskontrôle);
• «Conduit - lichtgewicht tsjinstmesh foar Kubernetes";
• «Wat is in tsjinstmesh en wêrom haw ik it nedich [foar in wolkapplikaasje mei mikrotsjinsten]?".

Boarne: www.habr.com