Plugin e middleware in API Gateway

1) Perché hanno bisogno di plugin e middleware

• standardizza la sicurezza (authN/authZ, WAF, CORS),
• protegge la stabilità (rate limit, circuito breaker, retry-policies),
• gestisce il contratto (convalida degli schemi, trasformazione),
• dà osservabilità (metriche, fogli, tracciabilità),
• riduce i costi (cache, deduplicazione, regole canarie).

Chiave: latitanza minima e sequenza di applicazione chiara.

2) Classi di plugin e cosa fanno

1. Identificazione/autenticazione

Provider JWT/JWKS, OAuth2/OIDC, API, mTLS (client cert).
Firme HMAC (Web Hook/Partner) DPoP/PoP al bordo.

2. Autorizzazione

RBAC/ABAC/OPA/Cedar (PDP) con cache locale delle soluzioni.
BOLA-guard: verifica «tenant »/« owner» nelle intestazioni/contesti.

3. Protezione in rete e protocolli

WAF (OWASP CRS), antibot (rate/behavioral), Geo/IP/filtri ASN, profili TLS.
KORS, intestazioni CSP, filtri Fetch-Metadata, CORP/COOP/COEP.

4. Sostenibilità

Rate limiting (token bucket/GCRA), quote e competitività.
Circuito breaker, timeout, adattativo concurrency, load shedding.
Retry-policy con per-try timeout e jitter.

5. Trasformazione e validazione

Censimento percorsi/titoli, body-rewrite, JSON/XML , HTTP.
Convalida diagrammi (OpenAPI/JSON Schema/Protobuf), normalizzazione ID.

6. Cache e prestazioni

Response/fragment cache, ETag/If-None-Match, compressione, brotli.
Richiest collapsing per le stesse chiavi.

7. Osservazione e verifica

Metriche RED/USE, logica delle soluzioni (429/403/5xx), traccia (W3C Trace-Context/OpenTelemetry), sampling (tail/adattabile).
Controlla le intestazioni di protezione e le versioni dei criteri.

8. Ciclo di vita e funzionamento

Canary/blue-green, feature-flags, soluzioni shadow (logica, non applicazione), migrazioni di versione.

3) Ordine di applicazione (catena consigliata)

[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

Principio: prima è più economico/fatale (deny, auth, limiti), più tardi è «cosmetica» (trasformazione, cache).

4) Prestazioni e cardinalità

Attenersi a O (1) passi senza query esterne nel percorso caldo.
Tutte le «chiamate esterne» dei plugin (PDP/JWKS) sono tramite TTL brevi e asynchronous refresh.
Etichette/etichette per le metriche - Cardinalità limitata («tenant», «plan», «route», ma non «user _ id»).
Plugin «pesanti» (WAF, body-transfer) - Includere selettivamente per-route.

5) Esempi di configurazione

5. 1 Avvoy: 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: plugin lungo il percorso

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: catena middleware

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) Multiforme e versioni delle regole

La chiave di instradamento è «{tenant, plan, region, route, vision}».
I plugin leggono «tenant» dal SAN/JWT/intestazione applicano limiti/quote/regole per tenant.
Versionare i criteri ('policy _ version'), condurre changelog e rollout canario.

7) Test e rollout

Prima del lancio

Test contrattuali della catena (tabella «se»): auth→deny, auth→allow, rate→429, schema→422.
Carichi di lavoro: burst x 10, platee lunghe, pattern «sporchi» (slow-POST).
Chaos: degrado PDP/JWKS/Redis - deve essere fail-closed/degrado al minimo sicuro.

Rilascio

«Report-Only »/shadow-mode (logifichiamo le soluzioni senza applicazione).
Canary 1-5% traffico + confronto metriche (p95/p99, 4xx/5xx/429).
Rollback automatico SLO/alert.

8) Osservabilità e metriche

• `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}`
• Trainer: span per-filter, attributi «policy _ variante», «tenant», «limit _ key».
• Loghi (samplato): soluzioni deny/429/5xx con cause e «trace _ id».
• Dashboard: riepilogo exec, per-route, per-tenant, hot policy.

9) Sicurezza e funzionamento

Tutti i segreti (HMAC, JWKS private, API) sono in KMS/Vault, non nei file config.
Criterio deny-by-default per percorsi sensibili.
TTL JWKS/cache PDP brevi, aggiornamenti asincroni con backoff.
Migrazione di diagrammi di trasformazione - versioned «frastornanti» - tramite dual-write.
Limitare il body-size (DoS) e la profondità di JSON.

10) Antipattern

Un set di plugin universale «tutto incluso» su ogni percorso, per millisecondi e conti in eccesso.
Dipendenze esterne dei plugin senza cache/timeout per timeout a cascata.
La mancanza di ordine dei filtri: prima la trasformazione/logica, poi i limiti non sono corretti.
Alta radicalità delle etichette metriche (raw 'user _ id '/' ip').
Miscelare i authN/authZ nei modelli di trasformazione (soluzioni implicite in Lua/Jinja).
Loging dei segreti/token.
Un Redis/cluster globale per tutti i limiti senza charding/riserva.

11) Specificità iGaming/finanza

Per-tenante/per-giurisdizione delle regole: KYC/AML, sanzioni, limiti dei pagamenti responsabili.
Regole rigide per le rotte di pagamento: timeout breve, ripetizione, idempotenza («Idempotency-Key»).
Separazione dei perimetri per PSP/KYC SDK (singoli domini/catene di plugin).
Controllo dei fogli decisionali invariati (conclusioni, blocchi, disdette).

12) Assegno-foglio prod-pronto

• L'ordine dei filtri è impostato su
• Plugin per-root; Pesanti solo dove si vuole.
• JWKS/PDP con TTL corto e cache timeout e strategie fallback.
• Rate/Quota/Concorrency - Le chiavi sono state progettate, il sistema di archiviazione.
• Set di metriche RED/USE, traccia OTTEL, sampling tail/adattativo.
• Modalità canary + shadow, auto-rollback SLO.
• Segreti in KMS/Vault; confighi - versionabili, con migrazioni.
• Limiti body/headers; protezione da oversize/slow-POST.
• Documentazione client: codice 401/403/409/422/429/5xx, «Retry-After», esempi di titoli.

13) TL; DR

Creare una catena di errore precoce, autenticazione/autorizzazione dei limiti/resilienza, convalida della trasformazione /cache della telemetria. Includere solo i plugin per-route desiderati, mettere in cache le soluzioni esterne (JWKS/PDP), impostare timeout e regole retry, controllare la radicalità delle metriche. Rilasciare attraverso shadow/canary, mantenere i segreti in KMS/Vault e misurare l'impatto di ogni plugin su p95/p99.