Plugins y middleware en API Gateway

1) Por qué se necesitan plugins y middleware

• estandariza la seguridad (authN/authZ, WAF, CORS),
• protege la estabilidad (rate limit, circuit breaker, retry-policies),
• gestiona el contrato (validación de esquemas, transformaciones),
• da la observabilidad (métricas, registros, seguimiento),
• reduce el coste (almacenamiento en caché, deduplicación, reglas canarias).

Clave: mínima latencia y clara secuencia de aplicación.

2) Clases de plugins y lo que hacen

1. Identificación/autenticación

Proveedores JWT/JWKS, OAuth2/OIDC, claves API, mTLS (cliente cert).
Firmas HMAC (webhooks/partners), DPoP/PoP en el borde.

2. Autorización

RBAC/ABAC/OPA/Cedar (PDP) con caché de soluciones local.
BOLA-guard: comprobar 'tenant '/' owner' en encabezados/contexto.

3. Protecciones de red y protocolo

WAF (OWASP CRS), antibot (rate/behavioral), filtros Geo/IP/ASN, perfiles TLS.
CORS, encabezados CSP, filtros Fetch-Metadata, CORP/COOP/COEP.

4. Sostenibilidad

Rate limiting (token bucket/GCRA), cuotas y competitividad.
Circuit breaker, timeouts, adaptive concurrency, load shedding.
Política Retry con timeout per-try y jitter.

5. Transformaciones y validación

Censo de paths/heads, body-rewrite, JSON/XML ↔, gRPC ↔ HTTP.
Validación de esquemas (OpenAPI/JSON Schema/Protobuf), normalización de ID.

6. Caché y rendimiento

Response/fragment cache, ETag/If-None-Match, compresión, brotli.
Request collapsing (coalescing) para las mismas claves.

7. Observabilidad y auditoría

Métricas RED/USE, lógica de soluciones (429/403/5xx), rastreo (W3C Trace-Context/OpenTelemetry), sampling (tail/adaptive).
Auditoría de títulos de seguridad y versiones de directivas.

8. Ciclo de vida y explotación

Canary/blue-green, feature-flags, shadow-solutions (lógica, no aplicar), migraciones de versiones.

3) Procedimiento de aplicación (cadena recomendada)

[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: antes - más barato/fatal (deny, auth, limites), más tarde - «cosmética» (transformaciones, caché).

4) Rendimiento y cardinalidad

Siga O (1) pasos sin solicitudes externas en la ruta de acceso caliente.
Todas las «llamadas externas» de los plugins (PDP/JWKS) son a través de TTL cortos y refresco asíncrono.
Etiquetas/etiquetas para métricas - cardinalidad limitada ('tenant', 'plan', 'route', pero no 'user _ id').
Plugins «pesados» (WAF, cuerpo-transformación) - incluir selectivamente por-ruta.

5) Ejemplos de configuraciones

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 a lo largo de la ruta

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: Cadena 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) Multiarrendamiento y versiones de políticas

Clave de enrutamiento: '{tenant, plan, región, ruta, versión}'.
Los plugins leen 'tenant' del sello/encabezado mTLS SAN/JWT → aplican límites/cuotas/reglas.
Versionar las políticas ('policy _ version'), mantener el changelog y el rollout canario.

7) Pruebas y rollout

Antes de la versión

Pruebas contractuales de la cadena (tabla «si acaso»): auth→deny, auth→allow, rate→429, schema→422.
Carga: burst × 10, mesetas largas, patrones «sucios» (slow-POST).
Chaos: Degradación PDP/JWKS/Redis - Debe haber una degradación cerrada/cerrada a la mínima seguridad.

Versión

'Report-Only '/shadow-mode (lógica soluciones sin aplicación).
Canarias 1-5% de tráfico + comparación métrica (p95/p99, 4xx/5xx/429).
Rollback automático por SLO/alertas.

8) Observabilidad y métricas

• `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}`
• Tracks: span per-filter, atributos 'policy _ version', 'tenant', 'limit _ key'.
• Logs (sampled): soluciones deny/429/5xx con causas y 'trace _ id'.
• Dashboards: Exec-sumario, per-route, per-tenant, políticas «calientes».

9) Seguridad y operación

Todos los secretos (HMAC, JWKS private, API-keys) están en KMS/Vault, no en los archivos de configuración.
Política deny-by-default para rutas sensibles.
TTL JWKS/caché PDP cortos, actualizaciones asíncronas con backoff.
Migraciones de esquemas de transformación - versionadas; «rompiendo» - a través de dual-write.
Limite el tamaño corporal (DoS) y la profundidad JSON.

10) Antipattern

Un conjunto universal de plugins «todo incluido» en cada ruta → milisegundos y facturas adicionales.
Las dependencias externas de plugins sin caché/temporizadores → temporizadores en cascada.
Falta de orden de filtros: primero transformaciones/lógica, luego límites - incorrecta.
Alta cardinalidad de las etiquetas métricas (raw 'user _ id '/' ip').
Mezclar authN/authZ en patrones de transformación (soluciones implícitas en Lua/Jinja).
Lógica de secretos/tokens.
Un Redis/clúster global para todos los límites sin cifrado/reserva.

11) Especificidad de iGaming/finanzas

Per-tenant/per-jurisdicción de la regla: KYC/AML, sanciones, límites de pagos responsables.
Políticas duras para las rutas de pago: tiempos cortos, repetición única, idempotencia ('Idempotency-Key').
Separación perimetral para SDK PSP/KYC (dominios/cadenas de plugins individuales).
Auditoría de registros inmutables de decisiones (conclusiones, bloqueos, denegación de sanciones).

12) Lista de comprobación prod

• Se ha definido el orden de los filtros: authN → authZ → limits → circuit/timeout → schema → transform → cache.
• Conjunto de plugins de ruta PER; pesados - sólo donde se necesita.
• JWKS/PDP con TTL corto y caché; taimouts y estrategias fallback.
• Rate/Quota/Concurrency - llaves diseñadas, charding de almacenamiento.
• Conjunto de métricas RED/USE, rastreo OTel, sampling tail/adaptive.
• Canary + shadow-mode, auto-rollback por SLO.
• Secretos en KMS/Vault; configuraciones - versionables, con migraciones.
• Límites de body/headers; protección contra oversize/slow-POST.
• Documentación para clientes: códigos 401/403/409/422/429/5xx, 'Retry-After', encabezados de ejemplo.

13) TL; DR

Construya la cadena «falla temprana → autenticación/autorización → límites/estabilidad → validación → transformación/caché → telemetría». Habilite sólo los plugins por route deseados, almacene en caché las soluciones externas (JWKS/PDP), defina los temporizadores y las políticas retry, controle la cardinalidad de las métricas. Libere a través de shadow/canary, mantenga los secretos en KMS/Vault y mida el impacto de cada plugin en p95/p99.