Plugins e middleware em API Gateway

1) Para quê são necessários plugins e middleware

• normaliza a segurança (authN/authZ, WAF, CORS),
• protege a sustentabilidade (rate limit, circuito breaker, retry-policies),
• gerenciamento de contrato (validação de esquemas, transformação),
• dá observabilidade (métricas, logs, traçado),
• reduz o custo (armazenamento, dedução, regras de canário).

A chave é latência mínima e uma sequência clara de aplicações.

2) Classes de plugins e o que eles fazem

1. Identificação/autenticação

Provedores JWT/JWKS, OAuth2/OIDC, API chaves, mTLS (cliente cert).
Assinaturas HMAC (webhooks/associados) DPoP/PoP na borda.

2. Autorização

RBAC/ABAC/OPA/Cedar (PDP) com o armazenamento local de soluções.
BOLA-guard: verificação de 'tenant '/' owner' em cabeçalhos/contextos.

3. Defesas de rede e protocolo

WAF (OWASP CRS), antibot (rate/behavioral), Geo/IP/ASN filtros, perfis TLS.
CORS, cabeçalhos CSP, filtros Fetch-Metadata, CORP/COP/COEP.

4. Sustentabilidade

Rate limiting (tocen bucket/GCRA), quotas e competitividade.
Circuito breaker, temporizadores, adaptativa concurrency, load shedding.
Retry-policy com per-try timeout e jitter.

5. Transformação e validação

Censo de caminhos/cabeçalhos, body-rewrite, JSON/ ↔, gRPC ↔ HTTP.
Validação de esquema (OpenAPI/JSON Schema/Protobuf), normalização de ID.

6. Armazenamento em dinheiro e desempenho

Response/fragment cache, ETag/If-None-Match, compressão, brotli.
Request collapsing (coalescing) para chaves iguais.

7. Observação e auditoria

Métricas RED/USE, loging de soluções (429/403/5xx), rastreamento (W3C Trace-Context/OpenTelemetry), sampling (tail/adaptável).
Auditar cabeçalhos de segurança e versões de políticas.

8. Ciclo de vida e exploração

Canary/blue-green, função-flags, soluções shadow (logar, não aplicar), migração de versões.

3) Ordem de aplicação (cadeia 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

Princípio: antes é mais barato/fatal (deny, auth, limites), mais tarde, «cosméticos» (transformações, dinheiro).

4) Produtividade e cardealidade

Mantenha os passos O (1) sem solicitações externas no caminho quente.
Todas as chamadas externas de plugins (PDP/JWKS) são via TTL e asynchronous refresh curtos.
Marcas/editoras para métricas - Cardinalidade limitada ('tenant', 'place', 'road', mas não 'user _ id').
Plugins «pesados» (WAF, body-trans) - incluir seletivamente per-road.

5) Exemplos de configuração

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 na rota

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: Cadeia 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) Multiplicidade e versões de políticas

A chave de rotação é 'se'.
Os plugins leem 'tenant' do mTLS SAN/JWT/cabeçalho → aplicam os limites/quotas/regras para tenante.
Versionize políticas ('policy _ version'), conduza changelog e rollout canário.

7) Testes e rollout

Antes do lançamento

Teste de cadeia contratual (tabela «se»): auth→deny, auth→allow, rate→429, schema→422.
Carga: Burst x 10, platô longo, pattern «sujo» (slow-POST).
Chaos: degradação PDP/JWKS/Redis - deve ser fail-closed/degradação para o mínimo de segurança.

Lançamento

'Relatório-Only '/shadow-modo (logando soluções sem aplicação).
Canary 1-5% de tráfego + comparação de métricas (p95/p99, 4xx/5xx/429).
Rollback automático por SLO/alertas.

8) Observabilidade e 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}`
• Trailers: span per-filter, atributos 'policy _ version', 'tenant', 'limit _ key'.
• Logi (sampleado): soluções deny/429/5xx com causas e 'trace _ id'.
• Dashboard: Resumo exec, per-road, per-tenant, políticas «quentes».

9) Segurança e operação

Todos os segredos (HMAC, JWKS private, API) estão no KMS/Vault, não nos ficheiros config.
Política deny-by-default para rotas sensíveis.
TTL JWKS/cachê PDP curtos, atualizações asincrônicas com backoff.
Migração de esquemas de transformação - versioned; «quebrantes» - via dual-write.
Limite o body-size (DoS) e a profundidade do JSON.

10) Antipattern

Um conjunto universal de plugins «tudo incluído» em cada rota → milissegundos e contas extras.
Dependências externas de plugins sem cachê/temporizador → temporizações em cascata.
Não há ordem de filtros: primeiro transformação/lógica, depois os limites não são corretos.
Alta cardenalidade das tiras (raw 'user _ id '/' ip').
Misturar authN/authZ em modelos de transformação (soluções implícitas em Lua/Ginja).
Regulação de segredos/tokens.
Um Redis/cluster global para todos os limites sem charding/reserva.

11) Especificidades do iGaming/Finanças

Para-tenente/para-jurisdição regras KYC/AML, sanções, limites de pagamentos responsáveis.
Políticas rígidas para rotas de pagamento: tempo curto, uma repetição, idempotidade ('Idempotency-Key').
Separação de perímetros para PSP/KYC SDK (domínios individuais/cadeias de plugins).
Auditar os logs de decisão invariáveis (conclusões, bloqueios, rejeição de sanções).

12) Folha de cheque pró-prontidão

• A ordem de filtros definida é: limits circuito/timeout schema aplicar-se.
• Um conjunto de plugins para-roteiro; Os difíceis só são onde é preciso.
• JWKS/PDP com um TTL curto e um cachê; temporizações e estratégias fallback.
• Rate/Cota/Concurrency - As chaves foram projetadas, o armazenamento em charding.
• Conjunto de métricas RED/USE, traçado OTel, sampling tail/adaptável.
• Modo Canary + shadow, auto-rollback SLO.
• Segredos no KMS/Vault; configh - versionáveis, com migrações.
• Limites body/headers; proteção contra oversize/slow-POST.
• Documentação para clientes: códigos 401/403/409/422/429/5xx, 'Retry-After', exemplos de títulos.

13) TL; DR

Construa uma cadeia de «falha precoce → autenticação/autorização → limites/sustentabilidade → validação → transformação/armazenamento em dinheiro → telemetria». Inclua apenas os plugins per-road desejados, dê ao cante soluções externas (JWKS/PDP), defina os temporizadores e as políticas retry, controle a vitalidade das métricas. Lance por shadow/canary, mantenha segredos em KMS/Vault e mede o impacto de cada plugin em p95/p99.