Plugins und Middleware im API Gateway

1) Warum Plugins und Middleware benötigt werden

• standardisiert die Sicherheit (authN/authZ, WAF, CORS),
• schützt die Nachhaltigkeit (Rate Limit, Circuit Breaker, Retry-Policies),
• verwaltet den Vertrag (Validierung von Schemata, Transformationen),
• gibt Beobachtbarkeit (Metriken, Protokolle, Tracing),
• reduziert die Kosten (Caching, Deduplizierung, Kanarienregeln).

Der Schlüssel: minimale Latenz und klare Applikationsreihenfolge.

2) Plugin-Klassen und was sie tun

1. Identifizierung/Authentifizierung

JWT/JWKS-Anbieter, OAuth2/OIDC, API-Schlüssel, mTLS (Client cert).
HMAC-Signaturen (Webhooks/Partner), DPoP/PoP am Rand.

2. Autorisation

RBAC/ABAC/OPA/Cedar (PDP) mit lokalem Lösungs-Cache.
BOLA-guard: Prüfung 'tenant '/' owner' in Überschriften/Kontext.

3. Netzwerk- und Protokollschutz

WAF (OWASP CRS), antibot (rate/behavioral), Geo/IP/ASN-Filter, TLS-Profile.
CORS, CSP-Header, Fetch-Metadata-Filter, CORP/COOP/COEP.

4. Immunität

Rate limiting (token bucket/GCRA), Quoten und Wettbewerbsfähigkeit.
Circuit Breaker, Timeouts, adaptive Concurrency, Load Shedding.
Retry-Politik mit per-try Timeout und Jitter.

5. Transformationen und Validierung

Pfad-/Header-Zählung, Body-Rewrite, JSON/XML ↔, gRPC ↔ HTTP.
Validierung von Schemata (OpenAPI/JSON Schema/Protobuf), Normalisierung der ID.

6. Caching und Performance

Response/fragment cache, ETag/If-None-Match, compression, brotli.
Anfrage collapsing (coalescing) für die gleichen Schlüssel.

7. Beobachtbarkeit und Audit

RED/USE Metriken, Entscheidungsprotokollierung (429/403/5xx), Tracing (W3C Trace-Context/OpenTelemetry), Sampling (tail/adaptive).
Überwachen Sie Sicherheitsüberschriften und Richtlinienversionen.

8. Lebenszyklus und Betrieb

Canary/blue-green, Feature-Flags, Shadow-Lösungen (loggen, nicht anwenden), Versionsmigrationen.

3) Reihenfolge der Anwendung (empfohlene Kette)

[Ingress TLS]
→ Early-Deny (ASN/Geo, IP allow/deny)
→ mTLS / Client Cert Auth
→ JWT/OAuth2 AuthN (JWKS cache)
→ OPA/ABAC AuthZ (solution cache)
→ Rate Limit / Concurrency
→ Circuit / Timeout / Retries (пер-try)
→ Schema Validation (request)
→ Transform (headers/path/body) / CORS
→ Caching (lookup)
→ Upstream Proxy (app)
← Caching (store) / Compression
← Response Transform / Schema Validation (response)
← Logging / Tracing / Metrics / Security Headers

Das Prinzip: früher - billiger/fataler (deny, auth, limits), später - „Kosmetik“ (Transformationen, Cache).

4) Produktivität und Kardinalität

Halten Sie sich an O (1) Schritte ohne externe Anfragen auf dem heißen Weg.
Alle „externen Anrufe“ der Plugins (PDP/JWKS) erfolgen über kurze TTLs und asynchrones Refresh.
Tags/Labels für Metriken - begrenzte Kardinalität ('tenant', 'plan', 'route', aber nicht 'user _ id').
„Schwere“ Plugins (WAF, Body-Transform) - aktivieren Sie selektiv per Route.

5) Beispiele für Konfigurationen

5. 1 Envoy: JWT + RateLimit + OPA + Retries (Pseudo)

yaml static_resources:
listeners:
- name: public_listener filter_chains:
- filters:
- name: envoy. filters. network. http_connection_manager typed_config:
route_config:
name: main virtual_hosts:
- name: api domains: ["api. example. com"]
routes:
- match: { prefix: "/v1/payments" }
route:
cluster: payments timeout: 350ms retry_policy:
retry_on: connect-failure,reset,5xx,gateways num_retries: 1 per_try_timeout: 200ms http_filters:
- name: envoy. filters. http. jwt_authn typed_config:
providers:
oidc:
issuer: https://auth. example. com/
remote_jwks:
http_uri: { uri: https://auth. example. com/.well-known/jwks. json, cluster: jwks, timeout: 2s }
cache_duration: 300s forward: true
- name: envoy. filters. http. ext_authz  # OPA/Cedar PDP typed_config:
http_service:
server_uri: { uri: http://opa:8181, cluster: opa, timeout: 50ms }
authorization_request: { allowed_headers: { patterns: [{ exact: "authorization" }, { exact: "x-tenant" }] } }
- name: envoy. filters. http. ratelimit typed_config:
domain: public-api rate_limit_service:
grpc_service: { envoy_grpc: { cluster_name: rl } }
- name: envoy. filters. http. router

5. 2 NGINX/OpenResty: HMAC + Lua + Redis (pseudo)

nginx lua_shared_dict jwks 10m;
lua_shared_dict limits 10m;

server {
listen 443 ssl http2;

Early deny by ASN/Geo if ($bad_asn) { return 403; }

HMAC signature check (webhooks/partners)
set_by_lua_block $sig_ok {
return verify_hmac_signature(ngx. var. http_x_signature, ngx. var. request_time, ngx. var. request_body)
}
if ($sig_ok = 0) { return 401; }

Token bucket in Redis access_by_lua_block {
local key = ngx. var. binary_remote_addr.. ":".. ngx. var. request_uri local allowed, retry_after = ratelimit_allow(key, 50, 100)
if not allowed then ngx. header["Retry-After"] = retry_after return ngx. exit(429)
end
}

proxy_read_timeout 300ms;
proxy_connect_timeout 100ms;
proxy_pass http://app_backend;
}

5. 3 Kong: Plugins entlang der Route

yaml services:
- name: payments url: http://payments:8080 routes:
- service: payments paths: ["/v1/payments"]
plugins:
- name: jwt config: { key_claim_name: kid, secret_is_base64: false, run_on_preflight: false }
- name: opa config: { server_url: "http://opa:8181/v1/data/authz/allow", timeout: 50 }
- name: rate-limiting config: { second: 50, policy: redis, redis_host: redis, fault_tolerant: true }
- name: correlation-id config: { header_name: "traceparent" }
- name: response-transformer config: { add: { headers: ["Strict-Transport-Security:max-age=31536000"] } }

5. 4 Apache APISIX: JWT + Limit + Proxy-Mirror (shadow)

yaml routes:
- uri: /v1/wallets/
plugins:
openid-connect:
client_id: wallet discovery: "https://auth. example. com/.well-known/openid-configuration"
scope: "openid"
limit-count:
count: 100 time_window: 60 key_type: "var"
key: "remote_addr"
proxy-mirror:          # shadow traffic host: "http://shadow-backend:8080"
upstream_id: 1

5. 5 Traefik: Middleware-Kette

yaml http:
middlewares:
hsts-headers:
headers:
stsSeconds: 31536000 stsIncludeSubdomains: true ratelimit:
rateLimit:
average: 50 burst: 100 routers:
api:
rule: "Host(`api. example. com`) && PathPrefix(`/v1`)"
service: app middlewares:
- hsts-headers
- ratelimit

6) Multi-Leasing und Richtlinienversionen

Routing-Schlüssel:'{tenant, plan, region, route, version}'.
Plugins lesen 'tenant' aus dem mTLS-SAN/JWT-Stigma/Header → wenden die Per-Tenant-Limits/Quoten/Regeln an.
Versionieren Sie Richtlinien ('policy _ version'), führen Sie einen Changelog und Kanarienroll aus.

7) Prüfung und Rollout

Vor der Veröffentlichung

Die Vertragsprüfungen der Kette (die Tabelle "wenn"): auth→deny, auth→allow, rate→429, schema→422.
Last: Bursts × 10, lange Plateaus, „schmutzige“ Muster (Slow-POST).
Chaos: Abbau von PDP/JWKS/Redis - muss fail-closed/Abbau zu minimal sicher sein.

Freigabe

'Report-Only '/shadow-mode (Lösungen ohne Anwendung protokollieren).
Kanarische 1-5% des Datenverkehrs + Vergleich der Metriken (p95/p99, 4xx/5xx/429).
Automatische Rollback durch SLO/alert.

8) Beobachtbarkeit und Metriken

• `http_requests_total{route,tenant,plan,status}`
• `request_duration_seconds_bucket{route}` (p95/p99)
• `rate_limited_total{policy}`, `retry_total{reason}`, `circuit_state`
• `authn_fail_total{reason}`, `authz_denied_total{action}`
• `schema_validation_fail_total{route}`
• Traces: Per-Filter-Spans, Attribute' policy _ version', 'tenant', 'limit _ key'.
• Logs (sampled): deny/429/5xx Lösungen mit Ursachen und 'trace _ id'.
• Dashboards: Exec-Zusammenfassung, per-route, per-tenant, „heiße“ Politiker.

9) Sicherheit und Betrieb

Alle Geheimnisse (HMAC, JWKS private, API-Schlüssel) sind in KMS/Vault, nicht in Config-Dateien.
Deny-by-default-Richtlinie für sensible Routen.
Kurze TTL JWKS/PDP Cache, asynchrone Updates mit Backoff.
Migrationen von Transformationsschemata - versioned; „breaking“ - per Dual-Write.
Begrenzen Sie die Körpergröße (DoS) und die Tiefe des JSON.

10) Antipatterns

All-inclusive-Plugins auf jeder Route → zusätzliche Millisekunden und Rechnungen.
Externe Plugin-Abhängigkeiten ohne Cache/Timeouts → kaskadierende Timeouts.
Fehlende Filterreihenfolge: erst Transformationen/Logik, dann Grenzen - falsch.
Hohe Kardinalität der Metrik-Labels (raw 'user _ id '/' ip').
Mischen von authN/authZ in Transformationsmustern (implizite Lösungen in Lua/Jinja).
Protokollierung von Geheimnissen/Token.
Ein globaler Redis/Cluster für alle Limits ohne Sharding/Reserve.

11) Spezifität von iGaming/Finanzen

Per-Tenant/Per-Jurisdiktion-Regeln: KYC/AML, Sanktionen, Grenzen für verantwortungsvolle Zahlungen.
Strenge Richtlinien für Zahlungswege: kurze Timeouts, eine Wiederholung, Idempotency („Idempotency-Key“).
Perimeterseparierung für PSP/KYC SDK (separate Domains/Plugin-Ketten).
Prüfung unveränderlicher Entscheidungsprotokolle (Schlussfolgerungen, Blockaden, Sanktionsverweigerung).

12) Checkliste Prod-Ready

• Die Filterreihenfolge ist definiert: authN → authZ → limits → circuit/timeout → schema → transform → cache.
• Per-Route-Satz von Plugins; schwer - nur dort, wo es nötig ist.
• JWKS/PDP mit kurzer TTL und Cache; Timeouts und Fallback-Strategien.
• Rate/Quota/Concurrency - Schlüssel entworfen, sharding Speicher.
• Satz von RED/USE-Metriken, OTel-Trace, Tail/adaptive-Sampling.
• Kanarische + Schatten-Modus, Auto-Rollback durch SLO.
• Geheimnisse in KMS/Vault; configi - versioniert, mit Migrationen.
• Körper-/Kopfgrenzen; Schutz gegen oversize/slow-POST.
• Kundendokumentation: Codes 401/403/409/422/429/5xx, „Retry-After“, Beispiele für Überschriften.

13) TL; DR

Erstellen Sie eine Kette von „Early Failure → Authentifizierung/Autorisierung → Limits/Robustheit → Validierung → Transformation/Cache → Telemetrie“. Aktivieren Sie nur die erforderlichen Per-Route-Plugins, zwischenspeichern Sie externe Lösungen (JWKS/PDP), legen Sie Zeitfenster und Retry-Richtlinien fest und kontrollieren Sie die Kardinalität der Metriken. Veröffentlichen Sie über shadow/canary, halten Sie Geheimnisse in KMS/Vault und messen Sie die Auswirkungen jedes Plugins auf p95/p99.