Перейти до вмісту

Модуль 9.9: Cloud-Native API Gateways та WAF

Складність: [COMPLEX] | Час на виконання: 2.5 год | Передумови: Модуль 9.3 (Взаємодія з Serverless), основи Kubernetes Ingress

Чому цей модуль важливий

Розділ «Чому цей модуль важливий»

У жовтні 2023 року B2B SaaS-компанія виставила свій API через стандартний Kubernetes NGINX Ingress. Вони налаштували ліміти (rate limiting) через анотації NGINX і почувалися в безпеці. Під час запуску нового продукту бот-мережа конкурента атакувала їхній API цінами: 50 000 запитів на секунду з 12 000 різних IP-адрес. Оскільки атака була розподіленою, ліміт “на один IP” не спрацював. Поди API захлинулися, реальні клієнти бачили помилки 503 протягом 45 хвилин, а компанія втратила три великі контракти.

Ця історія показує різницю між простим роутингом та реальною безпекою. Ingress вміє направляти трафік, але він не захищає від складних атак. Для цього потрібен Web Application Firewall (WAF) та інтелектуальний API Gateway, який бачить не просто IP, а особу користувача, його поведінку та патерни атак.

Цей модуль навчить вас будувати “броньовані двері” для вашого кластера. Ви дізнаєтеся, чим хмарні API-шлюзи відрізняються від Kubernetes Gateway API, як підключити WAF для захисту від SQL-ін’єкцій та ботів, як налаштувати авторизацію через OAuth2/OIDC на рівні входу та як працювати з сучасними протоколами gRPC та WebSockets.


Cloud API Gateways vs Kubernetes Gateway API

Розділ «Cloud API Gateways vs Kubernetes Gateway API»

Це не конкуренти, а різні рівні захисту.

  1. Cloud API Gateway (AWS API GW, Azure APIM): Живе зовні кластера. Його задача: WAF, перевірка ключів API, монетизація, глобальні ліміти та кешування.
  2. Kubernetes Gateway API (Envoy, Istio): Живе всередині кластера. Його задача: маршрутизація за шляхами, розділення трафіку (Canary), TLS та пересилання запитів на поди.

Найкраща практика: Використовуйте хмарний шлюз для безпеки на межі мережі, а внутрішній Gateway API — для гнучкого керування трафіком мікросервісів.


WAF — це інтелектуальний фільтр перед вашим API. Він шукає в запитах ознаки атак:

  • SQL Injection: спроби зламати базу через поля вводу.
  • XSS: спроби вставити шкідливий скрипт.
  • Bot Control: відсікання автоматичних сканерів.
  • Geo-blocking: заборона доступу з певних країн.

Kubernetes Gateway API: Наступне покоління

Розділ «Kubernetes Gateway API: Наступне покоління»

Забудьте про Ingress. Gateway API — це новий стандарт Kubernetes, який дає набагато більше можливостей:

  • HTTPRoute: маршрутизація не тільки за шляхом, а й за заголовками (headers).
  • GRPCRoute: нативна підтримка gRPC.
  • Traffic Splitting: відправка 10% трафіку на нову версію без сторонніх інструментів.
  • Role Separation: адміни керують інфраструктурою (Gateway), а розробники — своїми маршрутами (Route).

Авторизація через OAuth2 Proxy

Розділ «Авторизація через OAuth2 Proxy»

Замість того, щоб писати код перевірки логіна в кожному мікросервісі, винесіть це на рівень шлюзу. OAuth2 Proxy перехоплює запит, перевіряє токен користувача (напр. через Google або Okta) і, якщо все добре, додає заголовок X-Forwarded-User і пропускає запит далі. Ваш додаток просто довіряє цьому заголовку.


ПомилкаЧому це стаєтьсяЯк виправити
Тільки per-IP лімітиПростіше налаштуватиВикористовуйте ліміти за ключами API або токенами користувачів (JWT)
Відсутність WAF”Мій код безпечний”WAF захищає від вразливостей, про які ви ще не знаєте (Zero Day)
gRPC без TLS”Це ж внутрішній трафік”Метадані gRPC можуть містити секрети. Завжди використовуйте TLS
Низькі таймаути для WebSocketsDefault налаштування NGINX (60с)Для WebSockets ставте таймаути 1 годину і більше

1. Чим Kubernetes Gateway API кращий за старий Ingress?

Він набагато гнучкіший. Ingress залежав від анотацій, які відрізнялися у кожного вендора. Gateway API — це чистий стандарт, який підтримує gRPC, TCP, валідацію заголовків та розділення трафіку “із коробки”.

2. Навіщо ставити WAF, якщо в мене вже є Network Policies у Kubernetes?

Network Policies працюють на рівні IP та портів (L3/L4). Вони кажуть “хто куди може ходити”. WAF працює на рівні тексту запиту (L7). Він каже “що саме написано в запиті” і чи не є це спробою зламати ваш додаток.


Практична вправа: Створення маршруту

Розділ «Практична вправа: Створення маршруту»
  1. Встановіть Gateway API CRDs у ваш кластер.
  2. Розгорніть Gateway (напр. на базі Envoy або NGINX).
  3. Створіть HTTPRoute, який:
    • Направляє /v1/* на стару версію додатка.
    • Направляє /v2/* на нову версію.
    • Якщо є заголовок X-Debug: true — направляє запит на спеціальний дебаг-под.
  4. Перевірте маршрутизацію через curl -H.

Переходьте до Модуля 9.10: Data Warehousing та аналітика — ви навчитеся з’єднувати Kubernetes із BigQuery та Redshift, будувати конвеєри даних через Airflow та керувати витратами на аналітику.