🥇Terug na mikrodienste met Istio. Deel 3

Let wel. vertaal.: Eerste deel hierdie reeks was gewy om die vermoëns van Istio te leer ken en dit in aksie te demonstreer, 2 - fyn ingestelde roetering en netwerkverkeerbestuur. Nou sal ons praat oor sekuriteit: om die basiese funksies wat daarmee verband hou, te demonstreer, gebruik die skrywer die Auth0-identiteitsdiens, maar ander verskaffers kan op 'n soortgelyke manier gekonfigureer word.

Ons het 'n Kubernetes-kluster opgestel waarin ons Istio en 'n voorbeeld-mikrodienstoepassing, Sentiment Analysis, ontplooi het om Istio se vermoëns te demonstreer.

Met Istio kon ons ons dienste klein hou omdat hulle nie lae soos Herproberings, Timeouts, Circuit Breakers, Tracing, Monitering hoef te implementeer nie. . Daarbenewens het ons gevorderde toets- en ontplooiingstegnieke gebruik: A/B-toetsing, spieëlbeeld en kanarie-ontplooiing.

In die nuwe materiaal sal ons die laaste lae op die pad na besigheidswaarde hanteer: verifikasie en magtiging - en in Istio is dit 'n ware plesier!

Stawing en magtiging in Istio

Ek sou nooit geglo het dat ek deur verifikasie en magtiging geïnspireer sou word nie. Wat kan Istio vanuit 'n tegnologiese perspektief bied om hierdie onderwerpe vir jou pret en, nog meer, inspirerend te maak?

Die antwoord is eenvoudig: Istio verskuif verantwoordelikheid vir hierdie vermoëns van jou dienste na die Gesant-gevolmagtigde. Teen die tyd dat die versoeke die dienste bereik, is hulle reeds geverifieer en gemagtig, dus al wat jy hoef te doen is om besigheidsnuttige kode te skryf.

Klink goed? Kom ons kyk na binne!

Verifikasie met Auth0

As 'n bediener vir identiteits- en toegangsbestuur, sal ons Auth0 gebruik, wat 'n proefweergawe het, intuïtief is om te gebruik en ek hou eenvoudig daarvan. Dieselfde beginsels kan egter op enige ander toegepas word OpenID Connect implementerings: KeyCloak, IdentityServer en vele ander.

Om te begin, gaan na Auth0-portaal met jou rekening, skep 'n huurder (huurder - "huurder", logiese eenheid van isolasie, sien vir meer besonderhede dokumentasie - ongeveer. vertaal.) en gaan na Toepassings > Standaardtoepassingkies Domainsoos in die skermkiekie hieronder getoon:

Spesifiseer hierdie domein in die lêer resource-manifests/istio/security/auth-policy.yaml (bron):

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

Met so 'n hulpbron, Pilot (een van die drie basiese beheervlakkomponente in Istio - ongeveer transl.) stel Envoy op om versoeke te staaf voordat dit na dienste gestuur word: sa-web-app и sa-feedback. Terselfdertyd word die konfigurasie nie op diensgesante toegepas nie sa-frontend, wat ons toelaat om die voorkant ongewaarmerk te laat. Om die beleid toe te pas, voer die opdrag uit:

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

Gaan terug na die bladsy en rig 'n versoek - jy sal sien dat dit eindig met die status 401 Ongemagtigde. Laat ons nou frontend-gebruikers herlei om met Auth0 te verifieer.

Bevestig versoeke met Auth0

Om eindgebruikerversoeke te staaf, moet jy 'n API in Auth0 skep wat die geverifieerde dienste (resensies, besonderhede en graderings) sal verteenwoordig. Om 'n API te skep, gaan na Auth0-portaal > API's > Skep API en vul die vorm in:

Die belangrike inligting hier is identifiseer, wat ons later in die skrif sal gebruik. Kom ons skryf dit so neer:

Gehoor: {YOUR_AUDIENCE}

Die oorblywende besonderhede wat ons benodig, is op die Auth0-portaal in die afdeling geleë aansoeke — kies Toets Toepassing (outomaties geskep saam met die API).

Hier sal ons skryf:

Domain: {YOUR_DOMAIN}
Kliënt-ID: {YOUR_CLIENT_ID}

Blaai na Toets Toepassing na teksveld Toegelate terugbel-URL'e (opgeloste URL's vir die terugbel), waarin ons die URL spesifiseer waarheen die oproep gestuur moet word nadat verifikasie voltooi is. In ons geval is dit:

http://{EXTERNAL_IP}/callback

En vir Toegelate afmeld-URL'e (toegelate URL's om uit te meld) voeg by:

http://{EXTERNAL_IP}/logout

Kom ons gaan aan na die voorkant.

Frontend-opdatering

Skakel oor na tak auth0 bewaarplek [istio-mastery]. In hierdie tak word die frontend-kode verander om gebruikers na Auth0 te herlei vir stawing en die JWT-token te gebruik in versoeke na ander dienste. Laasgenoemde word soos volg geïmplementeer (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 die frontend te verander om huurderdata in Auth0 te gebruik, maak oop sa-frontend/src/services/Auth.js en vervang daarin die waardes wat ons hierbo geskryf het (Auth.js):

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

Die aansoek is gereed. Spesifiseer jou Docker ID in die opdragte hieronder wanneer jy die veranderinge wat gemaak is bou en ontplooi:

$ 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

Probeer die toepassing! Jy sal herlei word na Auth0, waar jy moet aanmeld (of registreer), waarna jy teruggestuur sal word na die bladsy vanwaar reeds geverifieerde versoeke gemaak sal word. As jy die opdragte wat in die eerste dele van die artikel genoem word met krul probeer, sal jy die kode kry 401 Status Kode, wat aandui dat die versoek nie gemagtig is nie.

Kom ons neem die volgende stap – magtig versoeke.

Magtiging met Auth0

Stawing laat ons toe om te verstaan wie 'n gebruiker is, maar magtiging is nodig om te weet waartoe hulle toegang het. Istio bied ook gereedskap hiervoor.

As voorbeeld, kom ons skep twee gebruikersgroepe (sien die diagram hieronder):

Lede (gebruikers) — met slegs toegang tot SA-WebApp en SA-Frontend-dienste;
Moderators (moderators) — met toegang tot al drie dienste.

Magtiging konsep

Om hierdie groepe te skep, sal ons die Auth0 Authorization-uitbreiding gebruik en Istio gebruik om hulle van verskillende vlakke van toegang te voorsien.

Installasie en konfigurasie van Auth0 Authorization

In die Auth0-portaal, gaan na uitbreidings (Uitbreidings) en installeer Auth0 Magtiging. Na die installasie, gaan na Magtigingsuitbreiding, en daar - na die huurder se konfigurasie deur regs bo te klik en die toepaslike kieslysopsie te kies (Konfigurasie). Aktiveer groepe (Groepe) en klik op die publiseer reël-knoppie (Publiseer reël).

Skep groepe

Gaan in Magtigingsuitbreiding na groepe en skep 'n groep moderators. Aangesien ons alle geverifieerde gebruikers as gereelde gebruikers sal behandel, is dit nie nodig om 'n bykomende groep vir hulle te skep nie.

Kies 'n groep moderators, Druk Voeg lede by, voeg jou hoofrekening by. Laat sommige gebruikers sonder enige groep om seker te maak dat hulle toegang geweier word. (Nuwe gebruikers kan met die hand geskep word via Auth0-portaal > Gebruikers > Skep gebruiker.)

Voeg groepeis by toegangsteken

Gebruikers is by groepe gevoeg, maar hierdie inligting moet ook in toegangstekens weerspieël word. Om aan OpenID Connect te voldoen en terselfdertyd die groepe wat ons benodig terug te stuur, sal die token sy eie moet byvoeg persoonlike eis. Geïmplementeer deur Auth0-reëls.

Om 'n reël te skep, gaan na Auth0 Portal na Reëls, Druk Skep Reël en kies 'n leë reël uit die sjablone.

Kopieer die kode hieronder en stoor dit as 'n nuwe reël Voeg groepeis by (namespacedGroup.js):

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

Let daarop: Hierdie kode neem die eerste gebruikergroep wat in die magtigingsuitbreiding gedefinieer is en voeg dit by die toegangstoken as 'n pasgemaakte eis (onder sy naamspasie, soos vereis deur Auth0).

Keer terug na bladsy Reëls en maak seker dat jy twee reëls in die volgende volgorde geskryf het:

auth0-magtiging-uitbreiding
Voeg groepeis by

Die volgorde is belangrik omdat die groepveld die reël asynchronies ontvang auth0-magtiging-uitbreiding en daarna word dit as 'n eis bygevoeg deur die tweede reël. Die resultaat is 'n toegangsteken soos hierdie:

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

Nou moet jy die Gesant-instaanbediener opstel om gebruikerstoegang na te gaan, waarvoor die groep van eis getrek sal word (https://sa.io/group) in die teruggekeerde toegangsteken. Dit is die onderwerp vir die volgende afdeling van die artikel.

Magtiging konfigurasie in Istio

Vir magtiging om te werk, moet jy RBAC vir Istio aktiveer. Om dit te doen, sal ons die volgende konfigurasie gebruik:

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"

Verduidelikings:

1 — aktiveer RBAC slegs vir dienste en naamruimtes wat in die veld gelys word Inclusion;
2 — ons lys 'n lys van ons dienste.

Kom ons pas die konfigurasie toe met die volgende opdrag:

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

Alle dienste vereis nou rolgebaseerde toegangsbeheer. Met ander woorde, toegang tot alle dienste is verbode en sal 'n reaksie tot gevolg hê RBAC: access denied. Laat ons nou toegang tot gemagtigde gebruikers toelaat.

Toegang tot konfigurasie vir gereelde gebruikers

Alle gebruikers moet toegang hê tot die SA-Frontend- en SA-WebApp-dienste. Geïmplementeer met behulp van die volgende Istio-hulpbronne:

Diensrol - bepaal die regte wat die gebruiker het;
DiensRolbinding — bepaal aan wie hierdie Diensrol behoort.

Vir gewone gebruikers sal ons toegang tot sekere dienste toelaat (diensrol.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 deur regular-user-binding pas Diensrol toe op alle bladsybesoekers (gereelde-gebruiker-diens-rolbinding.yaml):

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRoleBinding
metadata:
  name: regular-user-binding
  namespace: default
spec:
  subjects:
  - user: "*"
  roleRef:
    kind: ServiceRole
    name: "regular-user"

Beteken "alle gebruikers" dat ongeverifieerde gebruikers ook toegang tot die SA WebApp sal hê? Nee, die beleid sal die geldigheid van die JWT-token nagaan.

Kom ons pas die konfigurasies toe:

$ 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

Toegang opset vir moderators

Vir moderators wil ons toegang tot alle dienste (mod-diens-rol.yaml):

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

Maar ons wil sulke regte net hê vir die gebruikers wie se toegangsteken eis bevat https://sa.io/group met betekenis Moderators (mod-diens-rolbinding.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"

Kom ons pas die konfigurasies toe:

$ 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

As gevolg van die kas in gesante, kan dit 'n paar minute neem vir magtigingsreëls om in werking te tree. Jy kan dan verseker dat gebruikers en moderators verskillende vlakke van toegang het.

Gevolgtrekking oor hierdie deel

Maar ernstig, het jy al ooit 'n eenvoudiger, moeitelose, skaalbare en veilige benadering tot verifikasie en magtiging gesien?

Slegs drie Istio-hulpbronne (RbacConfig, ServiceRole en ServiceRoleBinding) was nodig om fyn beheer oor verifikasie en magtiging van eindgebruikerstoegang tot dienste te verkry.

Daarbenewens het ons hierdie kwessies uit ons gesantdienste versorg en bereik:

die vermindering van die hoeveelheid generiese kode wat sekuriteitsprobleme en foute kan bevat;
die vermindering van die aantal dom situasies waarin een eindpunt van buite toeganklik blyk te wees en vergeet het om dit aan te meld;
uitskakeling van die behoefte om alle dienste op te dateer elke keer wanneer 'n nuwe rol of reg bygevoeg word;
dat nuwe dienste eenvoudig, veilig en vinnig bly.

Output

Istio laat spanne toe om hul hulpbronne op besigheidskritiese take te fokus sonder om bokoste by dienste te voeg, en dit terug te keer na mikrostatus.

Die artikel (in drie dele) het basiese kennis en klaargemaakte praktiese instruksies verskaf om met Istio in werklike projekte te begin.

Terug na mikrodienste met Istio. Deel 3