API-Management mit Apache APISIX
Ein Fachbeitrag von Georg Schander und Phillip Conrad aus dem Segment Finance & Public
Lösungen im Bereich des API-Managements befassen sich mit der zentralen Bereitstellung und Verwaltung von Web-APIs. Dies umfasst das Lifecycle-Management bei der Erstellung und Veröffentlichung von Web-APIs sowie die zentrale Durchsetzung von Zugriffs- und Nutzungsrichtlinien. Insbesondere die zentrale Anbindung eines übergreifenden Identity-Providers für alle veröffentlichen Schnittstellen zur Authentifizierung ist ein Kernaspekt des API-Managements. Ergänzend können beispielswiese Monitoring sowie Intrusion-Detection-Systeme angebunden oder Nutzungslimits durchgesetzt werden.
Seiteninhalt
API-Gateways für den Zero-Trust Network Access (ZTNA)
In Zero-Trust-Architekturen finden API-Gateways als zentrale API-Management-Lösung Einsatz. Sie steuern und überwachen sämtlichen eingehenden API-Traffic und geben ausgewählte API-Methoden von ansonsten internen Schnittstellen frei. Durch diesen zentralen Zugriffspunkt kann eine Vielzahl von Einzelfreigaben – z. B. je öffentlichen API-Endpunkt – durch einen einzigen Single-Point-of-Trust im Firewall-Konzept ersetzt werden. In diesem Fall läuft der gesamte API-Traffic ausschließlich über das API-Gateway im Sinne eines funktionalerweiterten Reserve-Proxys. Ebenfalls kann ein API-Gateway dabei helfen, eingesetzte Drittanbieter-Lösungen in einer einheitlichen Unternehmens-API transparent und sicher zusammengefasst zu publizieren.
Apache APISIX: Zentrale Steuerung mittels Open Source
Apache APISIX ist ein solches Open Source API-Gateway und wird unter der Apache License 2.0 veröffentlicht. Es ermöglicht eine zentrale Steuerung von Zugriffen sowie die zentrale Absicherung von Webschnittstellen. APISIX besitzt eine Vielzahl an Konfigurationsmöglichkeiten und Anbindungen an gängige Tools zum Loggen, Erfassen von Metriken oder zur Absicherung. Da alle API-Anfragen über APISIX laufen, wird die Verwendung solcher Tools vereinfacht und bestehende APIs können mit geringem Aufwand angebunden werden. Konvertierung von SOAP-basierten Schnittstellen auf besser routbare REST-APIs sind ebenfalls möglich.
Nachfolgend wird eine typische Architekturskizze für den Einsatz von APISIX dargestellt. Über eine Web-DMZ, welche sowohl APISIX als auch einen möglichen Identity-Provider kapselt, können interne APIs von unsichereren Netzbereichen bestmöglich isoliert betrieben werden.
APISIX besteht aus zwei Softwarekomponenten: APISIX und APISIX-Dashboard. APISIX stellt die API-Gateway-Funktionen bereit und APISIX-Dashboard die Verwaltungsoberfläche. Die Architektur von APISIX ist als cloud-native zu bezeichnen. Zwecks einer horizontalen Skalierung werden i.d.R. zusätzlich etcd und redis als verteilte Storages eingesetzt. In etcd werden u. a. die APISIX-Konfigurationen gespeichert. Redis dient als verteilter Cache z. B. für geteilte Rate-Limit-Zustände. Über beide Mechanismen können mehreren APISIX-Instanzen, auf die gleichen Daten synchronisiert zugreifen. Wie auch andere API-Gateways (z. B. Kong) basiert APISIX selbst auf OpenRestly und NGINX.
Konzepte von APISIX
Upstreams, Services und Routen
Ein Upstream ist das Ziel einer Route, wie beispielsweise ein interner REST-API-Server oder eine andere Datenquelle. In einem Upstream können mehrere Ziele, die die gleiche API bereitstellen, konfiguriert werden. Via Load-Balancing kann APISIX entsprechend eine Lastverteilung samt automatisiertem Health-Check umsetzen.
Services sind die Kombination einer Plugin-Konfiguration und eines Upstreams. Für den gleichen Upstream können also verschiedene Plugin-Konfigurationen verwaltet werden. Ein möglicher Anwendungsfall wäre eine API, bei der Teile unterschiedlich abgesichert werden sollen.
Routen sind die einzelnen Endpunkte der APIs. Sie können mit Services oder Upstreams verknüpft werden, um ihre Einstellungen zu erben. Sie können aber auch individuell konfiguriert werden.
Funktionen von APISIX
Im Folgenden werden die Basis-Funktionalitäten von APISIX beschrieben. Diese lassen sich in die Bereiche Traffic-Management, Sicherheit, Observability, Analytics und Weiteres einteilen.
Traffic-Management
- Rate-Limits: Limitierung der Anfragen pro Zeiteinheit für bestimmte Endpunkte oder APIs. Es ist möglich, die Anzahl an Anfragen pro (bspw.) Minute durch das Plugin
limit-connzu begrenzen. Alle weiteren über das Limit hinausgehenden Anfragen werden ignoriert. Es ist auch möglich, die Anzahl der gleichzeitigen Anfragen zu limitieren. - Load-Balancing: Gleichmäßige Verteilung von Anfragen, um die Last zu verteilen und die Ausfallsicherheit zu verbessern.
- Proxy-Mirroring: Anfragen an einen bestimmten Endpunkt werden an mehrere Server gespiegelt, um den Datenverkehr zu überwachen, ohne den laufenden Betrieb zu stören.
- Client-Control: Steuerung des Zugriffs auf APIs (Authentifizierung, IP-Adresse oder API-Schlüssel)
Sicherheit
- Authentication: verschiedene Mechanismen zur Authentifizierung von Benutzern und Anwendungen durch Plugins wie JWT, Key Auth, OpenID Connect (OIDC), Keycloak bereit.
- WAF-Integration (Coraza): Coraza ist eine Web Application Firewall (WAF), die in APISIX integriert werden kann und Schutz vor einer Vielzahl von Web-basierten Angriffen bietet.
- OPA (Open Policy Agent): Policy-Engine zum Definieren und Durchsetzen von Regeln
- CORS-Header: Konfiguration von CORS-Headern, um Cross-Origin-Anfragen zu steuern und die Sicherheit von Webanwendungen zu verbessern
- URI- & IP-Restriction: Einschränkung des Zugriffs auf bestimmte Endpunkte basierend auf der URI oder IP-Adresse des Clients. Das Plugin
ip-restrictionermöglicht es, den Zugriff über eine Whitelist zu gestatten bzw. den Zugriff über eine Blacklist zu sperren.
Observability und Analytics
- Tracing: Tracing-Tools wie Zipkin und OpenTelemetry dienen dazu, die Leistung von APIs zu überwachen und zu analysieren.
- Metrics: Metriken und Statistiken über den eingehenden und ausgehenden Traffic können mit Monitoring-Tools wie Prometheus und Datadog visualisiert und analysiert werden.
- Logging: Protokollieren von Anfragen und Antworten für eine detaillierte Analyse und Fehlersuche
Weitere ausgewählte Funktionen
- Simulation von Störungen: Simulation von Netzwerkstörungen oder Ausfällen, um die Reaktion des Systems darauf zu testen und die Robustheit der APIs zu verbessern
- Mocking: Erstellen von Mocks für APIs, um das Verhalten von Backend-Services zu simulieren und die Entwicklung und Tests zu vereinfachen
- Serverless: Es können einfach Funktionen definiert werden, die APISIX um kleinere Funktionen erweitern. Es ist möglich diese sowohl vor einem Event bzw. danach auszuführen.
- Vieles mehr: Ingress-Support, Kafka- & MQTT-Proxy, Public-APIs, gPRC- & SOAP-Transcoding…
Plugins und Erweiterbarkeit von APISIX
APISIX verfügt über eine Plugin-basierte Architektur, welche die Erweiterung und Endpunkt-spezifische Konfiguration von APISIX erlaubt. Eine Vielzahl von Basis-Plugins bringt Apache APISIX von Haus aus mit. Sie werden in die Kategorien „Authentication“, „Security“, „Traffic“ „Control“, „Serverless“, „Observability“ und „Other“ unterteilt. Zusätzlich ist es möglich bei Bedarf eigene Plugins in Lua, Java, C#, Python, Typescript, Go etc. zu schreiben.
Bei der Plugin-Entwicklung wird zwischen der internen Plugin-Ausführung auf Lua-Basis und der externen Anbindung per RPC unterschieden. Die zweite Option basiert auf Googles Flattbuffers. Die RPC-Option erlaubt die Plugin-Entwicklung in fast beliebiger Programmiersprache. Lua-Skripte haben hingegen den Vorteil eines vereinfachten Deployments und werden In-Process ausgeführt, was wiederum einen Performance-Vorteil gerade bei überschaubaren Plugins mit sich bringt.
Die Nutzeroberfläche von APISIX
Nachfolgend ist die Nutzeroberfläche von APISIX abgebildet. In der Navigationsleiste sind die einzelnen Komponenten wie Routen, Upstreams und Services zu sehen. Auf den Detailseiten können diese Komponenten verwaltet werden. Alternativ kann das Command Line Interface (CLI) oder die Admin-API verwendet werden. Die CLI bietet eine entsprechend DevOps-taugliche Konfigurationsmöglichkeit. Helm-Chart oder Terraform-Provider für APISIX liegen ebenfalls vor.
Import bestehender Swagger- oder OpenAPI-Definitionen
Bestehende APIs, z. B. im Format OpenAPI, können im APISIX-Dashboard einfach importiert werden. Nach dem Import sind die einzelnen Endpunkte in der Übersicht einsehbar und können verwaltet werden. Ein analoger Export der in APISIX gespeicherten und publizierten Routen ist ebenfalls möglich.
Skalierbarkeit
Bei höheren Lasten und Verfügbarkeitsanforderungen, kann es sinnvoll sein, der Auslastung durch mehrere APISIX-Instanzen entgegenzuwirken. Dazu werden beispielsweise in einem Kubernetes-Cluster mehrere APISIX-Instanzen erstellt. Ein vorgeschalteter Load Balancer verteilt Anfragen gleichmäßig auf die Instanzen. Unter den APISIX-Instanzen gibt es keine direkte Kommunikation. Die einzelnen APISIX-Instanzen greifen auf ein gemeinsames etcd-Cluster zu, in welchem die Datensynchronisation erfolgt. In diesem Kontext ist zu erwähnen, dass APISIX ebenfalls als Erweiterung des Ingress-Controllers in Kubernetes als zentrales API-Gateway konfiguriert werden kann.
Identity-Provider
Von APISIX werden OpenID-Connect (OIDC), OAuth oder SAML2 basierte Identity-Provider unterstützt. Im OpenSource-Bereich wäre z. B. Keycloak ein sehr gut kombinierbarer Identity-Provider. Keycloak stellt Benutzeridentitäten samt den zugehörigen Zugriffsrechten (Authentifizierung sowie Autorisierung) für die angebundenen Anwendungen in Form eines Authentifizierungsgateways bereit. Alle gängigen Konfigurationen lassen sich über die Weboberfläche von Keycloak durchführen. Administrative Aufgaben können – wie auch bei APISIX – über eine CLI erledigt werden. Auf diese Weise können Konfigurationen z. B. vorkonfektioniert werden oder gar über Deployment-Skripte automatisiert durchgeführt werden. Keycloak kann wiederum als Identity-Broker an anderen Identity-Provider wie Microsoft Entra angebunden werden.
Wie auch bei APISIX sind Performance, Sicherheit und Skalierbarkeit wichtige Merkmale von Keycloak.
APISIX meets Keycloak
Lösung zur Absicherung und Verwaltung von Schnittstellen
Die gemeinsame Verwendung von APISIX als API-Gateway und von Keycloak als IdP-Komponente ermöglichen es, eine zentrale Zugriffsstrategie nach dem Zero-Trust-Ansatz zu implementieren. APISIX verwaltet die APIs und Keycloak ermöglicht eine Authentifizierung. Beim Zugriff auf die APIs kann differenziert werden, ob alle Schnittstellen zugänglich oder ob einzelne Schnittstellen unzugänglich sein sollen. Durch das bereitgestellte APISIX-Dashboard wird ein Überblick über alle vorhandenen Schnittstellen geschaffen. Dort ist auf einen Blick ersichtlich, ob Schnittstellen aktuell aktiv publiziert sind. Wenn eine Schnittstelle kurzfristig deaktiviert werden soll, kann dies über die APISIX-GUI erfolgen. Zusätzlich kann bei der Inspektion einer einzelnen Schnittstelle eingesehen werden, welche Plugins verwendet werden bzw. ob sie (bspw. mit Keycloak) abgesichert ist. Über die oben genannten Plugins wie Black/Whitelist, Limitierung der Anfragen kann die Schnittstelle vor Missbrauch und Überlastung geschützt werden.
Keycloak übernimmt als Authentifizierungsgateway die zentrale Steuerung aller Authentifizierungen. So ist es beispielsweise möglich, alle Schnittstellen über Keycloak abzusichern. Auch lässt sich der Zugriff auf Schnittstellen feingranular steuern. Wenn einige Schnittstellen öffentlich zugänglich sein sollen, wird auf die Absicherung durch Keycloak verzichtet. Bei Schnittstellen, die eine Absicherung benötigen, wird diese aktiviert. Nach der Umstellung ist die Schnittstelle sofort zugänglich bzw. nicht mehr zugänglich. Ein Neustart oder eine Wartezeit sind aufgrund des Hot Updates bzw. Hot Plugins von APISIX nicht notwendig. Die Kombination von APISIX und Keycloak stellt eine robuste und flexible Lösung zur Absicherung und Verwaltung von Schnittstellen bereit.
Monitoring mit Grafana
Grafische Darstellung von Metrikdaten
Die Kombination von APISIX und Grafana ermöglicht die grafische Darstellung von Metrikdaten zur Überwachung der angebundenen Schnittstellen. Es ist u. a. möglich auszuwerten, wie viele Anfragen innerhalb eines Zeitraums auf eine spezifische Route entfallen. Zusätzlich lassen sich Alerts erstellen. Diese können etwa bei einer Überschreitung eines bestimmten Grenzwertes (bspw. prozentuale CPU-Auslastung etc.) getriggert werden. Bei einer Überschreitung der definierten Schwelle wird z. B. eine E-Mail an die verantwortliche Person gesendet. Auf diese Weise kann auf diesen Sachverhalt reagiert werden. Durch die Überwachung des Datenverkehrs können Überlastungen oder Angriffe erkannt und ggf. Gegenmaßnahmen ergriffen werden.
Oben dargestellt ist ein typisches APISIX-Dashboard innerhalb von Grafana. Unter anderem ist die Anzahl der Anfragen zu sehen, welche nach Statuscode gruppiert werden. Zusätzlich werden diese Werte in dem darunter zu sehenden Diagramm nach aufgerufenen Routen aufgeschlüsselt.
Ähnlich zum APISIX-Dashboard in Grafana können auch Metrikdaten aus Keycloak angebunden werden. So lässt sich aufschlüsseln, wie viel Prozent der Logins auf einen bestimmten Realm entfallen. Ebenfalls kann die Hardwareauslastung überwacht werden. Um in Grafana Metrikdaten von externen Diensten wie Keycloak oder APISIX anzuzeigen, gilt es die dienstspezifischen Metrikdaten im Vorfeld über Prometheus zu sammeln.
Fazit: Darum ist Apache APISIX empfehlenswert
APISIX deckt viele Standardanforderungen an ein API-Gateway ab und lässt sich leicht konfigurieren. Erweiterungsmöglichkeiten sind durchgängig gegeben und die Dokumentation ist detailliert. Da sich das System einer hohen Beliebtheit erfreut, finden sich auch viele Informationen und Lösungsansätze zu bekannten Herausforderungen im Netz.
Die Installation und Inbetriebnahme ist in mehreren Varianten möglich (z. B. mittels Docker-Containern oder direkt in Kubernetes), sehr einfach durchzuführen und lädt zum Experimentieren mit der Software ein. Ein nicht zu unterschätzender Aspekt ist zudem die lebendige Entwickler-Community, die einerseits für einen hohen Sicherheitsstandard sorgt und andererseits eine kontinuierliche Weiterentwicklung der Software sicherstellt.
Die bisherigen Funktionalitäten im Bereich API-Lifecycle-Managements sind im Vergleich zu Enterprise API-Management-Lösungen noch ausbaubar, können aber im Verhältnis zum ansonsten lizenzkostenfreien Einsatz individuell ergänzt werden.
Bei weiteren Fragen rund um Apache APISIX kontaktieren Sie uns gern.
Vereinbaren Sie eine kostenlose Beratung
Phillip Conrad
Segment Manager
+49 231 9644-422
p.conrad@smf.de
Pflicht für alle Anfragen zu unseren Angeboten. *
Weiterführende Links
