שימוש ב-GKE Gateway בתור Agent Gateway נכנס

כשמארחים סוכני AI אוטונומיים או שרתי Model Context Protocol‏ (MCP) באשכולות של Google Kubernetes Engine‏ (GKE), צריך לאבטח את החיבורים הנכנסים מלקוחות חיצוניים, מממשקי שורת פקודה (CLI) למפתחים ומשירותים אחרים. סוכני AI קובעים את נתיבי הביצוע שלהם באופן דינמי, ולכן חומות אש בין רשתות רגילות בשכבה 4 לא יכולות להגן עליהם באופן מלא. באמצעות GKE Gateway API, אתם יכולים לפרוס מאזן עומסים אזורי של אפליקציות כדי לנהל את תעבורת הנתונים הנכנסת (ingress) מהלקוח לסוכן, ולהחיל אמצעי אבטחה ספציפיים ל-AI לפני שהבקשות מגיעות לעומסי העבודה.

אם אתם אדמינים של פלטפורמה או מהנדסי אבטחה שמנהלים את הרשת של GKE, אתם יכולים להשתמש בארכיטקטורה הזו כדי לחשוף סוכנים בניהול עצמי בצורה מאובטחת.

למה כדאי להשתמש ב-Agent Gateway לתעבורת נתונים נכנסת (ingress)?

מיקרו-שירותים רגילים מסתמכים על יחסי תלות סטטיים וצפויים. לעומת זאת, סוכני AI קובעים את נתיבי הביצוע שלהם באופן דינמי על סמך הנחיות המשתמש. כדי לאבטח את דפוסי האינטראקציה הבלתי צפויים האלה, אתם יכולים להמיר GKE Gateway רגיל ל-Agent Gateway, וכך:

  • אכיפת הרשאה מורכבת: אימות הזהות של השירות שמבצע את הקריאה החוזרת וגם ההקשר הסמנטי של המטען הייעודי (payload) של הבקשה בקצה הרשת.
  • הפרדת האבטחה מקוד הנציג: אפשר להחיל מדיניות קפדנית של Mutual TLS‏ (mTLS) והרשאות בלי לדרוש ממפתחי ה-AI לבנות לוגיקת אבטחה מורכבת באפליקציות של הנציגים.
  • הסרה אוטומטית של תוכן זדוני או רגיש מהנחיות: סינון הנחיות נכנסות כדי לזהות מתקפות של החדרת הנחיות או תוכן פוגעני לפני שהן מגיעות למנוע החשיבה הרציונלית של הנציג.

איך פועלת בקרת סוכני Ingress ב-GKE

כדי לנהל את התנועה הנכנסת לסוכנים, משלבים משאבים רגילים של GKE Gateway API עם מדיניות הניהול של Agent Platform:

  • ‫GKE Gateway: פורסים משאב Gateway רגיל (שמוגדר עם GatewayClass מסוג gke-l7-regional-external-managed או gke-l7-rilb) כדי להקצות מאזן עומסים אזורי מסוג HTTP(S) כנקודת הכניסה לרשת.
  • טירגוט של Agent Gateway: יוצרים משאב בהתאמה אישית מסוג GCPAgentGateway שמטרגט את המשאב מסוג Gateway, וממירים את מאזן העומסים ל-Agent Gateway מנוהל.
  • בקרת זהויות ובקרת גישה: החלת GCPAuthzPolicy משאב מותאם אישית כדי לאכוף אמצעי בקרת גישה מבוססי-זהות של שכבה 7. אתם יכולים לאמת את מזהה ה-SPIFFE של הלקוח שמתקשר ולהגביל את הגישה לשיטות MCP ספציפיות או לשמות של כלים (כמו tools/list או tools/call).
  • אבטחת תוכן והרשאות בהתאמה אישית: אפשר לצרף משאב מותאם אישית של Service Extension Binding ל-GCPAgentGateway כדי לנתב את ההנחיות הנכנסות והתשובות היוצאות דרך Cloud de Confiance by S3NSModel Armor, במטרה לחסום התקפות של החדרת הנחיות או להקצות החלטות לגבי הרשאות לספק זהויות (IDP) בהתאמה אישית.

דרישות מוקדמות

כדי להגדיר Agent Gateway נכנס, סביבת GKE צריכה לעמוד בדרישות הבאות:

  • גרסת אשכול GKE: באשכול צריכה לפעול גרסת GKE‏ 1.37.1-gke.1697000 ואילך.
  • ‫Gateway API: צריך להפעיל את GKE Gateway API באשכול.
  • זהות הסוכן: צריך להקצות זהות SPIFFE קריפטוגרפית לעומסי העבודה של הסוכן, כדי שהשער יוכל להעריך כללי מדיניות שמבוססים על זהות. במאמר מידע על Agent Identity ב-GKE מוסבר איך מקצים את הזהויות האלה לפודים.
  • מרשם הסוכנים: צריך לרשום את פריסות הסוכנים כדי שמרשם הסוכנים יוכל לזהות את עומסי העבודה ולסנכרן את המטא-נתונים שלהם. כדי ש-Registry יוכל לגלות את עומסי העבודה ולסנכרן את המטא-נתונים שלהם. כדי לרשום אותם, מוסיפים את התווית registry.gke.io/functional-type: "AGENT" לפריסות.

המאמרים הבאים