# API Gateways: Zentrale Steuerung & Security für Ihre Schnittstellen

TL;DR / Management Summary Werden Microservices direkt dem Internet ausgesetzt, entsteht ein Sicherheits- und Verwaltungschaos. Ein API Gateway agiert als zentraler Reverse Proxy (Artikel 564) für alle APIs. Es bündelt Aufgaben wie Authentifizierung, Rate Limiting, SSL-Terminierung und Request Routing. Ein Senior Admin nutzt API Gateways (z.B. Kong, Tyk oder KrakenD), um die Backend-Entwickler von Infrastruktur-Aufgaben zu entlasten und eine einheitliche Sicherheits-Policy über das gesamte Rechenzentrum durchzusetzen.

# 1. Kernfunktionen eines API Gateways

Mehr als nur ein Proxy.

Request Routing: Leitet api.firma.de/v1/user an Service A und /v1/order an Service B weiter.
Authentication: Prüft JWT-Tokens oder API-Keys, bevor die Anfrage das Backend erreicht.
Rate Limiting: Schützt vor DDoS (Artikel 753) und Missbrauch durch Begrenzung der Anfragen pro Sekunde.
Protocol Translation: Wandelt z.B. HTTP/JSON Anfragen in interne gRPC-Rufe um.

# 2. API Gateway vs. Ingress Controller

Die feinen Unterschiede.

In einer Kubernetes-Welt (Artikel 774) überschneiden sich die Rollen:

Ingress Controller: Fokus auf Layer 7 Routing innerhalb eines Clusters.
API Gateway: Fokus auf das Management der API-Logik (Planung, Monetarisierung, Dokumentation, Cross-Cluster Support).

# 3. Deep Dive: Kong (The Enterprise Leader)

Skalierbarkeit durch Plugins.

Kong basiert auf Nginx und bietet eine Lua-basierte Plugin-Engine.

Aktion: Installieren Sie Kong als Container in Proxmox.
Vorteil: Sie können per Klick Features wie “IP Restriction”, “CORS” oder “Request Transformation” hinzufügen, ohne den Code Ihrer Applikation ändern zu müssen.

# 4. Day-2 Operations: API Versioning am Gateway

Umbruch ohne Abbruch.

Ein API Gateway erlaubt ein nahtloses Versioning:

Vorgang: Das Gateway erkennt den Header X-API-Version: 2.
Aktion: Traffic wird automatisch an den neuen Container-Stack geleitet, während User ohne diesen Header weiterhin auf der stabilen Version 1 bleiben.

# 5. Troubleshooting & “War Stories”

Wenn der Flaschenhals verstopft.

# Top 3 Fehlerbilder

Symptom: “429 Too Many Requests”.
- Ursache: Das Rate-Limit ist zu strikt eingestellt oder ein Client läuft in einer Fehlerschleife.
- Lösung: Limits pro API-Key individuell anpassen.
Symptom: Hohe Latenz bei jedem API-Call.
- Ursache: Das Gateway führt zu viele synchrone Prüfungen durch (z.B. externe LDAP-Abfrage bei jedem Request).
- Fix: Nutzen Sie JWT (JSON Web Tokens), die das Gateway lokal validieren kann, ohne die Datenbank zu fragen.
Symptom: Header-Loss. Interne Server sehen die IP des Users nicht mehr.
- Lösung: X-Forwarded-For Konfiguration prüfen.

# “War Story”: Der “Double-Auth” GAU

Ein Team implementierte die Authentifizierung sowohl im API Gateway als auch in jedem einzelnen Microservice. Das Ereignis: Ein Passwort-Wechsel im AD dauerte 10 Minuten, bis er im gesamten System aktiv war. Das Ergebnis: User konnten sich am Gateway anmelden, wurden aber vom Backend abgelehnt, da die Caches asynchron waren. Fehlersuche im Log war unmöglich, da beide Systeme “Unauthorized” meldeten. Lehre: Nutzen Sie das API Gateway als einzige Instanz für die Authentifizierung (Edge-Auth). Vertrauen Sie intern dem Gateway via privatem Netzwerk oder mTLS.

# 6. Monitoring & Reporting

API-Analytics.

# Dashboard KPIs

Überwachen Sie via Prometheus:

http_requests_total (per Service).
latency_p99 (Zeit im Gateway vs. Zeit im Backend).
bandwidth_usage (pro API-Key).

# 7. Fazit & Empfehlung

Ein API Gateway ist der Wächter über Ihre digitalen Schnittstellen.

Empfehlung: Nutzen Sie KrakenD, wenn Sie maximale Performance (Go-basiert) ohne Plugin-Chaos suchen.
Wichtig: Sichern Sie das Admin-Interface des Gateways mit einem separaten VPN (Artikel 567) ab.

# Anhang: Cheatsheet (Common Gateway Tools)

Tool	Sprache	Stärke
Kong	Lua / Nginx	Plugin-Vielfalt
Tyk	Go	Native Management UI
KrakenD	Go	Performance, Stateless
Traefik	Go	Cloud-Native Integration