5 Steps To Integrate Istio With OPA

Authenticatie en autorisatie zijn grote delen van het veiligheidspuzzel dat door cloud architecten en DevOps-engineers moet worden opgelost. In deze blog zullen we specifiek kijken hoe we autorisatie/toegangsbeheer behalen; d.w.z., welke acties de geauthenticateerde entiteit kan uitvoeren in de Istio-service-mesh. Het helpt de infrastructuur te beveiligen door acties met kwaadwillige intenties te voorkomen.

Autorisatie in een service mesh kan worden gedefinieerd met behulp van OPA-beleid. OPA is een mechanisme dat DevOps-mensen helpt om autorisatiesregels voor Kubernetes-workloads te definiëren en te handhaven. In dit stuk zullen we zien:

• Wat OPA is
• Waarom je OPA moet integreren met de Istio-service mesh
• Hoe Istio en OPA verzoeken autoriseren
• De exacte stappen die u kunt volgen om OPA te integreren met Istio

Wat Is OPA?

OPA (kort voor “Open Policy Agent”) is een open-source algemene doelmatige beleidsenforcementengine die laat DevOps beleid definiëren als code met behulp van een hoog niveau declaratieve taal genaamd Rego. OPA helpt centraal beleid te definiëren en toe te passen over de gehele stack terwijl ontwikkelaars vrijstellen van het schrijven van autorisatiesregels in het toepassingscode. Hier is hoe OPA werkt (zie afbeelding 1):

1. De applicatie/dienst ontvangt een verzoek.
2. De dienst stuurt een JSON-autorisatieverzoek naar OPA.
3. OPA controleert het verzoek aan de hand van de gedefinieerde autorisatiebeleidsen.
4. OPA neemt de beslissing en stuurt de autorisatiereactie (ALLOW/DENY) terug naar de dienst in JSON-formaat.

Afbeelding 1: Autorisatieverzoekstroom met OPA

Merk op dat het niet noodzakelijk is dat een door een ontwikkelaar geschreven toepassing de autorisatieverzoeken verzendt: het kan Argo CD, een Kubernetes Gateway API-bron, Terraform, Prometheus of iets anders zijn, omdat OPA een alomvattend doel heeft. (Ik heb hier een toepassing in een Kubernetes-cluster genoemd en getekend voor de gemak en een beter begrip.)

Waarom OPA integreren met Istio?

Istio beschikt over een robuust autorisatiesysteem. Echter, het hebben van een speciaal policy-enforcement engine zoals OPA naast de Istio service mesh heeft zijn eigen voordelen:

• Centralesysteem voor het definiëren en handhaven van politieken: OPA maakt het gemakkelijker voor DevOps om autorisatiepolitieken voor de gehele stack centraal te beheren. Dit omvat gemeshde taken, niet-gemeshde stacks en ook autorisatiecontroles (bijvoorbeeld een politiek die voorkomt dat deployments op vrijdag plaatsvinden). 
• Meer flexibiliteit en granulariteit bij het definiëren van politieken: Als u naar de onderstaande tabel (Afbeelding 2) kijk, is het duidelijk dat Istio-autorisatie veel kan en een verzoek aanstuurt op basis van een verscheidenheid van velden uit verschillende gegevensbronnen kan matchen. Echter, de Istio AuthorizationPolicy CRD kan beperkt zijn in het configureren van de HTTP-verzoekenbod of contextuele gegevens in de velden, waarvoor OPA gebruikt kan worden. In tegenstelling tot Istio kan OPA voor de policy-evaluatie gebruik maken van elke gegevens.
• Gemakkelijkere AuthZ-configuratie: Het kan lastig zijn voor DevOps om complexe autorisatierules in Istio te configureren. OPA wordt geconfigureerd met Rego, wat dicht bij een programmeertaal is. Het is relatief gemakkelijker om basis- tot complexe policy-regels met Rego in te stellen.

Figuur 2: Tabelaire vergelijking tussen Istio en OPA-autorisatie (bron)

Hoe Istio en OPA verzoeken autoriseren

DevOps kunnen OPA als aparte dienst uitvoeren of als sidecar-container naast de Envoy proxy en de toepassingscontainer in een pod. Het sidecar-container-aanpak is beter voor het verminderen van de latency.

OPA sidecar-containers moeten worden ingevoegd in de toepassingspod net zoals Istio’s Envoy proxy sidecar-containers. We kunnen de ingevoerde OPA containers instellen om ConfigMaps te monteren die de autorisatieregels bevatten; elke OPA sidecar-container in het namespace zal dan dezelfde configuratie en AuthZ-regels die zijn gedefinieerd in de ConfigMap monteren.

Zodra de OPA sidecar is ingevoerd, zal de Envoy proxy autorisatieverzoeken naar OPA sturen om autorisatiedecisionen te nemen wanneer de service een verzoek ontvangt:

Figuur 3: Istio-OPA autorisatiewerk流程

Stel dat de DevOps-medewerkers niet willen dat elke ingevoerde OPA container in hetzelfde namespace dezelfde configuraties volgt en verschillende regels willen afdwingen. In dat geval moeten ze een van de volgende handelingen uitvoeren:

• Verwijderen van hard-coding dat de huidige injectiebeleid een bepaalde ConfigMap gebruikt
• Configureer mutating webhook en schakel sidecar-injectie uit op pod-niveau
• Policijelijke bundels vanaf een externe HTTP-server opvragen
• De toepassing en de sidecars in een andere namespace deployen met verschillende ConfigMap

Stappen om Opa met Istio te integreren: Demo

Het idee hier is om OPA de externe autorisator te maken in plaats van de Envoy proxy sidecars — om toegangsregelings beslissingen uit te voeren.

Ik zal de klassieke Bookinfo-toepassing gebruiken uit de Istio-documentatie voor de demo. Ik zal OPA configureren met Istio voor toegangsbeheer en controleren of het wordt gehandhaafd door verzoeken te sturen naar bookinfo/productpage:

Afbeelding 4: Diagram van Istio-OPA-integratie handleiding

Noteer dat /productpage de UI is, die interne aanroepen maakt naar andere services, zoals review- en waarderingdiensten (diagram). Ik zal OPA injecteren in elke pod in de bookinfo-namespace; alle OPA-containers monteren dezelfde ConfigMap en hebben daardoor dezelfde toegangsbeheer politieken. Het standaardgedrag van de Bookinfo-toepassing stuurt geen HTTP-authenticatie door, dus de interne aanroepen zullen authenticatie en daarmee toegangsbeheer mislukken.

We zullen de gegeven stappen volgen in volgorde:

1. Configureer OPA sidecar-injectie
2. Maak communicatie mogelijk tussen Istio-proxy en OPA
3. Deploy OPA-configuratie
4. Pas Istio-configuratie toe
5. Deploy de applicatie en test het Istio-OPA autorisatiesetup

De voorvereiste voor de demo is om Istio v1.19+ geïnstalleerd te hebben in uw cluster. Ik gebruik hier Istio v1.21.0.

OPA biedt een quickstart.yaml voor gemakkelijke installatie. Ik heb de yaml in drieën opgesplitst voor een beter begrip: IMESH GitHub-repo. 

Stap 1: Configureer OPA Sidecar Injectie

Pas het opa_controller.yaml toe:

kubectl apply -f opa_controller.yaml

Het opa_controller.yaml deploieert alles — TLS-certificaten, ConfigMap met injectiebeleid, dePLOYMENT van de toelatingcontroller, en configuratie van het muterende webhook — in de opa-istio-namespace (zie figuur 5):

1. De muterende webhookcontroller (opa-istio-admission-controller) zal dan luisteren naar een bepaalde label (opa-istio-injection) met de waarde ingesteld op enabled.
2. De webhook controller roept de admission-controller aan, die de injectiebeleid heeft.
3. Het injectiebeleid vertelt de admission-controller hoe de OPA sidecar container moet worden ingevoegd in de pod.

Afbeelding 5: OPA sidecar injectie configuratie

Nu, voordat we de Bookinfo applicatie deployen, zullen we een bookinfo namespace aanmaken en de resterende stappen volgen:

Maak de bookinfo namespace aan door bookinfo-ns.yaml toe te passen:

kubectl apply -f bookinfo-ns.yaml

Stap 2: Schakel communicatie tussen Istio Proxy en OPA in

Bewerk de Istio ConfigMap in het istio-system namespace en voeg extensionProviders (opa-ext-authz-grpc) toe, zodat externe autorisatie in het mesh wordt ingeschakeld:

• Kopieer extensionProviders uit de commentaarregel in opa_controller.yaml.
• Bewerk de Istio ConfigMap en voeg extensionProviders toe in het veld van het mesh.
• Zorg ervoor dat de indentatie correct is.
• Sla de configuratie op.

Deze stap maakt het mogelijk voor istio-proxy om met de opa-istio container in de pod te communiceren voor autorisatieverzoeken.

Als u naar de extensionProviders kijkt, is het een ExtAuthzGrpc filtertype in Envoy met een gespecificeerd service entry en poort:

...

extensionProviders:
- name: opa-ext-authz-grpc
envoyExtAuthzGrpc:
service: opa-ext-authz-grpc.local
       port: "9191"

...

De naam, serviceadres en poort van de extensionProviders moeten hetzelfde zijn in het opa_authz.yaml en opa_config.yaml.

Stap 3: Implementeer OPA-configuratie

Het opa_config.yaml definieert configuraties die met open beleid te maken hebben. Het bevat opa-istio-config en opa-policy ConfigMaps — die de gRPC-serviceimplementatie (envoy_ext_authz_grpc) en de concrete toegangsbeleidigheden respectievelijk definiëren.

De toegangsbeleidigheden kunnen worden onderverdeeld in twee delen: het eerste deel definieert de voorwaarden onder welke de toegang wordt toegestaan of geweigerd; het tweede deel definieert de gebruikersrollen en de permissies voor elke rol.

Het aanvaarden van de toegangsbeleidigheden kan enige tijd vereisen, omdat Rego hier geen veelvuldige sleutelwoorden gebruikt. Schakel een nieuwere versie van Rego in om sleutelwoorden te krijgen (bijvoorbeeld het toestaan-als-voorwaarde-sleutelwoord).

Plaats de OPA-configuratie in het bookinfo-namespace, want dat gaat samen met de toepassing:

kubectl apply -f opa_config.yaml -n bookinfo

Stap 4: Toepassing Istio-configuratie

Het opa_authz.yaml bestand bevat Istio-configuraties. Het bevat een AuthorizationPolicy en een ServiceEntry. Noteer dat de Autorisatiebeleidsprovider is opa-ext-authz-grpc, wat de extensionProvider is die we in stap 2 van de ConfigMap hebben geconfigureerd.

eveneens, de hostnaam die is gedefinieerd in de ServiceEntry is hetzelfde als de service-adres gegeven in de extensionProvider (opa-ext-authz-grpc.local). Het gRPC-dienst zal lopen op poort 9191 op localhost 127.0.0.1, wat de ServiceEntry maakt zodat de opa-istio sidecars binnen de pod door de istio-proxy container toegankelijk zijn.

Plaats de configuratie:

kubectl apply -f opa_authz.yaml -n bookinfo

Stap 5: Plaats de Applicatie en Test de Istio-OPA Autorisatiesetup

Plaats de Bookinfo-applicatie en de gateway:

kubectl apply -f /your_Istio_directory/samples/bookinfo/platform/kube/bookinfo.yaml -n bookinfo
kubectl apply -f /your_Istio_directory/samples/bookinfo/networking/bookinfo-gateway.yaml -n bookinfo

Controleer de pods in het bookinfo namespace:

kubectl get pods -n bookinfo

U kunt zien dat elke pod 3 containers in ze draait: de applicatie, Envoy proxy (istio-proxy) en OPA (opa-istio) containers.

Haal het IP-adres van de Istio-gateway om de service te bereiken:

kubectl get svc -n istio-system

Nu is alles klaar en zijn we klaar om de autorisatiebeleidstesten uit te voeren. De beleidsen die we in opa_config.yaml hebben gedefinieerd zijn de volgende:

...

user_roles = {
"alice": ["guest"],
"bob": ["admin"]
}

role_perms = {
"guest": [
{"method": "GET", "path": "/productpage"},
],
"admin": [
{"method": "GET", "path": "/productpage"},
{"method": "GET", "path": "/api/v1/products"},
        ],

...

Alice is een gastgebruiker die alleen toegang tot /productpage heeft; Bob is een beheerder die toegang heeft tot de paden /productpage en /api/v1/products. Laten we de beleidstesten controleren.

Probeer toegang te krijgen tot /api/v1/products vanaf Alice:

curl -vvv your_istio_gateway_ip/api/v1/products -u alice:password

U kunt zien dat de 403 Verboden reactie sinds Alice geen toegang heeft tot de pad. Laten we proberen dezelfde pad als Bob:

curl -vvv your_istio_gateway_ip/api/v1/products -u bob:password

Het toont de HTTP status 200 OK en de pagina inhoud aan het einde van de reactie.

Voorbeeld scenario voor toegangsbeheer met OPA

U kunt Istio’s AuthorizationPolicy CRD gebruiken om de in de demostratie hierboven getoonde beleid te handhaven. U heeft geen OPA nodig. Echter, zijn er gevallen waar Istio toegangsbeheer beperkt kan zijn, zoals in de tabel aan het begin genoemd werd. Laat me eenvoudig voorbeeld geven.

Stel dat er een BookReviews applicatie is, die een GraphQL dienst is, waar beoordelaars beoordelingen aanbieden, redacteurs deze beoordelingen bewerken en publiceren en gebruikers de gepubliceerde beoordelingen lezen.

Wanneer een beoordelaar een boekbeoordeling aan de dienst toevoegt, bevat de aanvraag de JWT van de beoordelaar, die de groepen en rollen (beoordelaar of redacteur) bevat die de beoordelaar tot behoort. De aanvraaglichaam bevat ook de GraphQL mutatiequery met de nieuw aangemaakte beoordelingendata.

Laat ons zeggen dat u de volgende voorwaarden wilt waarborgen:

• Alleen beoordelaars kunnen beoordelingen indienen.
• Een redacteur kan een beoordeling alleen bewerken als deze is geschreven door een beoordelaar die tot dezelfde groep behoort die door hen wordt beheerd.
• Alleen redacteurs kunnen een beoordeling markeren als “klaar voor publicatie”.

Hier is het diagram dat de bovenstaande beleidsen bevat:

Istio’s AuthorizationPolicy zal het bovenstaande condities moeilijk kunnen handhaven. De reden is dat Istio de GraphQL aanvraaglichaam niet kan gebruiken voor toegangscontrole, die een JSON-object is naast de JWT nodig voor de beleidsevaluatie.

OPA kent geen dergelijke beperkingen. Het kan elke gegevens laden voor policy checks, en DevOps kunnen deze regels in een meer comfortabele manier schrijven met behulp van Rego.

Video: Demo in Actie

Als u de demo liever in actie ziet, kijk dan a.u.b. op de onderstaande video:S

Bedrijfsondersteuning voor integratie van Istio

De meeste bedrijven gebruiken OPA om autorisatiepolicies te definiëren en toe te passen op hun gehele stack. Een centrale mechanismus voor toegangscontrole verbeterd de algemene beveiliging en de flexibiliteit van IT-teams. Anders zullen ontwikkelaars tijd spenderen aan het ontwikkelen van autorisatiepolicies in hun toepassingscode, geschreven in een bepaalde taal, wat de scalabiliteit en de snellere uitrollen van bedrijfslogica verhindert.