🥇Tilbage til mikroservices med Istio. Del 3

Bem. overs.: Første del af denne cyklus var dedikeret til at introducere mulighederne i Istio og demonstrere dem i aktion, den anden — fint indstillet routing og styring af netværkstrafik. Nu vil vi tale om sikkerhed: for at demonstrere de tilknyttede grundlæggende funktioner bruger forfatteren identitetstjenesten Auth0, men lignende kan andre udbydere konfigureres.

Vi har opsat et Kubernetes-klynge, hvor vi har implementeret Istio og et eksempel på mikrotjenesteapplikationen Sentiment Analysis, — så blev mulighederne i Istio demonstreret.

Ved hjælp af Istio lykkedes det os at opretholde en lille størrelse af tjenesterne, da de ikke behøver at implementere sådanne "lag", som genforbindelsesforsøg (Retries), timeouts (Timeouts), automatiske afbrydere (Circuit Breakers), sporingssystemer (Tracing), overvågning (Monitoring). Derudover anvendte vi teknikker til avanceret testning og deployment: A/B-testning, spejling og canary-udrulninger.

I det nye materiale vil vi se nærmere på de afsluttende lag på vejen til business value: autentifikation og autorisation — og i Istio er det en ren fornøjelse!

Autentifikation og autorisation i Istio

Jeg ville aldrig have troet, at jeg kunne finde inspiration i autentifikation og autorisation. Hvad kan Istio så tilbyde fra et teknologisk synspunkt for at gøre disse emner spændende og endda for at inspirere dig?

Svaret er enkelt: Istio overfører ansvaret for disse funktioner fra dine tjenester til proxyen Envoy. Når forespørgslerne når tjenesterne, er de allerede autentificeret og autoriseret, så du kan bare fokusere på at skrive nyttig forretningskode.

Lyder det godt? Lad os tage et kig indeni!

Autentifikation med Auth0

Som server til identitets- og adgangsstyring vil vi bruge Auth0, som har en gratis prøveversion, som er intuitiv at bruge og ganske enkelt tiltaler mig. Dog kan de samme principper anvendes i forhold til enhver anden implementering af OpenID Connect: KeyCloak, IdentityServer og mange andre.

For at komme i gang skal du besøge Auth0 Portal med din konto, oprette en tenant (tenant — "lejer", en logisk isolationsenhed, se nærmere i dokumentationen — red. anm.) og gå til Applications > Default App, vælg Domæne, som vist i skærmbilledet nedenfor:

Angiv dette domæne i filen resource-manifests/istio/security/auth-policy.yaml (kilde):

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

Med denne ressourcer håndterer Pilot (en af de tre primære komponenter i Control Plane i Istio — bemærk oversætterens kommentar) Envoy'er til autentificering af anmodninger, før de videresendes til tjenesterne: sa-web-app og sa-feedback. Samtidig anvendes konfigurationen ikke på tjenestens Envoy'er sa-frontend, hvilket gør det muligt for os at lade frontend'en være uautentificeret. For at anvende politikken (Policy) skal du køre kommandoen:

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

Gå tilbage til siden og lav en anmodning — du vil se, at den afsluttes med status 401 Unauthorized. Lad os nu omdirigere frontend-brugerne til autentificering med Auth0.

Autentificering af anmodninger med Auth0

For at autentificere slutbrugeranmodningerne skal du oprette et API i Auth0, som repræsenterer de autentificerede tjenester (reviews, details og ratings). For at oprette et API, gå til Auth0 Portal > APIs > Create API og udfyld formularen:

En vigtig information her er Identifier, som vi senere vil bruge i scriptet. Lad os notere det ned som:

Audience: {YOUR_AUDIENCE}

De resterende nødvendige detaljer findes på Auth0 Portal i sektionen Applications — vælg Test Application (oprettes automatisk sammen med API'et).

Her vil vi notere:

Domæne: {YOUR_DOMAIN}
Client Id: {YOUR_CLIENT_ID}

Rul ned til tekstfeltet Test Application Allowed Callback URLs (tilladte URL'er til callback), hvor vi angiver den URL, som opkaldet skal sendes til efter, at autentificeringen er afsluttet. I vores tilfælde vil det være: http://{EXTERNAL_IP}/callback

Og for

Allowed Logout URLs (tilladte URL'er for logud) tilføjer vi: http://{EXTERNAL_IP}/logout

Lad os gå videre til frontend'en.

Opdatering af frontend

Skift til branch

auth0 i repositoryet [istio-mastery] . I denne branch er frontend-koden ændret, så den omdirigerer brugerne til Auth0 for autentificering og bruger JWT-token i anmodninger til de øvrige tjenester. Det sidste implementeres på følgende måde (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)); }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));
}

For at oversætte frontend til at bruge tenant-data i Auth0, skal du åbne sa-frontend/src/services/Auth.js og erstatte værdierne, som vi har noteret tidligere (Auth.js):

const Config = {
    clientID: '{YOUR_CLIENT_ID}',
    domain:'{YOUR_DOMAIN}',
    audience: '{YOUR_AUDIENCE}',
    ingressIP: '{EXTERNAL_IP}' // Bruges til omdirigering efter autentificering
}

Applikationen er klar. Angiv dit Docker ID i nedenstående kommandoer, når du bygger og deployer de ændringer, du har foretaget:

$ 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

Prøv applikationen! Du vil blive omdirigeret til Auth0, hvor du skal logge ind (eller registrere dig), hvorefter du vil blive sendt tilbage til siden, hvor autentificerede anmodninger vil blive lavet. Hvis du prøver de befalne kommandoer med curl fra de tidligere dele af artiklen, får du koden 401 Status Code, hvilket indikerer, at anmodningen ikke er autoriseret.

Lad os tage det næste skridt – autorisere anmodningerne.

Authorization med Auth0

Autentificering gør det muligt for os at forstå, hvem brugeren er, men for at vide, hvad de har adgang til, kræves der autorisation. Istio tilbyder også værktøjer til dette.

Som et eksempel vil vi oprette to brugergrupper (se diagrammet nedenfor):

Brugere (users) – med adgang kun til tjenesterne SA-WebApp og SA-Frontend;
Moderators (moderators) – med adgang til alle tre tjenester.

Autoriseringskoncept

For at oprette disse grupper vil vi bruge Auth0 Authorization-udvidelsen og give dem forskellige adgangsniveauer ved hjælp af Istio.

Installation og konfiguration af Auth0 Authorization

Gå til Auth0-portalen og klik på udvidelser (Extensions) og installer Auth0 Authorization. Efter installationen, gå til Authorization Extension, og klik derefter på konfigurationen af tenant'en i menuen til højre og vælg den relevante mulighed (Configuration). Aktivér grupperne (Groups) og tryk på knappen for at publicere reglerne (Publish rule).

Oprettelse af grupper

Gå til Authorization Extension og vælg Groups og opret gruppen Moderators. Da vi betragter alle autentificerede brugere som almindelige, er der ikke behov for at oprette en ekstra gruppe for dem.

Vælg gruppen Moderators, klik på Add Members, tilføj din primære konto. Lad nogle brugere være uden nogen gruppe for at sikre, at adgangen for dem er blokeret. (Nye brugere kan oprettes manuelt gennem Auth0 Portal > Brugere > Opret bruger.)

Tilføj Group Claim i Access Token

Brugere er blevet tilføjet til grupper, men denne information skal også være afspejlet i adgangstokens. For at overholde OpenID Connect og samtidig returnere de grupper, vi har brug for, skal tokenet tilføje sin custom claim. Implementeres via Auth0 regler.

For at oprette en regel, gå til Auth0 Portal til Regler, klik på Opret regel og vælg en tom regel fra skabelonerne.

Kopier koden nedenfor, og gem den som en ny regel Add Group Claim (namespacedGroup.js):

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

Bemærk: denne kode tager den første gruppe af brugeren, som er defineret i Authorization Extension, og tilføjer den til access-tokenet som en custom claim (under sit eget navneområde, som krævet af Auth0).

Gå tilbage til siden Regler og kontroller, at du har to regler, der er skrevet i følgende rækkefølge:

auth0-authorization-extension
Add Group Claim

Rækkefølgen er vigtig, fordi gruppefeltet asynkront modtager reglen auth0-authorization-extension og derefter tilføjes som claim af den anden regel. Resultatet bliver et sådant access-token:

{
 "https://sa.io/group": "Moderators",
 "iss": "https://sentiment-analysis.eu.auth0.com/",
 "sub": "google-oauth2|196405271625531691872"
 // [forkortet for klarhed]
}

Nu skal Envoy-proxien konfigureres til at kontrollere brugeradgang, hvor gruppen vil blive udtrukket fra claim (https://sa.io/group) i det returnerede access-token. Dette er emnet for næste afsnit i artiklen.

Authorization Configuration in Istio

For at autorisering kan fungere, skal RBAC aktiveres for Istio. Vi vil bruge følgende konfiguration:

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"

Forklaringer:

1 — aktiverer RBAC kun for de tjenester og navneområder, der er nævnt i feltet Inclusion;
2 — angiver listen over vores tjenester.

Anvend konfigurationen med følgende kommando:

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

Nu kræver alle tjenester adgangskontrol baseret på roller (Role-Based Access Control). Med andre ord er adgangen til alle tjenester blokeret og vil resultere i svaret RBAC: adgang nægtet. Nu giver vi adgang til autoriserede brugere.

Adgangskonfiguration for almindelige brugere

Alle brugere skal have adgang til service SA-Frontend og SA-WebApp. Dette implementeres ved hjælp af følgende Istio-ressourcer:

ServiceRole — definerer de rettigheder, som brugeren har;
ServiceRoleBinding — definerer, hvem denne ServiceRole gælder for.

For almindelige brugere giver vi adgang til bestemte tjenester (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: ["*"]

Og gennem regular-user-binding anvender vi ServiceRole til alle besøgende på siden (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"

Betyder "alle brugere", at også ikke-autentificerede brugere får adgang til SA WebApp? Nej, politikken vil kontrollere gyldigheden af JWT-tokenet.

Vi anvender konfigurationer:

$ 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

Adgangskonfiguration for moderatorer

For moderatorer ønsker vi at inkludere adgang til alle tjenester (mod-service-role.yaml):

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

Men vi ønsker disse rettigheder kun for de brugere, hvis access-token har en claim https://sa.io/group med værdien 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"

Vi anvender konfigurationer:

$ 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

På grund af caching i envoy'erne kan det tage et par minutter, før autorisationsreglerne træder i kraft. Derefter kan du sikre dig, at brugere og moderatorer har forskellige adgangsniveauer.

Konklusion i denne del

Seriøst: har du set en mere simpel, problemfri, skalerbar og sikker tilgang til autentifikation og autorisation noget sted?

Det krævede blot tre Istio-ressourcer (RbacConfig, ServiceRole og ServiceRoleBinding) for at opnå fin kontrol over autentifikation og autorisation af slutbrugeres adgang til tjenester.

Derudover har vi taget hånd om disse problemer fra vores tjenester til envoy'er, og opnået:

en reduktion af mængden af generisk kode, som kan indeholde sikkerhedsproblemer og fejl;
en reduktion af dumme situationer, hvor en endpoint var tilgængelig udefra og glemte at rapportere det;
en eliminering af behovet for at opdatere alle tjenester ved hver tilføjelse af en ny rolle eller rettighed;
at nye tjenester forbliver enkle, sikre og hurtige.

Output

Istio giver teams mulighed for at fokusere deres ressourcer på forretningskritiske opgaver uden at pålægge overhead på tjenesterne, hvilket bringer dem tilbage til status som "mikro."

Artiklen (i tre dele) gav grundlæggende viden og en klar praktisk vejledning til at komme i gang med Istio i virkelige projekter.