Kong Gateway is een open-source API-gateway die ervoor zorgt dat alleen de juiste verzoeken toegelaten worden en die beveiliging, snelheidslimieten, logging en meer beheert. OPA (Open Policy Agent) is een open-source beleidsengine die de controle over uw beveiliging en toegangsbeslissingen neemt. Denk eraan als de geest die beleidsuitoefening ontkoppelt van uw app, zodat uw services niet hoeven te maken over het handhaven van regels. In plaats daarvan doet OPA het denken met zijn Rego-taal, het evalueren van beleid over APIs, microservices of zelfs Kubernetes. Het is flexibel en veilig, en het maakt het bijwerken van beleid een gemak. OPA werkt door drie belangrijke dingen te evalueren: invoer (reële tijddata zoals verzoeken), gegevens (externe informatie zoals gebruikersrollen) en beleid (de logica in Rego die beslist of iets “toegestaan” of “geweigerd” moet worden). Samen stellen deze componenten OPA in staat om uw beveiligings spel sterk te houden terwijl het dingen eenvoudig en consistent houdt.
Wat Seeken We Te Bereiken of Oplossen?
Vaak zijn de gegevens in OPA als een vaste oude vriend – statisch of langzaam veranderend. Het wordt gebruikt naast de steeds veranderende invoergegevens om slimme beslissingen te nemen. Maar stel je een systeem voor met een wijdvertakt web van microservices, tonnen gebruikers en een enorme database zoals PostgreSQL. Dit systeem verwerkt elke seconde een hoog volume aan transacties en moet de snelheid en doorvoer op peil houden zonder dat het je moeite kost.
Fijne toegangscontrole in zo’n systeem is lastig, maar met OPA kun je het zware werk van je microservices overnemen en op gateway-niveau afhandelen. Door samen te werken met Kong API Gateway en OPA, krijg je zowel uitstekende doorvoer als nauwkeurige toegangscontrole.
Hoe onderhoud je nauwkeurige gebruikersgegevens zonder de boel te vertragen? Voortdurend die PostgreSQL database raadplegen om miljoenen records op te halen is zowel duur als traag. Het bereiken van zowel nauwkeurigheid als snelheid vereist meestal compromissen tussen de twee. Laten we proberen een praktische balans te vinden door een aangepaste plugin te ontwikkelen (op gateway niveau) die regelmatig gegevens laadt en lokaal cached voor OPA om te gebruiken bij het evalueren van zijn beleid.
Demo
Voor de demo heb ik voorbeeldgegevens ingesteld in PostgreSQL, die informatie over gebruikers bevatten zoals naam, e-mail, en rol. Wanneer een gebruiker probeert toegang te krijgen tot een dienst via een specifieke URL, evalueert OPA of het verzoek is toegestaan. De Rego-politiek controleert de URL van het verzoek (resource), de methode, en de rol van de gebruiker, en keert dan true of false terug op basis van de regels. Als het true is, mag het verzoek doorgaan; als het false is, wordt toegang geweigerd. Het is een rechttoe-zonder-omweg-opstelling. Laten we eens kijken naar de aangepaste plugin.
Wanneer een verzoek via de Kong Proxy komt, wordt de aangepaste Kong-plugin geactiveerd. De plugin haalt de benodigde gegevens op en stuurt deze samen met de input/query naar OPA. Deze gegevensopslag bestaat uit twee delen: één is om in Redis te zoeken naar de vereiste waarden, en als deze gevonden zijn, door te geven aan OPA; anders gaat het een query uitvoeren naar Postgres en haalt de gegevens op en cacht deze in Redis alvorens ze door te geven aan OPA. We kunnen dit later opnieuw bekijken als we de commando’s in de volgende sectie uitvoeren en de logs observeren. OPA neemt een beslissing (gebaseerd op de politiek, input, en gegevens) en als het is toegestaan, zal Kong het verzoek doorgsturen naar de API. Met deze aanpak wordt het aantal queries naar Postgres aanzienlijk verminderd, terwijl de beschikbare gegevens voor OPA redelijk accuraat zijn en de lage latency behouden blijft.
Om een aangepaste plugin te beginnen bouwen, hebben we een handler.lua nodig waar de kernlogica van de plugin wordt geïmplementeerd en een schema.lua die, zoals de naam aangeeft, het schema definieert voor de configuratie van de plugin. Als je begint te leren hoe je aangepaste plugins voor Kong schrijft, raadpleeg dan deze link voor meer informatie. De documentatie legt ook uit hoe je de plugin kunt verpakken en installeren. Laten we doorgaan en de logica van deze plugin begrijpen.
De eerste stap van de demo zou zijn om OPA, Kong, Postgres, en Redis op je lokale installatie of een cloudinstallatie te installeren. Clone dan deze repository.
Bekijk de docker-compose yaml die de configuraties definieert om alle vier bovengenoemde services te deployen. Let op de Kong Env-variabelen om te zien hoe de aangepaste plugin wordt geladen.
Voer de onderstaande commando’s uit om de services te deployen:
docker-compose build
docker-compose up
Als we hebben gecontroleerd of de containers actief zijn, zijn Kong manager en OPA beschikbaar op respectievelijke endpoints https://localhost:8002 en https://localhost:8181 zoals hieronder weergegeven:
Maak een testservice, route en voeg onze aangepaste Kong-plugin toe aan deze route met behulp van het onderstaande commando:
curl -X POST http://localhost:8001/config -F config=@config.yaml
De OPA-politiek, gedefinieerd in het bestand authopa.rego, wordt gepubliceerd en bijgewerkt naar de OPA-service met behulp van het onderstaande commando:
curl -X PUT http://localhost:8181/v1/policies/mypolicyId -H "Content-Type: application/json" --data-binary @authopa.rego
Deze voorbeeldpolicy verleent toegang tot gebruikersverzoeken alleen als de gebruiker toegang heeft tot het pad /demo met een GET-methode en de rol heeft van "Moderator". Aanvullende regels kunnen toegevoegd worden naar behoefte om toegangscontrole te verfijnen op basis van verschillende criteria.
opa_policy = [
{
"path": "/demo",
"method": "GET",
"allowed_roles": ["Moderator"]
}
]
Nu de setup klaar is, maar voordat we gaan testen, hebben we testgegevens nodig die we kunnen toevoegen in Postgres. Ik heb wat voorbeeldgegevens (naam, e-mail en rol) voor een aantal werknemers toegevoegd zoals hieronder weergegeven (zie PostgresReadme voor referentie).
Hier is een voorbeeld van een mislukte en succesvolle aanvraag:
Om nu de kernfunctionaliteit van deze custom plugin te testen, laten we twee opeenvolgende aanvragen doen en kijken naar de logs om te zien hoe de gegevensverwerking plaatsvindt.
Hier zijn de logs:
2024/09/13 14:05:05 [error] 2535#0: *10309 [kong] redis.lua:19 [authopa] No data found in Redis for key: [email protected], client: 192.168.96.1, server: kong, request: "GET /demo HTTP/1.1", host: "localhost:8000", request_id: "ebbb8b5b57ff4601ff194907e35a3002"
2024/09/13 14:05:05 [info] 2535#0: *10309 [kong] handler.lua:25 [authopa] Fetching roles from PostgreSQL for email: [email protected], client: 192.168.96.1, server: kong, request: "GET /demo HTTP/1.1", host: "localhost:8000", request_id: "ebbb8b5b57ff4601ff194907e35a3002"
2024/09/13 14:05:05 [info] 2535#0: *10309 [kong] postgres.lua:43 [authopa] Fetched roles: Moderator, client: 192.168.96.1, server: kong, request: "GET /demo HTTP/1.1", host: "localhost:8000", request_id: "ebbb8b5b57ff4601ff194907e35a3002"
2024/09/13 14:05:05 [info] 2535#0: *10309 [kong] handler.lua:29 [authopa] Caching user roles in Redis, client: 192.168.96.1, server: kong, request: "GET /demo HTTP/1.1", host: "localhost:8000", request_id: "ebbb8b5b57ff4601ff194907e35a3002"
2024/09/13 14:05:05 [info] 2535#0: *10309 [kong] redis.lua:46 [authopa] Data successfully cached in Redis, client: 192.168.96.1, server: kong, request: "GET /demo HTTP/1.1", host: "localhost:8000", request_id: "ebbb8b5b57ff4601ff194907e35a3002"
2024/09/13 14:05:05 [info] 2535#0: *10309 [kong] opa.lua:37 [authopa] Is Allowed by OPA: true, client: 192.168.96.1, server: kong, request: "GET /demo HTTP/1.1", host: "localhost:8000", request_id: "ebbb8b5b57ff4601ff194907e35a3002"
2024/09/13 14:05:05 [info] 2535#0: *10309 client 192.168.96.1 closed keepalive connection
------------------------------------------------------------------------------------------------------------------------
2024/09/13 14:05:07 [info] 2535#0: *10320 [kong] redis.lua:23 [authopa] Redis result: {"roles":["Moderator"],"email":"[email protected]"}, client: 192.168.96.1, server: kong, request: "GET /demo HTTP/1.1", host: "localhost:8000", request_id: "75bf7a4dbe686d0f95e14621b89aba12"
2024/09/13 14:05:07 [info] 2535#0: *10320 [kong] opa.lua:37 [authopa] Is Allowed by OPA: true, client: 192.168.96.1, server: kong, request: "GET /demo HTTP/1.1", host: "localhost:8000", request_id: "75bf7a4dbe686d0f95e14621b89aba12"
De logs geven aan dat bij de eerste aanvraag, waarbij er geen gegevens in Redis aanwezig zijn, de gegevens uit Postgres worden opgehaald en in Redis worden gecached voordat ze naar OPA worden gestuurd voor evaluatie. Bij de daaropvolgende aanvraag, aangezien de gegevens in Redis beschikbaar zijn, zal de respons veel sneller zijn.
Conclusie
In conclusie door Kong Gateway samen te voegen met OPA en het custom plugin met Redis caching uit te voeren, wordt effectief een evenwicht gehandhaafd tussen nauwkeurigheid en snelheid voor toegangscontrole in high-throughput omgevingen. Het plugin minimaliseert het aantal kostbare Postgres-query’s door gebruikersrollen in Redis te cachen na de eerste query. Bij volgende verzoeken wordt de data opgehaald uit Redis, wat significant de latency reduceert terwijl accurate en actuele informatie over gebruikers wordt behouden voor OPA-beoordelingen van beleidsregels. Deze aanpak zorgt ervoor dat fijnmazige toegangscontrole effectief wordt behandeld op niveau van de gateway zonder dat er performantie of veiligheid worden opgeofferd, waardoor het een ideale oplossing is voor het scalen van microservices terwijl exacte toegangsbeleid wordt afgedwongen.
Source:
https://dzone.com/articles/enhanced-api-security-fine-grained-access-control