Microservices: Kong Gateway 2.3 spendiert dem Gorilla einen Sandkasten

Inhaltsverzeichnis

Das Unternehmen Kong hat Version 2.3 des gleichnamigen Microservices-Gateways veröffentlicht. Das aktuelle Release ändert die Standardeinstellungen zum Ausführen von Lua-Skripten zugunsten der Sicherheit. Außerdem bringt es einige Ergänzungen bei den Plug-ins unter anderem für das Logging und die Authentifizierung mit.

Mit Blick auf den weltweiten Einsatz lassen sich Routen- und Service-Namen neuerdings in UTF-8 angeben. Neben russischen oder japanischen Schriftzeichen dürfen auch Emojis Bestandteil der Servicenamen sein.

Öffnen statt absichern

Für die Einstellungen gilt ab sofort das Secure-by-Default-Prinzip: Kong Gateway ist standardmäßig restriktiv eingestellt, und wer flexiblere Settings benötigt, muss sie explizit aktivieren. Das gilt vor allem für das Ausführen von Lua-Code. Die Skriptsprache ließ sich bisher beliebig für Serverless-Funktionen verwenden und die hatten damit potenziell Zugriff auf den Kong-Prozess selbst.

Zwar existierte dazu die explizite Empfehlung, den Administrationsport abzusichern und im Zweifel entsprechende Plug-ins in der Konfiguration zu deaktivieren. Nun dreht die Software den Spieß jedoch um und führt Lua-Programme standardmäßig nur in einer Sandbox aus. Den erweiterten Einsatz müssen Administratorinnen und Administratoren explizit erlauben.

Im Sandkasten gelten eigene Regeln

Konkret gilt für Serverless-Funktionen, dass Lua-Code in der Sandbox per Default lediglich Zugriff auf das Kong PDK (Plugin Development Kit), die OpenResty-ngx-APIs und die Lua-Standardbibliotheken hat. Für das Sandboxing existieren drei neue Konfigurationsparameter: untrusted_lua, untrusted_lua_sandbox_requires und untrusted_lua_sandbox_environment .

In der Standardeinstellung sandbox erlaubt der Parameter untrusted_lua das Ausführen von Lua-Code in der Sandbox. Über off ist das Laden von Lua-Code grundsätzlich untersagt, während on die Ausführung ohne Sandbox erlaubt. Letztere Einstellung entspricht den bisherigen Vorgaben.

Bei untrusted_lua_sandbox_requires handelt es sich um eine globale Einstellung, die zusätzliche Module für die Sandbox bereitstellt, und mit untrusted_lua_sandbox_environment lassen sich zusätzliche Lua-Variablen für die Sandbox definieren.

Erweiterte Plug-ins

Bei den Plug-ins von Kong Gateway gibt es ein paar nennenswerte Ergänzungen. Dass das HTTP-Log-Plug-in das Zufügen von Headern zum HTTP-Request erlaubt, soll das Zusammenspiel mit Observability-Werkzeugen wie Splunk und den Tools der Elastic Cloud auf Kubernetes (ECK) verbessern. Das Key-Authentication-Plug-in bringt die beiden neuen booleschen Konfigurationsparameter key_in_header key_in_query mit, die standardmäßig auf true stehen.

Schließlich lässt sich über den Parameter require_content_length festlegen, dass das Request-Size-Limiting-Plug-in vor dem Lesen des Request Body sicherstellt, dass der Header eine gültige Content-Length enthält.

Großer Gorilla für kleine Services

Kong verbindet ein Open-Source-API-Gateway mit einem Load Balancer. Das Gateway hat italienische Wurzeln und entstand ursprünglich 2009 in Mailand. Bis zur Umbenennung 2017 hieß das dahinter stehende Unternehmen Mashape, und die Software Kong ist seit 2015 ein Open-Source-Projekt.

Daneben existiert ein Enterprise-Produkt, das zusätzliche Funktionen unter anderem zur Administration, für Security und Hochverfügbarkeit bietet. Außerdem enthält die Enterprise-Variante mit Kong Studio eine angepasste Version von Insomnia zum Erstellen, Testen und Veröffentlichen von REST- und GraphQL-basierten Schnittstellen.

Weitere Neuerungen in Kong Gateway 2.3 lassen sich dem Kong-Blog entnehmen. Wie bei den Vorversionen 2.1 und 2.2 hat Kong parallel zur Open-Source-Variante eine Betaversion von Kong Enterprise 2.3 veröffentlicht.

(rme)