Kong API Gateway: הגדרת JWT, Rate Limiting וניטור

Kong API Gateway: הגדרת JWT, Rate Limiting וניטור

בעיה: ניהול API ללא שער מרכזי

ארכיטקטורת מיקרוסרוויסים גדלה במהירות: עשרות נקודות קצה מופיעות, אימות משוכפל, Rate Limiting מיושם אחרת בכל שירות, וניטור מפוצל. ראינו צוותים שמבזבזים שבועות רק כדי להסכים על פורמטי לוגים וחוקי אבטחה. Kong API Gateway — פתרון קוד פתוח המבוסס על nginx/OpenResty — מרכז משימות אלה: ניתוב, פלאגינים (JWT, Rate Limiting, CORS, Prometheus), ותצורה הצהרתית. במשך 7+ שנים פרסנו את Kong ביותר מ-50 פרויקטים, מסטארטאפים ועד ארגונים.

אילו בעיות אנו פותרים

• אימות נפוח: לכל מיקרוסרוויס יש מפענח JWT משלו — כפילות קוד ובאגים. Kong מטפל באימות, מאמת JWT בנקודת הכניסה, ומעביר כותרות פנימיות. זה מקטין את קוד השירות ומגביר את האבטחה.
• Rate Limiting "על הברך": מגבלות בקוד אינן גמישות וקשה לשנותן ללא פריסה מחדש. Kong תומך ב-Rate Limiting עם Redis — עד 100,000 בקשות לדקה לכל צרכן, עם מדיניויות שונות (local, Redis, cluster).
• חוסר ב-observability: ללא נקודה מרכזית קשה לאסוף מדדים. Kong מייצא ל-Prometheus את מספר הבקשות, זמני השהייה (p50/p99), וסטטוסים — ישירות ל-Grafana.

כיצד Kong פותר את בעיית כפילות האימות

Kong משמש כנקודת כניסה יחידה: כל הבקשות עוברות תחילה דרך השער, שם JWT מאומת. אם הטוקן תקף, Kong מוסיף כותרות (x-consumer-id, x-user-id) ומעביר את הבקשה למיקרוסרוויס. השירות יכול לסמוך על כותרות אלה ללא יישום בדיקה משלו. זה מקטין את כפילות הקוד ב-40% ומפחית את הסבירות לשגיאות אבטחה.

כיצד אנו מגדירים את Kong turnkey

אנו משתמשים ב-Kong 3.x (גרסה נוכחית) עם PostgreSQL או במצב DB-less. להלן מחסנית טיפוסית:

---
version: '3.8'
services:
  kong-db:
    image: postgres:15
    environment:
      POSTGRES_DB: kong
      POSTGRES_USER: kong
      POSTGRES_PASSWORD: kong_password
  kong-migration:
    image: kong:3.5
    command: kong migrations bootstrap
    environment:
      KONG_DATABASE: postgres
      KONG_PG_HOST: kong-db
      KONG_PG_USER: kong
      KONG_PG_PASSWORD: kong_password
    depends_on:
      - kong-db
  kong:
    image: kong:3.5
    environment:
      KONG_DATABASE: postgres
      KONG_PG_HOST: kong-db
      KONG_PG_USER: kong
      KONG_PG_PASSWORD: kong_password
      KONG_PROXY_ACCESS_LOG: /dev/stdout
      KONG_ADMIN_ACCESS_LOG: /dev/stdout
      KONG_PROXY_ERROR_LOG: /dev/stderr
      KONG_ADMIN_ERROR_LOG: /dev/stderr
      KONG_ADMIN_LISTEN: 0.0.0.0:8001
      KONG_PROXY_LISTEN: 0.0.0.0:8000, 0.0.0.0:8443 ssl
    ports:
      - "8000:8000"
      - "8443:8443"
      - "8001:8001"
    depends_on:
      - kong-migration
---

באמצעות פקודות Admin API אנו יוצרים שירותים, נתיבים ופלאגינים. דוגמה: הגדרת JWT ו-Rate Limiting על שירות users-api.

# Создать upstream-сервис
curl -X POST http://localhost:8001/services \
  -d name=users-api \
  -d url=http://users-service:3000

# Создать роут
curl -X POST http://localhost:8001/services/users-api/routes \
  -d 'paths[]=/api/v1/users' \
  -d 'strip_path=false'

# JWT плагин
curl -X POST http://localhost:8001/services/users-api/plugins \
  -d name=jwt

# Rate limiting с Redis
curl -X POST http://localhost:8001/plugins \
  -d name=rate-limiting \
  -d config.minute=100 \
  -d config.hour=5000 \
  -d config.policy=redis \
  -d config.redis_host=redis \
  -d config.redis_port=6379 \
  -d config.limit_by=consumer

---
_format_version: "3.0"
services:
  - name: users-api
    url: http://users-service:3000
    routes:
      - paths:
          - /api/v1/users
        strip_path: false
    plugins:
      - name: jwt
      - name: rate-limiting
        config:
          minute: 100
          hour: 5000
          policy: redis
          redis_host: redis
          redis_port: 6379
          limit_by: consumer

תהליך העבודה

1. ניתוח: אנו אוספים דרישות — אילו שירותים, פרוטוקולים, מגבלות, האם נדרש DB-less.
2. עיצוב: תוכנית ניתוב, בחירת פלאגינים, הגדרת רשת (TLS, פילוח).
3. יישום: פריסת Kong, ייבוא תצורה (הצהרתית או דרך Admin API), אינטגרציה עם CI/CD.
4. בדיקות: בדיקות עומס (לדוגמה, 1000 RPS), בדיקות אימות, תקינות.
5. פריסה ותיעוד: אנו מעבירים הוראות, דיאגרמות, לוחות מחוונים של Grafana. מאמנים את הצוות.

מה כלול בעבודה

• פריסת Kong (Docker/Kubernetes/bare metal)
• הגדרת ניתוב, JWT, Rate Limiting, CORS, Request Transformer
• ניטור: Prometheus + Grafana (מזהה לוח מחוונים 7424)
• אינטגרציה עם Redis ל-Rate Limiting
• תיעוד ניהול
• יומיים של הדרכת צוות
• שבועיים של תמיכה לאחר השקה

לוחות זמנים משוערים

מיומיים עסקיים (תצורה בסיסית) עד 7 ימים (עם פריסות canary, HA, DB-less). העלות נקבעת באופן אישי — צרו קשר להערכה.

השוואת מצבי פעולה של Kong

מצב DB-less פשוט יותר לפריסה: אין צורך במסד נתונים, התצורה סטטית ונטענת מחדש בכל שינוי. מצב דינמי עם PostgreSQL מאפשר שינוי הגדרות תוך כדי תנועה דרך Admin API אך מוסיף נקודת כשל. אנו עוזרים לבחור את האפשרות המתאימה לתרחישים שלכם: אם נתיבים משתנים לעתים קרובות, בחרו DB; אם התצורה יציבה, בחרו DB-less.

השוואת פלאגינים פופולריים של Kong

למה לבחור ב-Kong ל-API שלכם?

Kong מהיר בממוצע פי 3 מפתרונות מותאמים אישית מבחינת תפוקה (עד 2 מיליון RPS על צומת יחיד) ויש לו מערכת אקולוגית עשירה של פלאגינים. אנו מבטיחים יציבות: בפרויקטים שלנו, Kong פעל ללא אתחול במשך למעלה מ-6 חודשים.

כיצד אנו מתאימים את Kong לצרכים שלכם

לכל פרויקט אנו מתאימים מצב DB-less או דינמי, בוחרים פלאגינים (key-auth, OAuth2, IP restriction), ומגדירים פריסות canary באמצעות יעדים משוקללים. לדוגמה, אנו מחלקים תעבורה 90%/10% בין גרסאות שירות. צרו קשר לייעוץ — נציע ארכיטקטורה לפרויקט שלכם. הזמינו יישום Kong וקבלו שער API אמין מאפס.