API Gateway бағдарламасындағы плагиндер мен middleware
1) Плагиндер мен middleware не үшін қажет
API-шлюз - корпоративтік саясатты мәжбүрлеп орындату нүктесі. Дұрыс құрастырылған плагиндер тізбегі:- (authN/authZ, WAF, CORS),
- орнықтылықты қорғайды (rate limit, circuit breaker, retry-policies),
- (схемаларды валидациялау, трансформациялау),
- бақылау (метрика, логия, трассировка),
- құнын төмендетеді (кэштеу, дедупликациялау, канареялық ережелер).
Кілт: ең аз жасырындылық және нақты қолдану реттілігі.
2) Плагин кластары және олар не істейді
1. Сәйкестендіру/сәйкестендіру
JWT/JWKS-провайдерлер, OAuth2/OIDC, API-кілттер, mTLS (client cert).
HMAC-қолтаңбалар (вебхактар/серіктестер), DPoP/PoP шетінде.
2. Авторизация
Жергілікті шешімдер кэшімен RBAC/ABAC/OPA/Cedar (PDP).
BOLA-guard: тақырыптағы/мәтінмәндегі 'tenant '/' owner' дегенді тексеру.
3. Желілік және протоколдық қорғаныстар
WAF (OWASP CRS), антибот (rate/behavioral), Geo/IP/ASN-сүзгілер, TLS-профильдер.
CORS, CSP-тақырыптар, Fetch-Metadata сүзгілері, CORP/COOP/COEP.
4. Орнықтылық
Rate limiting (token bucket/GCRA), квоталар және бәсекелестік.
Circuit breaker, таймауттар, adaptive concurrency, load shedding.
Retry-policy per-try timeout және джиттермен.
5. Трансформация және валидация
Жолдар/тақырыптар санағы, body-rewrite, JSON/XML, gRPC, HTTP.
Схемаларды валидациялау (OpenAPI/JSON Schema/Protobuf), ID қалыпқа келтіру.
6. Кэштеу және өнімділік
Response/fragment cache, ETag/If-None-Match, компрессия, brotli.
Бірдей кілттер үшін Request collapsing (coalescing).
7. Бақылау және аудит
RED/USE өлшемдері, шешімдерді логирлеу (429/403/5xx), трассировка (W3C Trace-Context/OpenTelemetry), сэмплинг (tail/adaptive).
Қауіпсіздік тақырыптарының және саясат нұсқаларының аудиті.
8. Өмірлік цикл және пайдалану
Canary/blue-green, feature-flags, shadow-шешімдер (логин жасау, қолданбау), нұсқа көші-қоны.
3) Қолдану тәртібі (ұсынылатын тізбек)
[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
Принцип: бұрын - арзанырақ/фатальді (deny, auth, лимиттер), кейінірек - «косметика» (трансформация, кэш).
4) Өнімділік және түбегейлілік
Ыстық жолда сыртқы сұраусыз O (1) қадамдарды ұстаныңыз.
Плагиндердің барлық «сыртқы қоңыраулары» (PDP/JWKS) - қысқа TTL және asynchronous refresh арқылы.
Метриктер үшін белгілер/лейблдер - шектелген кардиналдық ('tenant', 'plan', 'route', бірақ 'user _ id' емес).
«Ауыр» плагиндер (WAF, body-transform) - per-route селективті қосылады.
5) Конфигурация мысалдары
5. 1 Envoy: JWT + RateLimit + OPA + Retries (жалған)
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 (жалған)
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: бағыт бойынша плагиндер
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 тізбегі
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) Көп жалдау және саясат нұсқалары
Бағыттау кілті: '{tenant, plan, region, route, version}'.
Плагиндер mTLS SAN/JWT-таңбалауынан/→ тақырыбынан «tenant» оқиды.
Саясаттың нұсқасын ('policy _ version'), changelog және канареялық rollout бағдарламаларын жүргізіңіз.
7) Тестілеу және rollout
Шығарылғанға дейін
Тізбектің келісімшарттық тестілері («егер» кестесі): auth → deny, auth → allow, rate → 429, schema → 422.
Жүктелетін: бурсттар × 10, ұзын платолар, «лас» паттерндер (slow-POST).
Chaos: PDP/JWKS/Redis деградациясы - ең аз қауіпсіз fail-closed/деградациясы болуы тиіс.
'Report-Only '/shadow-mode (шешімдерді қолданбай логикалаймыз).
Canary 1-5% трафик + метриктерді салыстыру (p95/p99, 4xx/5xx/429).
SLO/алгоритмдер бойынша автоматты rollback.
8) Бақылау және метрика
Өлшемдері:- `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}`
- Трестер: per-filter, 'policy _ version', 'tenant', 'limit _ key' төлсипаттары.
- Логи (сэмплирленген): себептермен deny/429/5xx шешімдері және 'trace _ id'.
- Дашбордтар: Exec-сводка, per-route, per-tenant, «ыстық» саясат.
9) Қауіпсіздік және пайдалану
Барлық құпиялар (HMAC, JWKS private, API-кілттер) - -файлдарда емес, KMS/Vault-та.
Сезімтал бағыттар үшін deny-by-default саясаты.
Қысқа TTL JWKS/PDP кэші, backoff бар асинхронды жаңартулар.
Трансформация схемаларының көші-қоны - versioned; «сындырушылар» - dual-write арқылы.
body-size (DoS) және JSON тереңдігін шектеңіз.
10) Антипаттерндер
Әр бағыт бойынша әмбебап «барлығы қосылған» плагиндер жиынтығы → артық миллисекундтар мен шоттар.
Кэшсіз/таймаусыз плагиндердің сыртқы тәуелділігі → каскадты таймауттар.
Сүзгілер тәртібінің болмауы: алдымен трансформация/логика, содан кейін лимиттер - дұрыс емес.
Метрлік лейблдердің жоғары кардиналдылығы (raw 'user _ id '/' ip').
Трансформация үлгілерінде authN/authZ араластыру (Lua/Jinja көрінбейтін шешімдер).
Құпияларды/токендерді логикалау.
Шардталмаған/резервсіз барлық лимиттер үшін бір жаһандық Redis/кластер.
11) iGaming/Қаржы ерекшелігі
Қағиданың пер-тенанты/пер-юрисдикциясы: KYC/AML, санкциялар, жауапты төлемдердің лимиттері.
Төлем бағыттары үшін қатаң саясат: қысқа таймауттар, бір қайталау, теңсіздік ('Idempotency-Key').
PSP/KYC SDK үшін периметрлерді бөлу (жеке домендер/плагиндер тізбегі).
Шешімдердің өзгермейтін логының аудиті (қорытындылар, блоктау, санкциялардан бас тарту).
12) Prod-дайындық чек-парағы
- Сүзгілердің тәртібі анықталды: authN → authZ → limits → circuit/timeout → schema → transform → cache.
- Пер-маршруттық плагиндер жиынтығы; ауыр - қажет жерде ғана.
- JWKS/PDP қысқа TTL және кэш; таймауттар мен fallback стратегиялары.
- Rate/Quota/Concurrency - кілттер жобаланған, сақтау орнын шардарлау.
- RED/USE метриктер жиынтығы, OTel трассасы, tail/adaptive сэмплингі.
- Canary + shadow режимі, SLO бойынша auto-rollback.
- KMS/Vault құпиялары; конфигтер - нұсқаланатын, көші-қоны бар.
- body/headers лимиттері; oversize/slow-POST-тан қорғау.
- Клиенттерге арналған құжаттама: 401/403/409/422/429/5xx, 'Retry-After' кодтары, тақырып мысалдары.
13) TL; DR
«Ерте істен шығу → аутентификация/авторизация → лимиттер/тұрақтылық → валидация → трансформация/кэш → телеметрия» тізбегін жасаңыз. Тек қажетті per-route плагиндерін қосыңыз, сыртқы шешімдерді кэштеңіз (JWKS/PDP), таймауттар мен retry-саясатты белгілеңіз, метрикалардың түбегейлілігін бақылаңыз. shadow/canary арқылы шығарыңыз, құпияларды KMS/Vault-да сақтаңыз және әрбір плагиннің p95/p99-ға әсерін өлшеңіз.