🥇Terug naar microservices met Istio. Deel 3

Opmerking. vert.: Het eerste deel deze serie was gewijd aan het leren kennen van de mogelijkheden van Istio en het demonstreren ervan in actie, tweede — nauwkeurig afgestemde routering en netwerkverkeersbeheer. Nu zullen we het hebben over beveiliging: om de basisfuncties die ermee verband houden te demonstreren, gebruikt de auteur de identiteitsservice Auth0, maar andere providers kunnen op een vergelijkbare manier worden geconfigureerd.

We hebben een Kubernetes-cluster opgezet waarin we Istio en een voorbeeld van een microservice-applicatie, Sentiment Analysis, hebben geïmplementeerd om de mogelijkheden van Istio te demonstreren.

Met Istio konden we onze services klein houden omdat ze geen lagen zoals nieuwe pogingen, time-outs, stroomonderbrekers, tracering en monitoring hoeven te implementeren. Daarnaast hebben we gebruik gemaakt van geavanceerde test- en implementatietechnieken: A/B-testen, mirroring en canary rollouts.

In het nieuwe materiaal behandelen we de laatste lagen op het pad naar zakelijke waarde: authenticatie en autorisatie - en in Istio is het een waar genoegen!

Authenticatie en autorisatie in Istio

Ik had nooit geloofd dat ik geïnspireerd zou worden door authenticatie en autorisatie. Wat kan Istio vanuit technologisch perspectief bieden om deze onderwerpen leuk en vooral inspirerend voor je te maken?

Het antwoord is simpel: Istio verschuift de verantwoordelijkheid voor deze mogelijkheden van uw services naar de Envoy-proxy. Tegen de tijd dat de verzoeken de services bereiken, zijn ze al geverifieerd en geautoriseerd, dus het enige dat u hoeft te doen is bedrijfscode schrijven.

Klinkt goed? Laten we eens binnen kijken!

Authenticatie met Auth0

Als server voor identiteits- en toegangsbeheer zullen we Auth0 gebruiken, die een proefversie heeft, intuïtief te gebruiken is en ik vind het gewoon leuk. Dezelfde principes kunnen echter op elk ander worden toegepast OpenID Connect-implementaties: KeyCloak, IdentityServer en vele anderen.

Ga naar om aan de slag te gaan Auth0-portaal Maak met uw account een tenant aan (tenant - “tenant”, logische isolatie-eenheid, zie voor meer details documentatie — ca. vert.) en ga naar Applicaties > Standaardappkiezen Domein, zoals weergegeven in de onderstaande schermafbeelding:

Geef dit domein op in het bestand 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 zo'n hulpbron, Pilot (een van de drie basiscomponenten van Control Plane in Istio - ca. vert.) configureert Envoy om verzoeken te verifiëren voordat deze naar services worden doorgestuurd: sa-web-app и sa-feedback. Tegelijkertijd wordt de configuratie niet toegepast op service Envoys sa-frontend, waardoor we de frontend niet-geverifieerd kunnen laten. Om het beleid toe te passen, voert u de opdracht uit:

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

Keer terug naar de pagina en doe een verzoek - u zult zien dat het eindigt met de status 401 ongeautoriseerd. Laten we nu frontend-gebruikers omleiden om te authenticeren met Auth0.

Verzoeken verifiëren met Auth0

Om verzoeken van eindgebruikers te authenticeren, moet u in Auth0 een API maken die de geverifieerde services vertegenwoordigt (recensies, details en beoordelingen). Ga naar om een API te maken Auth0 Portal > API's > API maken en vul het formulier in:

De belangrijke informatie hier is Identifier, die we later in het script zullen gebruiken. Laten we het als volgt opschrijven:

Toehoorders: {YOUR_AUDIENCE}

De overige gegevens die we nodig hebben, bevinden zich op de Auth0 Portal in de sectie Toepassingen - selecteren Testtoepassing (automatisch gemaakt samen met de API).

Hier zullen we schrijven:

Domein: {YOUR_DOMAIN}
Klant identificatie: {YOUR_CLIENT_ID}

Scroll naar Testtoepassing naar tekstveld Toegestane callback-URL's (opgeloste URL's voor de callback), waarin we de URL specificeren waar de oproep naartoe moet worden gestuurd nadat de authenticatie is voltooid. In ons geval is het:

http://{EXTERNAL_IP}/callback

En voor Toegestane uitlog-URL's (toegestane URL's voor uitloggen) toevoegen:

http://{EXTERNAL_IP}/logout

Laten we verder gaan naar de frontend.

Frontend-update

Schakel over naar filiaal auth0 opslagplaats [istio-mastery]. In deze vertakking wordt de frontendcode gewijzigd om gebruikers om te leiden naar Auth0 voor authenticatie en om het JWT-token te gebruiken in verzoeken aan andere services. Dit laatste wordt als volgt geïmplementeerd (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));
}

Als u de frontend wilt wijzigen om tenantgegevens in Auth0 te gebruiken, opent u sa-frontend/src/services/Auth.js en vervang daarin de waarden die we hierboven schreven (Auth.js):

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

De applicatie is klaar. Geef uw Docker-ID op in de onderstaande opdrachten bij het bouwen en implementeren van de aangebrachte wijzigingen:

$ 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 de app! U wordt doorgestuurd naar Auth0, waar u dient in te loggen (of te registreren), waarna u teruggestuurd wordt naar de pagina van waaruit reeds geauthenticeerde verzoeken worden gedaan. Als u de opdrachten uit de eerste delen van het artikel met curl probeert, krijgt u de code 401 Statuscode, wat aangeeft dat het verzoek niet is geautoriseerd.

Laten we de volgende stap zetten: verzoeken autoriseren.

Autorisatie met Auth0

Authenticatie stelt ons in staat te begrijpen wie een gebruiker is, maar autorisatie is vereist om te weten waartoe deze toegang heeft. Ook hiervoor biedt Istio tools.

Laten we als voorbeeld twee gebruikersgroepen maken (zie het onderstaande diagram):

Leden (gebruikers) — met alleen toegang tot SA-WebApp- en SA-Frontend-services;
moderatoren (moderators) — met toegang tot alle drie de diensten.

Autorisatieconcept

Om deze groepen te maken, gebruiken we de Auth0 Authorization-extensie en gebruiken we Istio om ze verschillende toegangsniveaus te bieden.

Installatie en configuratie van Auth0-autorisatie

Ga in de Auth0-portal naar extensies (uitbreidingen) en installeer Auth0-autorisatie. Ga na de installatie naar Autorisatie-uitbreiding, en daar - naar de configuratie van de huurder door rechtsboven te klikken en de juiste menuoptie te selecteren (Configuratie). Activeer groepen (Groepen) en klik op de knop Publiceerregel (Publicatieregel).

Groepen maken

Ga in Autorisatie-uitbreiding naar Groepen en maak een groep moderators. Omdat we alle geauthenticeerde gebruikers als gewone gebruikers behandelen, is het niet nodig om een extra groep voor hen aan te maken.

Kies een groep moderators, hoe dan ook Voeg leden toe, voeg uw hoofdaccount toe. Laat sommige gebruikers zonder groep achter om er zeker van te zijn dat hen de toegang wordt geweigerd. (Nieuwe gebruikers kunnen handmatig worden aangemaakt via Auth0 Portal > Gebruikers > Gebruiker aanmaken.)

Groepsclaim toevoegen aan toegangstoken

Er zijn gebruikers toegevoegd aan groepen, maar deze informatie moet ook tot uiting komen in toegangstokens. Om te voldoen aan OpenID Connect en tegelijkertijd de groepen terug te geven die we nodig hebben, zal het token zijn eigen token moeten toevoegen aangepaste claim. Geïmplementeerd via Auth0-regels.

Om een regel aan te maken, gaat u naar Auth0 Portal naar Reglement, hoe dan ook Creëer regel en selecteer een lege regel uit de sjablonen.

Kopieer de onderstaande code en sla deze op als een nieuwe regel Groepsclaim toevoegen (naamruimtegroep.js):

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

Noot: Deze code neemt de eerste gebruikersgroep die is gedefinieerd in de Autorisatie-extensie en voegt deze toe aan het toegangstoken als een aangepaste claim (onder de naamruimte, zoals vereist door Auth0).

Terug naar pagina Reglement en controleer of u twee regels in de volgende volgorde hebt geschreven:

auth0-autorisatie-extensie
Groepsclaim toevoegen

De volgorde is belangrijk omdat het groepsveld de regel asynchroon ontvangt auth0-autorisatie-extensie en daarna wordt het door de tweede regel als claim toegevoegd. Het resultaat is een toegangstoken zoals dit:

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

Nu moet u de Envoy-proxy configureren om de gebruikerstoegang te controleren, waarvoor de groep uit de claim wordt gehaald (https://sa.io/group) in het geretourneerde toegangstoken. Dit is het onderwerp voor het volgende deel van het artikel.

Autorisatieconfiguratie in Istio

Om autorisatie te laten werken, moet u RBAC voor Istio inschakelen. Om dit te doen, zullen we de volgende configuratie gebruiken:

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"

Toelichting:

1: schakel RBAC alleen in voor services en naamruimten die in het veld worden vermeld Inclusion;
2 — we vermelden een lijst van onze diensten.

Laten we de configuratie toepassen met de volgende opdracht:

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

Alle services vereisen nu op rollen gebaseerd toegangscontrole. Met andere woorden: toegang tot alle diensten is verboden en zal resulteren in een reactie RBAC: access denied. Laten we nu toegang verlenen aan geautoriseerde gebruikers.

Toegangsconfiguratie voor gewone gebruikers

Alle gebruikers moeten toegang hebben tot de SA-Frontend- en SA-WebApp-services. Geïmplementeerd met behulp van de volgende Istio-bronnen:

ServiceRol — bepaalt de rechten die de gebruiker heeft;
ServiceRoleBinding — bepaalt van wie deze ServiceRole is.

Voor gewone gebruikers verlenen we toegang tot bepaalde diensten (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 daarna regular-user-binding ServiceRole toepassen op alle paginabezoekers (reguliere-gebruikersservice-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"

Betekent "alle gebruikers" dat niet-geverifieerde gebruikers ook toegang hebben tot de SA WebApp? Nee, het beleid controleert de geldigheid van het JWT-token.

Laten we de configuraties toepassen:

$ 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

Toegangsconfiguratie voor moderators

Voor moderators willen we toegang tot alle services mogelijk maken (mod-service-rol.yaml):

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

Maar we willen dergelijke rechten alleen voor die gebruikers wier toegangstoken een claim bevat https://sa.io/group met betekenis Moderators (mod-service-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"

Laten we de configuraties toepassen:

$ 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

Vanwege het cachen van gezanten kan het enkele minuten duren voordat de autorisatieregels van kracht worden. U kunt er vervolgens voor zorgen dat gebruikers en moderators verschillende toegangsniveaus hebben.

Conclusie op dit onderdeel

Maar even serieus: heb je ooit een eenvoudiger, moeiteloze, schaalbare en veilige benadering van authenticatie en autorisatie gezien?

Er waren slechts drie Istio-bronnen (RbacConfig, ServiceRole en ServiceRoleBinding) nodig om een fijnmazige controle te realiseren over de authenticatie en autorisatie van de toegang van eindgebruikers tot services.

Daarnaast hebben we deze kwesties afgehandeld vanuit onze gezantdiensten, waardoor we het volgende hebben bereikt:

het verminderen van de hoeveelheid generieke code die beveiligingsproblemen en bugs kan bevatten;
het terugdringen van het aantal domme situaties waarin één eindpunt van buitenaf toegankelijk bleek te zijn en vergat dit te melden;
het elimineren van de noodzaak om alle services bij te werken telkens wanneer een nieuwe rol of recht wordt toegevoegd;
dat nieuwe diensten eenvoudig, veilig en snel blijven.

Uitgang

Met Istio kunnen teams hun middelen richten op bedrijfskritische taken zonder extra overhead aan services toe te voegen, waardoor deze teruggaan naar een microstatus.

Het artikel (in drie delen) bood basiskennis en kant-en-klare praktische instructies om in echte projecten met Istio aan de slag te gaan.

Terug naar microservices met Istio. Deel 3