Kong API Gateway, Enterprise API Management mit Open Source

Warum ein API Gateway

In einer Microservice-Architektur kommunizieren dutzende Services miteinander und mit externen Clients. Ohne zentrale Steuerungsschicht entstehen schnell Probleme: Authentifizierung wird in jedem Service separat implementiert, Rate Limiting fehlt, Logging ist inkonsistent, und die Frage “Wer ruft was auf?” lässt sich nicht beantworten.

Ein API Gateway löst diese Querschnittsanliegen an einer zentralen Stelle. Es ist der einzige öffentlich erreichbare Endpunkt, alle Requests laufen durch das Gateway, bevor sie an Backend-Services weitergeleitet werden.

Kong im Vergleich

Der Markt für API Gateways ist breit. Die Entscheidung für Kong war das Ergebnis einer strukturierten Evaluation:

Kriterium	Kong	Nginx/OpenResty	Traefik	AWS API Gateway
Open Source	Ja (Apache 2.0)	Ja	Ja	Nein
Plugin-Ökosystem	Umfangreich	Lua-basiert, manuell	Middleware	AWS-spezifisch
Kubernetes-nativ	Kong Ingress Controller	Nginx Ingress	Nativ	Cloud-only
Enterprise Features	Kong Enterprise	Nicht vorhanden	Begrenzt	Ja (AWS Lock-in)
Declarative Config	deck / CRDs	Konfigurationsdatei	Labels/Annotations	CloudFormation
Performance	~10.000 RPS/Core	~15.000 RPS/Core	~8.000 RPS/Core	Abhängig von Region

Warum Kong

Die Entscheidung fiel auf Kong aus mehreren Gründen:

Open-Source-Kern, Kein Vendor Lock-in. Die Community Edition deckt 80% der Anforderungen ab
Plugin-Architektur, Standardfunktionalität über Plugins, eigene Plugins in Lua oder Go entwickelbar
Kubernetes-native, Kong Ingress Controller als Alternative zu Nginx Ingress mit deutlich mehr Funktionalität
Deklarative Konfiguration, Infrastructure as Code über deck CLI oder Kubernetes CRDs

Plugin-Ökosystem

Kongs Stärke liegt in den Plugins. Jedes Plugin implementiert eine spezifische Funktionalität, die per Route, Service oder global konfiguriert werden kann.

Authentifizierung und Autorisierung

OIDC Plugin, Token-Validierung gegen Keycloak. Jeder Request muss ein gültiges JWT im Authorization-Header tragen
Key Authentication, API-Key-basierte Authentifizierung für Machine-to-Machine-Kommunikation
ACL Plugin, Gruppenmitgliedschaft als zusätzliche Autorisierungsschicht

Traffic Control

apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: rate-limiting-prod
config:
  minute: 100
  hour: 5000
  policy: redis
  redis_host: redis.infrastructure
  redis_port: 6379
plugin: rate-limiting

Rate Limiting pro Consumer und Route verhindert Missbrauch und schützt Backend-Services vor Überlastung. Die Redis-Backend-Policy stellt sicher, dass Limits über alle Kong-Instanzen hinweg konsistent sind.

Request/Response Transformation

Request Transformer, Header hinzufügen oder entfernen, bevor Requests an Backend-Services weitergeleitet werden
Response Transformer, Sensitive Header aus Responses entfernen (z.B. X-Powered-By, interne Service-Header)
Correlation ID, Jeder Request erhält eine eindeutige ID, die durch alle Services propagiert wird

Observability

Prometheus Plugin, Exponiert Metriken im Prometheus-Format: Request Count, Latenz, Status Codes, Upstream Health
OpenTelemetry Plugin, Distributed Tracing über das gesamte System
File Log / HTTP Log, Access Logs an Loki oder eine zentrale Log-Aggregation weiterleiten

Kong in Kubernetes

Kong Ingress Controller

Der Kong Ingress Controller ersetzt den Standard-Nginx-Ingress in Kubernetes und bietet erweiterte Routing-Funktionalität:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: vop-api
  annotations:
    konghq.com/plugins: rate-limiting-prod, oidc-auth
    konghq.com/strip-path: "true"
spec:
  ingressClassName: kong
  rules:
    - host: api.rypox.de
      http:
        paths:
          - path: /api/v1/vop
            pathType: Prefix
            backend:
              service:
                name: vop-gateway
                port:
                  number: 8080

Plugins werden per Annotation an Ingress-Ressourcen gebunden. Das ist deklarativ, versioniert und reviewbar, kein imperativer API-Call gegen die Kong Admin API.

Deployment-Architektur

Internet → Kong Ingress Controller (2+ Replicas)
  → VoP Gateway Service
    → VoP Matcher Service
    → VoP Audit Service
  → BankDir API
  → Health/Status Endpoints

Kong läuft als Deployment mit mindestens zwei Replicas und einem PostgreSQL-Backend für die Konfiguration. Im DB-less Mode ist auch eine rein deklarative Konfiguration ohne Datenbank möglich, das vereinfacht das Setup, schränkt aber die dynamische Plugin-Konfiguration ein.

QWAC-Zertifikate für PSD2

Im Kontext der PSD2-Regulierung müssen Zahlungsdienstleister qualifizierte Website-Authentifizierungszertifikate (QWAC) verwenden. Kong kann als TLS-Terminierungspunkt QWAC-Zertifikate präsentieren und Client-Zertifikate validieren.

mTLS am Gateway

apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: mtls-auth
config:
  ca_certificates:
    - "ca-cert-id-for-psd2-ca"
  revocation_check_mode: SKIP
  skip_consumer_lookup: false
plugin: mtls-auth

Das mtls-auth Plugin validiert das Client-Zertifikat gegen eine Liste vertrauenswürdiger CAs. Im PSD2-Kontext sind das die Qualified Trust Service Providers (QTSPs), die QWAC-Zertifikate ausstellen.

Zertifikatsinformationen als Header

Nach erfolgreicher Validierung extrahiert Kong Informationen aus dem Client-Zertifikat und leitet sie als Header an Backend-Services weiter:

X-Client-Cert-DN, Distinguished Name des Clients
X-Client-Cert-Serial, Seriennummer des Zertifikats
X-Client-Cert-Roles, PSD2-Rollen aus dem Zertifikat (AISP, PISP, PIISP)

Backend-Services können anhand dieser Header autorisieren, ohne selbst TLS-Terminierung durchführen zu müssen.

Operativer Betrieb

Health Checks

Kong prüft die Verfügbarkeit der Backend-Services über aktive und passive Health Checks:

Active Health Checks, Kong sendet periodisch Requests an einen Health-Endpoint. Unhealthy Backends werden aus dem Load Balancing entfernt
Passive Health Checks, Kong wertet Responses aus. Zu viele 5xx-Responses führen zum automatischen Circuit Breaking

Zero-Downtime Updates

Kong-Updates erfolgen über Rolling Deployments in Kubernetes. Die deklarative Konfiguration über CRDs stellt sicher, dass die Konfiguration nach dem Update identisch ist. Database Migrations werden automatisch ausgeführt.

Monitoring

Zentrale Metriken für das Kong-Monitoring:

Metrik	Beschreibung	Alert-Schwelle
`kong_http_requests_total`	Gesamtanzahl Requests	Anomalie-Detection
`kong_request_latency_ms`	Gateway-Latenz (ohne Upstream)	p99 > 50ms
`kong_upstream_latency_ms`	Backend-Latenz	p99 > 500ms
`kong_bandwidth_bytes`	Traffic-Volumen	Ungewöhnliche Spitzen
`kong_datastore_reachable`	DB-Konnektivität	0 (nicht erreichbar)

Fazit

Kong hat sich in unserem Stack als zuverlässiges API Gateway bewährt. Die Kombination aus Open-Source-Kern, umfangreichem Plugin-Ökosystem und nativer Kubernetes-Integration macht es zur soliden Wahl für Microservice-Architekturen. Für regulierte Umgebungen im Zahlungsverkehr bieten die mTLS- und QWAC-Unterstützung die notwendige Grundlage für PSD2-Compliance. Die deklarative Konfiguration über Kubernetes CRDs passt in den GitOps-Workflow und macht das Gateway-Setup reproduzierbar und auditierbar.