דפוסי רשת פרטית עם כמה סוכנים ב-Google Cloud

Last reviewed 2026-04-16 UTC

במסמך הזה מוסבר איך לתכנן תשתית של רשת פרטית שתומכת באפליקציית Gemini Enterprise עם גישה ציבורית, שכוללת כמה סוכנים וחיבורים פרטיים בין סוכנים, סוכני משנה וכלים. עיצוב הרשת מספק חיבורים פרטיים לסוכנים שמתארחים ב-Agent Runtime בפלטפורמת הסוכנים של Gemini Enterprise, ב-Cloud Run, ב-Google Kubernetes Engine‏ (GKE), במרכזי נתונים מקומיים או בעננים אחרים. העיצוב תומך גם בקישור לנציגים שפועלים במיקומים באינטרנט.

מערכות AI מרובות סוכנים כוללות לרוב נתונים רגישים או קנייניים של הארגון. רשת פרטית מאפשרת לכם למנוע את החשיפה של התנועה הזו לאינטרנט הציבורי. העיצוב הזה משתמש בתשתית רשת Google Cloud , במשאבי רשת של ענן וירטואלי פרטי (VPC) ובקישוריות פרטית לסביבות מקומיות או לרשתות חוצות ענן.

בתכנון שמתואר במסמך הזה, סוכנים מתקשרים עם סוכנים אחרים ועם כלים באמצעות פרוטוקול Agent2Agent‏ (A2A) ו-Model Context Protocol‏ (MCP). התקשורת מוצפנת על ידי ניתוב שלה דרך רשת VPC. כדי להעביר תעבורת נתונים אל רשת ה-VPC וממנה, נעשה שימוש בשילוב של נקודות קצה (endpoints) של Private Service Connect, ממשקי Private Service Connect ותעבורת נתונים יוצאת (egress) של Direct VPC ב-Cloud Run. ‫Cloud Next Generation Firewall (Cloud NGFW) שולט בתעבורה שעוברת דרך רשת ה-VPC. שכבות אבטחה נוספות מספקות תעבורת נתונים יוצאת (egress) מבוקרת לאינטרנט באמצעות Secure Web Proxy, ומספקות מדיניות גישה לשירותי API באמצעות גבולות גזרה של VPC Service Controls.

קהל היעד של המסמך הזה כולל אדריכלים, מפתחים ואדמינים שבונים ומנהלים תשתית ענן של AI ואפליקציות. ההנחה במסמך הזה היא שיש לכם הבנה בסיסית של סוכני AI ומודלים, ושאתם מכירים את המושגים שקשורים לרשתות Google Cloud .

תבנית עיצוב לכמה סוכנים

אפליקציית Gemini Enterprise מרובת סוכנים דורשת סוכן מותאם אישית שישמש כסוכן בסיס או כסוכן לניהול תהליכים ליצירת חיבורים לכלי עזר ולסוכני משנה. כדי להטמיע חיבורים פרטיים לכלים ולסוכני משנה שמארחים ב-Google Cloud או בשרתים מקומיים, העיצוב משתמש ברשת VPC עם כתובות IP פרטיות. הסוכן הראשי מתארח בתשתית של Google, באמצעות Agent Engine,‏ Cloud Run או GKE. בדפוס העיצוב של כמה סוכנים מודגשים האינטראקציות הבאות:

  1. אפליקציית Gemini Enterprise באינטראקציה עם סוכני שורש בהתאמה אישית. ‫ אפליקציות Gemini Enterprise מציגות ממשק משתמש מנוהל עם פונקציות אבטחה מובְנות שחושפות פונקציונליות של סוכן בהתאמה אישית. סוכני שורש בהתאמה אישית רשומים ב-Gemini Enterprise וזמינים באפליקציות למשתמשי קצה. הסוכן המותאם אישית ברמה הבסיסית (root) פועל ככלי לניהול תהליכי עבודה ברמה העליונה, והוא מעביר משימות מיוחדות לסוכני משנה. בארכיטקטורה הזו נעשה שימוש בסוכני בסיס מותאמים אישית שמארחים ב-Agent Runtime ב-Gemini Enterprise Agent Platform, ב-Cloud Run או ב-GKE.
  2. סוכנים ראשיים שמקיימים אינטראקציה עם סוכני משנה וכלים. הליבה של תהליך העבודה של מערכת ה-AI והלוגיקה העסקית נמצאת בסוכן הבסיסי ובסוכני משנה ייעודיים. הגמישות במסגרת הסוכן, בזמן הריצה ובפלטפורמת האירוח מאפשרת אפשרויות שונות לחיבור סוכני הבסיס לסוכני משנה ולכלים דרך רשת ה-VPC. באמצעות רשתות VPC בחלק הזה של הארכיטקטורה, סוכנים יכולים להשתמש בנתיבי רשת פרטיים שאתם מגדירים, שחושפים נקודות קצה פרטיות אחרות, אמצעי אבטחה של Enterprise ונגישות רחבה יותר לרשת.

סקירה כללית של ארכיטקטורת רשת מרובת סוכנים.

הארכיטקטורה כוללת את הרכיבים הבאים:

  • אפליקציית Gemini Enterprise: ממשק הקצה שמאפשר למשתמשים לגשת לממשק צ'אט בתוך האפליקציה ולקיים אינטראקציה עם מערכת ה-AI מרובת הסוכנים. המשתמשים יכולים לגשת לאפליקציות Gemini Enterprise דרך האינטרנט הציבורי או באופן פרטי דרך חיבורים היברידיים.
  • סוכנים בהתאמה אישית: סוכני בסיס שנבנים ונרשמים ב-Gemini Enterprise ומתארחים ב-Agent Runtime, ב-Cloud Run או ב-GKE. סוכני הבסיס האלה פועלים ככלי תזמור שמקצים משימות לסוכני משנה.
  • רשת VPC: משאב שאתם שולטים בו כדי לספק לסוכנים קישוריות לרשת IP לנקודות קצה פרטיות ונגישות רחבה יותר לרשת. רשת ה-VPC מספקת פלטפורמה להטמעה של קישוריות פרטית ואמצעי בקרה לאבטחת רשת עבור בקשות של סוכנים לסוכנים ולכלים אחרים.
  • סוכני משנה: סוכנים עם התמחויות שמופעלים על ידי תהליך העבודה של הסוכן ברמה הבסיסית (root). סוכני משנה מתקשרים באמצעות פרוטוקול A2A, שמאפשר אינטראקטיביות בין סוכנים ללא קשר לשפת התכנות ולזמן הריצה.
  • כלים: מערכות מרוחקות שחושפות שירותים כמו ממשקי API, מקורות נתונים ופונקציות של תהליכי עבודה. הכלים האלה מאחזרים נתונים ומבצעים פעולות או טרנזקציות בשביל הסוכנים. הכלים הם חיצוניים לסוכנים, והסוכנים מתחברים לכלים ומקיימים איתם אינטראקציות באמצעות מפרט ה-MCP.

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

VPC משותף

תבנית העיצוב של ריבוי סוכנים משתמשת ב-VPC משותף כדי לרכז את הסמכות והאחריות בנושאי רשת ואבטחה. העיצוב הזה מספק למפתחים סביבות שעוזרות לענות על צורכי האבטחה של הארגון. מומלץ להשתמש ב-VPC משותף כדי לרכז את הגדרות הרשת והאבטחה ולפשט אותן.

בארכיטקטורה של VPC משותף, פרויקט מארח מכיל את משאבי הרשת המשותפים, כולל רשתות VPC, נתבי Cloud, רשתות משנה, חומות אש ו-Cloud DNS. אדמינים יכולים להעניק גישה לפרויקטים של שירותים כדי להשתמש במשאבים האלה. פרויקטים של שירותים מכילים את משאבי זמן הריצה של הסוכן, כולל Agent Runtime,‏ Cloud Run,‏ GKE,‏ Gemini Enterprise ומאזני עומסים ספציפיים לאפליקציה.

ב-VPC משותף יש הפרדה ברורה בין תפקידים של אדמינים של רשתות ואבטחה לבין תפקידים של מפתחי אפליקציות AI:

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

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

אפשר לשלב את רשת ה-VPC המשותפת ב רשת חוצת-עננים באמצעות רכזות (spokes) של VPC ב-Network Connectivity Center ‏(NCC) כדי להוסיף את רשת ה-VPC המשותפת כרשת VPC של עומס עבודה. ההטמעה הזו מספקת ל-VPC המשותף נגישות מלאה לנתיבים של מרכז NCC וקישוריות לנקודות גישה לשירותים ממרכזי משנה אחרים.

בקשות שמופעלות מסוכני בסיס בהתאמה אישית משתמשות ברשת VPC פרטית בניהול הלקוח כדי לספק נתיבי רשת מאובטחים לסוכני משנה, לכלים ולשירותים. הניתוב ברשת ה-VPC קובע את הנגישות לנקודות קצה פרטיות. כללי מדיניות של Cloud NGFW שמוחלים על רשת ה-VPC שולטים בגישה לרשת.

הסוכנים מקבלים גישה מאובטחת לנתיבים פרטיים ברשת VPC, כולל קישוריות ל:

  • רשתות VPC אחרות באמצעות קישור בין רשתות VPC שכנות, מכשירי multi-NIC או NCC.
  • נקודות קצה של Private Service Connect לגישה לשירותים מנוהלים.
  • שירותים מנוהלים עם כתובות IP פרטיות, כמו Cloud SQL.
  • חזיתות של מאזן עומסים פנימי ומשאבי Compute Engine.
  • ממשקי Google API דרך גישה פרטית ל-Google או דרך Private Service Connect.
  • האינטרנט, שנשלט באמצעות Secure Web Proxy.
  • יעדים היברידיים וחוצי-ענן באמצעות Cloud Interconnect,‏ Cloud VPN, מכשיר נתב או SD-WAN.
  • כל יעד של נקודת קצה שאפשר להגיע אליו דרך ניתוב IP ברשת VPC.
  • סוכני AI, כלים ושירותים תומכים אחרים.

מידע נוסף על VPC משותף זמין במקורות המידע הבאים:

רשתות ב-Gemini Enterprise

אפליקציות Gemini Enterprise הן משאבים מנוהלים שפועלים בסביבה מתארחת מחוץ לרשת ה-VPC, אבל בתוך הרשת של Google. בקטעים הבאים מתוארת ההגדרה של רשתות בין המשתמש לבין אפליקציית Gemini Enterprise, ובין האפליקציה לבין הסוכנים.

שיחות של משתמשים עם ממשקי Gemini Enterprise

המשתמשים מתכתבים בצ'אט עם אפליקציית Gemini Enterprise באמצעות אפליקציה מבוססת-דפדפן ששולחת בקשות לממשקי API ולשירותים של Google. כדי להפעיל קישוריות פרטית של משתמשים, אתם יכולים להגדיר שכתובות ה-URL של Google API ינותבו לטווחים של כתובות IP פרטיות שמוגדרות ברשת ה-VPC שלכם. מידע נוסף זמין במאמר הגדרת גישה פרטית לממשק המשתמש.

אפליקציות Gemini Enterprise לסוכנים מותאמים אישית

אתם רושמים סוכנים מותאמים אישית בשירות הגילוי של Gemini Enterprise. כשרושמים סוכן, Gemini Enterprise ממפה את השם של הסוכן ליעד ספציפי, שהוא URI של משאב Agent Runtime או כתובת URL של סוכן A2A. לאפליקציות Gemini Enterprise יש ממשק צ'אט מובנה שנקרא העוזר הדיגיטלי. כשמשתמש מציין סוכן באמצעות @agent_name, או כשהעוזר הדיגיטלי מחליט להעביר את הפנייה לסוכן, האפליקציה מחפשת את הסוכן במרשם כדי למצוא את נקודת הקצה המשויכת.

כשרושמים סוכן ראשי ב-Gemini Enterprise, אפשר לפרוס את הסוכן הזה בכל מקום כסוכן בהתאמה אישית. סוכנים בהתאמה אישית ב-Agent Runtime וב-Cloud Run יכולים להשתמש בנתיבים קיימים ברשת פרטית בלי להגדיר משאבי רשת נוספים. כדי לפרוס סוכן בהתאמה אישית ב-GKE, צריך לחשוף את השירות באמצעות שער חיצוני. מידע על הגדרת שער חיצוני מאובטח יותר מופיע בהמשך המאמר בקטע רשתות GKE.

כדי לשלוח בקשות לסוכנים בהתאמה אישית, Gemini Enterprise משתמש בזהות של חשבון Discovery Engine Service ב-Gemini Enterprise Agent Platform. נתיב הרשת ומנגנוני ההרשאה משתנים בהתאם לפלטפורמת האירוח שבה אתם משתמשים:

  • סוכנים בהתאמה אישית ב-Agent Runtime: סוכן השירות של Agent Platform Discovery Engine כולל את התפקידים הדרושים של ניהול זהויות והרשאות גישה (IAM) ב-Agent Platform כדי להפעיל משאבים של Agent Runtime כמאפיין מובנה. המערכת מנתבת בקשות שמוגשות לשירות Agent Platform API ברשת Google כקריאה פנימית ל-API.
  • סוכנים בהתאמה אישית ב-Cloud Run: אפליקציות Gemini Enterprise משתמשות בזהות של סוכן שירות Discovery Engine של Agent Platform כדי לבצע קריאות לכתובת ה-URL היציבה run.app שרשומה בכרטיס הסוכן. כדי ששירות Cloud Run של סוכן ה-AI יאשר את הקריאות האלה, צריך להקצות לסוכן השירות של Discovery Engine את תפקיד ה-IAM‏ Cloud Run Invoker‏ (roles/run.invoker). בקשות ל-Cloud Run מנותבות דרך רשת הייצור של Google אל ממשק הקצה של Google‏ (GFE) לכניסה ל-Cloud Run.

  • סוכנים בהתאמה אישית ב-GKE: אפליקציות של Gemini Enterprise משתמשות בזהות של סוכן השירות Agent Platform Discovery Engine כדי לבצע קריאות לכתובת ה-URL שרשומה בכרטיס הסוכן. מערכת DNS ציבורית צריכה להיות מסוגלת לתרגם את שם המארח לכתובת IP חיצונית שמנוהלת על ידי השער. מומלץ להשתמש בgke-l7-regional-external-managed מאזן העומסים או במאזן העומסים gke-l7-global-external-managed. כדי להוסיף שכבת אבטחה, מומלץ ש-Gemini Enterprise יתקשר עם סוכן A2A שמתארח ב-GKE באמצעות שרת proxy לאימות זהויות (IAP). כדי ש-IAP יאשר את הקריאות האלה, צריך להעניק לסוכן השירות של Discovery Engine את תפקיד IAM של משתמש באפליקציית אינטרנט שמוגנת באמצעות IAP ‏(roles/iap.httpsResourceAccessor). רשת הייצור של Google מנתבת בקשות ל-GKE אל GFE עבור כניסה למאזן עומסים של אפליקציות (ALB) חיצוני.

    כדי לאבטח את GKE Ingress מ-Gemini Enterprise, אפשר לעיין בקטעים IAP ו-Google Cloud Armor בהמשך המאמר הזה.

רשת פרטית לפלטפורמות אירוח של נציגים

אחרי שמשתמש שולח בקשה לאפליקציית Gemini Enterprise, בקשות נשלחות מסוכני שורש מותאמים אישית לסוכני משנה ולכלים. פלטפורמות אירוח של סוכנים בהתאמה אישית מספקות את הממשק בין Gemini Enterprise לבין רשתות ה-VPC שלכם. פלטפורמות האירוח של הסוכנים והכלים בקונטיינרים הן Agent Runtime,‏ Cloud Run ו-GKE.

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

אתם יוצרים קישוריות פרטית ל-VPC באמצעות מנגנונים שונים, בהתאם לפלטפורמת אירוח הסוכן שבה אתם משתמשים:

  • סוכנים בהתאמה אישית ב-Agent Runtime: ממשקי Private Service Connect מקשרים בין זמני הריצה של Agent Runtime לבין רשת ה-VPC. יוצרים קובץ מצורף לרשת ברשת משנה של רשת ה-VPC ומעניקים ל-Agent Runtime הרשאה לצרף אותו. תעבורת הנתונים שנשלחת מ-Agent Runtime מופיעה ברשת ה-VPC כאילו היא הגיעה מכתובת ה-IP של רשת המשנה של הקובץ המצורף. לאחר מכן, רשת ה-VPC מנתבת את התנועה לכתובת ה-IP המתאימה של היעד.
  • סוכנים בהתאמה אישית ב-Cloud Run: תעבורת נתונים יוצאת (egress) ישירה של VPC ב-Cloud Run מחברת את המכונות של שירות Cloud Run לרשת ה-VPC. רשת ה-VPC שמצוינת כשפורסים שירות Cloud Run יכולה להיות מפרויקט שירות Cloud Run או מפרויקט מארח של VPC משותף. תעבורת נתונים שנשלחת מ-Cloud Run מופיעה ברשת ה-VPC כאילו היא הגיעה מכתובת ה-IP של רשת המשנה של Direct VPC egress. לאחר מכן, רשת ה-VPC מנתבת את התנועה לכתובת ה-IP המתאימה של היעד.
  • סוכנים בהתאמה אישית ב-GKE: אשכולות GKE נמצאים ישירות ברשת ה-VPC ומשתמשים בכתובות IP של רשתות משנה מקומיות. כברירת מחדל, תעבורת היציאה של GKE משתמשת בכתובת ה-IP של ה-Pod ככתובת ה-IP של המקור. אם מגדירים מיסוך, תעבורת היציאה של GKE משתמשת בכתובת ה-IP של הצומת ככתובת ה-IP של המקור. כל תעבורת הנתונים היוצאת (egress) של GKE מנותבת על ידי רשת ה-VPC.

בקטעים הבאים מפורטות הנחיות נוספות לניהול בקשות תעבורת נתונים נכנסת (ingress) ותעבורת נתונים יוצאת (egress) אל רשת VPC וממנה לכל פלטפורמת אירוח של סוכן. השיקולים לגבי הרשת רלוונטיים גם לפונקציונליות של סוכן הבסיס וגם לפונקציונליות של סוכן המשנה.

Agent Runtime networking

בקטע הזה מוסבר על רשתות פרטיות לסוכנים ראשיים ולסוכני משנה שמארחים ב-Agent Runtime. אם אתם משתמשים ב-Agent Runtime כדי לארח את סוכן הבסיס, אתם צריכים לפרוס את Gemini Enterprise ואת Agent Runtime באותו פרויקט.

Agent Runtime מארח קונטיינרים בתשתית Google מחוץ לרשת ה-VPC שלכם. כדי להפעיל קישוריות פרטית לסוכנים אחרים, אתם יכולים לחבר את הסוכן לרשת ה-VPC באמצעות השיטות הבאות:

כדי לאפשר בקשות בין הסוכנים שלכם לבין סוכנים אחרים, צריך להגדיר את שני החיבורים הקודמים.

תעבורת יציאה (egress) של Agent Runtime לרשת VPC

סביבת זמן הריצה של הסוכן משתמשת בפרויקט דייר שמנוהל על ידי Google ליציאה מהרשת. הרשת של הדייר מספקת קישוריות לסוכנים לממשקי Google API ולתעבורת נתונים יוצאת לאינטרנט הציבורי, אבל כברירת מחדל היא לא מחוברת ישירות לרשתות ה-VPC של הלקוח.

כדי לחבר סוכנים למשאבים שנמצאים בתוך רשת ה-VPC שלכם, Agent Runtime משתמש ב ממשקי Private Service Connect. הכלי Agent Runtime פורס ממשק רשת בפרויקט הדייר שמתחבר למשאב network attachment בפרויקט שלכם. החיבור הזה יוצר נתיב נתונים מאובטח בין זמן הריצה של Agent Runtime לבין רשת ה-VPC. כשמגדירים ממשק Private Service Connect בפרויקט Agent Runtime, המערכת מנתבת את כל תעבורת הנתונים של הסוכן שלא מיועדת ל-Google APIs לרשת ה-VPC.

כדי לפרוס תעבורת נתונים יוצאת (egress) ברשת VPC של Agent Runtime, אפשר לעיין במקורות המידע הבאים:

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

תעבורת נכנסת של Agent Runtime מרשת ה-VPC

בקשות לסוכנים שפועלים ב-Agent Runtime נשלחות באמצעות נקודת קצה ל-API של Agent Platform ‏ (aiplatform.googleapis.com). כדי להגיע לנקודות קצה של Google API באמצעות נתיבי רשת פרטיים מרשת ה-VPC, צריך להשתמש בגישה פרטית ל-Google או בנקודות קצה של Private Service Connect ל-Google APIs.

משתמשים פרטיים שמבצעים שאילתות לסוכנים צריכים לפתור את שם המארח של נקודת קצה ל-API של Agent Platform לטווח כתובות ה-IP הפרטיות של גישה פרטית ל-Google או לכתובת ה-IP של נקודת הקצה של Private Service Connect ל-Google APIs. אזור פרטי מנוהל של Cloud DNS‏ ל-googleapis.com פותר בקשות ל-Agent Platform API. רשת ה-VPC מנתבת את הבקשה ישירות דרך רשת הייצור של Google.

אם אתם משתמשים בגישה פרטית ל-Google או ב-Private Service Connect ל-Google APIs, תוכלו להגן על התנועה מרשת ה-VPC אל Agent Runtime באמצעות המוצרים והתכונות הבאים:

שיקולים נוספים לגבי הרשת של Agent Runtime

תעבורת נתונים יוצאת (egress) של Agent Runtime שמשתמשת בממשקי Private Service Connect יכולה להתבצע רק לטווחים של כתובות IP מסוג RFC 1918 ברשת ה-VPC. למידע על טווחי יעד ספציפיים שלא ניתן לנתב באמצעות תעבורת נתונים יוצאת (egress) של Agent Runtime, אפשר לעיין במאמר דרישות לגבי טווח כתובות IP של רשת משנה. כדי להגיע ליעדים של טווח כתובות IP שלא ניתן לנתב, צריך להשתמש בהגדרת שרת proxy מפורשת בסוכנים ולפרוס משאבי proxy שמשתמשים בכתובת IP שניתנת לניתוב ברשת ה-VPC.

כשפורסים את Agent Runtime בלי ממשק Private Service Connect, יש לו גישה לאינטרנט כברירת מחדל. כדי להגן מפני זליגת נתונים, צריך להשבית את הגישה שמוגדרת כברירת מחדל ולהפעיל את VPC Service Controls.

כשפורסים את Agent Runtime עם ממשק Private Service Connect, תעבורת נתונים יוצאת (egress) ישירה באינטרנט מושבתת, ללא קשר ל-VPC Service Controls. אם אתם צריכים שהסוכן שלכם יגש ליעד ש-Agent Runtime לא יכול להגיע אליו בדרך כלל, כמו האינטרנט, אתם צריכים לבצע את הפעולות הבאות:

  1. מגדירים Secure Web Proxy ברשת משנה RFC 1918 של רשת ה-VPC. צריך להגדיר את ה-proxy במצב ניתוב מפורש של שרת proxy.
  2. יוצרים רשומת Cloud DNS עבור שם המארח של שרת ה-Proxy המאובטח באינטרנט.
  3. מגדירים DNS peering עבור Agent Runtime כדי לתמוך בפענוח של שאילתות DNS של סוכנים לכתובת הפרטית של Secure Web Proxy ברשת ה-VPC.
  4. כשפורסים סוכנים, צריך לבצע את הפעולות הבאות:
    1. מגדירים משתני סביבה כדי להשתמש ב-proxy מפורש על ידי ציון שם המארח והיציאה של Secure Web Proxy.
    2. אם אתם ניגשים ליעד פרטי, צריך להגדיר אזור DNS פרטי עבור היעד הזה.

אחרי שתעבורת הנתונים מ-Agent Runtime יוצאת ומגיעה לרשת ה-VPC, היא יכולה להגיע לכל יעד ברשת שאפשר להגיע אליו דרך רשת ה-VPC. מידע על הגבלת היקף היעדים ברשת היציאה שזמינים לסוכני Agent Runtime מופיע בקטע Cloud NGFW בהמשך המאמר.

רשתות ב-Cloud Run

בקטע הזה מוסבר על רשתות פרטיות לסוכנים ראשיים ולסוכני משנה שמארחים ב-Cloud Run. שירות Cloud Run מארח קונטיינרים בתשתית של Google מחוץ לרשת ה-VPC שלכם. כדי להפעיל קישוריות פרטית לסוכנים אחרים, אתם יכולים לחבר את הסוכן לרשת ה-VPC באמצעות השיטות הבאות:

כדי לאפשר בקשות בין הסוכנים שלכם לבין סוכנים אחרים, צריך להגדיר את שני החיבורים הקודמים.

תעבורה יוצאת (egress) מ-Cloud Run לרשת VPC

כדי ליזום חיבורים של Cloud Run לרשת VPC, מומלץ להשתמש בDirect VPC egress. כשמשתמשים ב-Direct VPC egress, מופעים של Cloud Run מתחברים ישירות לרשת ה-VPC המשותפת באמצעות כתובת IP מרשת המשנה שמציינים כשפורסים Direct VPC egress.

כשמגדירים Direct VPC egress, צריך לבצע את הפעולות הבאות:

  1. מגדירים את רשת המשנה של היעד עם גישה פרטית ל-Google מופעלת.
  2. מגדירים ניתוב תנועה כדי לנתב את כל התנועה לרשת ה-VPC.

במסגרת ההגדרה הזו, כל התעבורה עוברת דרך רשת ה-VPC כדי לשמור על הפרטיות, והבקשות מ-Cloud Run אל ממשקי Google API אחרים עוברות דרך הרשת הפנימית של Google.

כל שאילתות ה-DNS מ-Cloud Run משתמשות במדיניות ובאזורים של Cloud DNS שמשויכים לרשת ה-VPC. אין צורך בהגדרות נוספות של שיתוף פעולה בין שרתי DNS. סוכנים שמארחים ב-Cloud Run פותרים את כל התחומים הפרטיים ב-Cloud DNS ואת שמות המארחים הציבוריים.

בהמשך המאמר הזה מוסבר איך לאבטח עוד יותר את הסוכנים ואת רשת ה-VPC עבור תעבורת היציאה של Cloud Run:

תעבורת נתונים נכנסת (ingress) ב-Cloud Run מרשת ה-VPC

‫Cloud Run היא פלטפורמה שמנוהלת על ידי Google ופועלת בסביבה מחוץ לרשת ה-VPC. בסביבה הזו מתארחת נקודת הקצה היציבה של כתובת ה-URL של שירותי Cloud Run שמריצים עומסי עבודה של סוכני AI או כלים.*.run.app נקודות הקצה האלה מוגשות על ידי אותה נקודת כניסה של GFE שמשרתת שירותי API של *.googleapis.com. ‫Cloud Run משתמש באותם נתיבי רשת בסיסיים שמאפשרים קישוריות פרטית ל-גישה פרטית ל-Google ול-Private Service Connect ל-Google APIs.

משתמשים פרטיים ברשת VPC שמבצעים שאילתות לסוכנים או לכלים צריכים לפתור את שם המארח run.app לטווח כתובות ה-IP הפרטיות של גישה פרטית ל-Google או לכתובת ה-IP של נקודת הקצה של Private Service Connect עבור Google APIs. אזור פרטי מנוהל של Cloud DNS עבור כתובת ה-URL‏ run.appמפענח בקשות לשירותי Cloud Run. רשת ה-VPC מנתבת את הבקשה ישירות דרך רשת הייצור של Google.

הגדרת תעבורת נתונים נכנסת (ingress) של Cloud Run לפנימית מגבילה את הגישה לשירות, ומאפשרת בקשות רק ממקורות פנימיים מאומתים. מקורות מאושרים כוללים את המקורות הבאים:

  • רשתות VPC של פרויקט השירות Cloud Run.
  • רשת ה-VPC המשותפת שמארחת את נקודת היציאה של Direct VPC.
  • משאבים שנמצאים באותו היקף של VPC Service Controls.
  • מאזני עומסים פנימיים של אפליקציות (ALB) ברשת ה-VPC.
  • שירותי Google כמו Cloud Scheduler ו-Pub/Sub שנמצאים בפרויקט השירות או ב-service perimeter של VPC Service Controls.

אם לא משתמשים בגבולות גזרה משותפים של VPC Service Controls כדי לכלול גם את השירותים שקוראים לשירותים אחרים וגם את השירותים שאליהם קוראים, התנועה שמגיעה מחוץ לפרויקט השירות של Cloud Run או לסביבת ה-VPC המשותף נחשבת לתנועה חיצונית. תנועה כזו כוללת תנועה משירותים אחרים של Google Cloud Cloud Run, כמו Agent Runtime. כדי לעבור את הבדיקה של תעבורת נתונים נכנסת פנימית ב-Cloud Run, צריך לנתב את התעבורה כך שהיא תיראה כאילו היא מגיעה מתוך רשת ה-VPC של שירות היעד.

כדי לספק את השיוך הנדרש לרשת הפנימית, אפשר לבצע אחת מהפעולות הבאות:

  • אתם יכולים להשתמש בנקודות קצה של Private Service Connect כדי לאפשר לשירותים בפרויקטים או ברשתות VPC אחרות להתחבר לממשקי Google APIs ולשירותים של Google, כולל שירות Cloud Run שלכם, באמצעות כתובת IP פרטית ברשת ה-VPC שלכם.
  • ניתוב תעבורה דרך מאזן עומסים פנימי של אפליקציות (ALB) שמוצב בתוך רשת ה-VPC לפני שירות Cloud Run. מאזן העומסים מעביר בקשות משירותים אחרים דרך רשת ה-VPC, כדי שהן יעמדו בקריטריונים של תעבורת נתונים פנימית.

מאזני עומסים פנימיים של אפליקציות עם קצוות עורפיים של קבוצת נקודות קצה ברשת (NEG) בלי שרתים יוצרים משאב VPC שממופה ישירות לשירות Cloud Run. בדגם הזה, מאזן העומסים סוגר את חיבורי ה-TLS של הלקוח באמצעות אישור מהימן. מאזני עומסים פנימיים של אפליקציות תומכים באמצעי בקרה נוספים לאבטחה, כולל כללי מדיניות לאבטחת קצה עורפי של Cloud Armor וכללי מדיניות נוספים להרשאה.

כברירת מחדל, כדי לגשת לכל שירותי Cloud Run נדרש אימות IAM. מומלץ להשתמש בזהות לכל שירות בנפרד ולהקצות לחשבון המשתמש את תפקיד ה-IAM‏ Cloud Run Invoker‏ (roles/run.invoker).

מידע על הגדרת אמצעי בקרה לכניסה ב-Cloud Run זמין במקורות המידע הבאים:

אם אתם משתמשים בגישה פרטית ל-Google או בנקודות קצה (endpoints) של Private Service Connect ל-Google APIs כדי לשלוח תנועה מרשת ה-VPC שלכם אל Cloud Run, אתם יכולים להשתמש במוצרים ובתכונות הבאים כדי להגן על התנועה הזו:

אם אתם משתמשים במאזן עומסים של אפליקציות (ALB) פנימי כדי לשלוח תעבורת נתונים מרשת ה-VPC אל Cloud Run, תוכלו להשתמש במוצרים ובתכונות הבאים כדי להגן על תעבורת הנתונים הזו:

GKE networking

בקטע הזה מתואר ה-Networking של סוכנים שמבוססים על GKE.

‫GKE ו-Gemini Enterprise

‫GKE מארח סוכני AI וכלים, ומציע פלטפורמה שניתנת להתאמה אישית גבוהה לצורך בקרה על הרשת והאבטחה. מערכת מרובת סוכנים מבוססת-AI שנפרסת ב-GKE יכולה לספק יעילות תפעולית בהיקף נרחב. הוא יכול להשתלב בצורה חלקה עם אפליקציות אחרות של Kubernetes ועם ארכיטקטורות גדולות יותר של מיקרו-שירותים.

אשכולות GKE הם צמתים של מכונות וירטואליות ב-Compute Engine שפועלים בתוך רשת משנה של רשת ה-VPC. אפליקציות Gemini Enterprise הן משאבים מנוהלים שפועלים בסביבה מתארחת מחוץ לרשת ה-VPC. כדי לאפשר לאפליקציות Gemini Enterprise לקרוא לסוכנים מותאמים אישית שמתארחים ב-GKE, צריך לחשוף בצורה מאובטחת שער חיצוני עם כתובת IP ציבורית ושם DNS. תעבורת הנתונים יוצאת מ-Gemini Enterprise לרשת הקצה של Google, שם היא עוברת בנתיב ממוטב למאזן העומסים החיצוני של GKE.

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

מצב הפעולה של GKE

‫GKE מציע את מצבי הפעולה הבאים כדי לאזן בין ניהול ובקרה:

  • ‫Autopilot: ‏ Google מבצעת אוטומציה של כל תשתית אשכולות GKE, כולל מישור הבקרה, הקצאת צמתים, חיזוק האבטחה והתאמת קנה מידה.
  • ‫Standard: Google מנהלת את מישור הבקרה. אתם אחראים באופן מלא להגדרות של מאגרי הצמתים, כמו בחירת סוגי מכונות, ניהול קובצי אימג' של מערכות הפעלה ושינוי גודל ידני.
הקשחת התשתית ומישור הבקרה
  • אשכולות GKE פרטיים: הקצאת צמתים ללא כתובות IP ציבוריות, כדי להבטיח שסביבת זמן הריצה מבודדת מחשיפה ישירה לאינטרנט.
  • רשתות מורשות ראשיות: הגבלת גישת אדמין ל-Kubernetes API לטווחי כתובות IP ספציפיים ומהימנים, כדי להקשיח את מישור הבקרה מפני שינויים לא מורשים בהגדרות. מאבטחים את נקודת הקצה של DNS עבור Kubernetes API באמצעות IAM ו-VPC Service Controls של Google Cloud.
זהות וגישה (אפס אמון)
  • ‫IAP: פועל כשומר סף ברמת מאזן העומסים. הוא מבטיח שרק משתמשים מאומתים עם הרשאות IAM מתאימות יוכלו לגשת לנקודת הקצה של הסוכן. הגישה הזו מעבירה את ההיקף של האבטחה מהרשת למשתמש הבודד ולהקשר של המכשיר שלו.
הגנה על קצה הרשת וניהול תנועה
  • ‫Cloud Armor: מספק אבטחה חזקה בקצה הרשת, כולל כללים של חומת אש ליישומי אינטרנט (WAF) שעוזרים לחסום תכנים זדוניים, הגנה מפני DDoS שעוזרת להבטיח זמן פעולה רציף והגבלת קצב שעוזרת למנוע ניצול יתר של שירותים.
  • ‫הגנה מוגברת על המודל: תכונה שנועדה במיוחד לאבטחת מודלים גדולים של שפה (LLM). היא בודקת ומסירה פרומפטים ותגובות בזמן אמת כדי למנוע החדרת פרומפטים וזליגת נתונים.
בידוד של רשת פנימית
  • כללי מדיניות של רשת Kubernetes: אכיפה של תקשורת מפורטת עם הרשאות מינימליות בין מיקרו-שירותים. כברירת מחדל, כללי המדיניות דוחים את כל התנועה, אלא אם מאשרים אותה באופן מפורש. כך נמנעת תנועה לרוחב בתוך האשכול.

תעבורה יוצאת (egress) מ-GKE לרשת VPC

רשת ה-VPC מנתבת חיבורים יוצאים מסוכנים שמארחים ב-GKE. מצב הרשת של אשכול GKE שמוגדר כברירת מחדל הוא VPC-native, והוא מספק את המאפיינים הבאים:

  • אשכול GKE משתמש בטווחי כתובות IP של כינויים.
  • כתובות ה-IP של ה-Pod שמורות על ידי ציון טווח כתובות ה-IP של ה-Pod.
  • אפשר להגדיר ניתוב של כתובות ה-IP של הפודים באופן מקורי ברשת ה-VPC של האשכול וברשתות VPC אחרות שמקושרות אליה.

אם Pod של סוכן מתקשר עם Pod של סוכן משנה באותו צומת, התנועה מנותבת באופן מקומי במרחב השמות של רשת הצומת. אם יעד ה-Pod של הסוכן נמצא בצומת אחר באשכול, התנועה מנותבת באמצעות טבלת הניתוב של רשת ה-VPC. כדי ש-Pod של סוכן יוכל לתקשר עם משאבי VPC אחרים, כמו מאזני עומסים או נקודות קצה של Private Service Connect, הוא יכול להגיע ליעד באמצעות אותה מערכת ניתוב סטנדרטית של VPC, בכפוף לכללי חומת האש.

אתם יכולים להשתמש במוצרים ובשירותים הבאים כדי להגן על התנועה שיוצאת מאשכול GKE:

תעבורת Ingress מ-GKE מרשת ה-VPC

שירותים של Kubernetes מספקים גישה למשאבי GKE. למערכת AI מרובת סוכנים, מומלץ להשתמש ב-GKE Gateway או ב- GKE Inference Gateway. השער מספק יכולות משופרות של בקרת תעבורה, הפרדה תפעולית של משאבים ושילובים של אבטחה. עם זאת, יש אפשרויות אחרות לשירותי כניסה בהתאם לדרישות המערכת.

משאב ה-Gateway יוצר מאזן עומסים של אפליקציות ומקצה את כל רכיבי איזון העומסים הנדרשים. קבוצות נקודות הקצה ברשת בקצה העורפי של השירות מחוברות כדי לספק איזון עומסים ישירות למאגרי נתונים. כדי לחשוף שירות באופן פנימי לתעבורה שמגיעה מרשת ה-VPC, משתמשים במחלקות Gateway למאזן עומסים פנימי אזורי של אפליקציות (gke-l7-rilb) או למאזן עומסים פנימי חוצה-אזורים של אפליקציות (gke-l7-cross-regional-internal-managed-mc).

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

  • ‫Cloud Armor: מגן על שירותים על ידי צירוף של כללי מדיניות האבטחה של Cloud Armor לשירותי ה-Backend שמנוהלים על ידי שער. הוא מספק סינון WAF, סינון לפי כתובת IP ומיקום גיאוגרפי, הגנה מפני DDoS והגבלת קצב לפני שהתנועה מגיעה לאשכול GKE או ל-IAP.
  • ‫IAP: מופעל בשירות לקצה העורפי כדי לשלוט בגישה לאפליקציות באמצעות פרטי כניסה ל-IAM. ‏IAP אוכף מדיניות גישה של אפס אמון. שרת IAP מאמת ומאשר את סוכני ה-AI שמקבלים גישה למשאבי האשכול, כולל אפליקציות Gemini Enterprise, סוכנים בהתאמה אישית ומשאבים חיצוניים. כדי להשתמש בו, למי שמבצע את הקריאה צריכה להיות זהות שאומתה על ידי IAM והרשאה לגשת לשירות העורפי.

אם אתם שולחים תנועה מרשת ה-VPC לשירות GKE דרך שער, אתם יכולים להגן על התנועה הזו באמצעות המוצרים והתכונות הבאים:

אם אתם לא משתמשים בשער כדי לשלוח תנועה מרשת ה-VPC לשירות GKE, אתם יכולים להשתמש במוצרים ובשירותים הבאים כדי להגן על התנועה הזו:

מידע נוסף על אבטחת GKE זמין במאמרים שיטות מומלצות לאבטחת רשת והסבר על אבטחת רשת ב-GKE.

אבטחת רשת של סוכנים

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

Cloud NGFW

‫Cloud NGFW פועל כשומר הסף ברמת הרשת כדי לאבטח תקשורת A2A ו-MCP. חומת האש מוודאת שרק תעבורה מורשית יכולה להגיע לנקודות הקצה של הנציגים. לשם כך, היא מאמתת כל חיבור נכנס או יוצא אל נציגים וכלים אחרים וממנו.

‫Cloud NGFW הוא שירות חומת אש מבוזרת שמוטמעת בבד של רשת ה-VPC. הוא מציע את רמות התכונות האלה שפועלות בשכבות שונות של מחסנית הרשת:

  • ‫Cloud Next Generation Firewall Essentials: מספק סינון מנות של חומת אש עם שמירת מצב. כללי המדיניות מוגדרים על סמך כתובות IP (שכבה 3), פרוטוקולים ויציאות (שכבה 4).
  • ‫Cloud Next Generation Firewall Standard: מספק אכיפה מבוססת-IP עם אובייקטים של שם דומיין שמוגדר במלואו (FQDN), אובייקטים של מיקום גיאוגרפי ופידים מ-Google Threat Intelligence כדי לחסום כתובות זדוניות מוכרות.
  • ‫Cloud Next Generation Firewall Enterprise: מספק יכולות בדיקה אמיתיות של אפליקציות (L7) עם פענוח TLS ויכולות של מערכת לגילוי ולמניעת חדירות (IDPS) כדי לנתח מטענים ייעודיים (payloads) בהשוואה לחתימות של איומים מתקדמים.

אפשר להחיל את Cloud NGFW על רשת ה-VPC כדי לאכוף את מדיניות חומת האש על סמך הכללים שנדרשים לטירגוט פלטפורמת אירוח הסוכן שבה השתמשתם.

  • ‫Agent Runtime: סוכנים שפועלים ב-Agent Runtime מתחברים לרשת ה-VPC באמצעות קבצים מצורפים לרשת של Private Service Connect. החיבורים האלה גורמים לממשק הרשת של הסוכן להופיע בתת-רשת ברשת ה-VPC. מדיניות חומת האש של רשת Cloud NGFW מוחלת על רשת ה-VPC. המדיניות מסננת את התנועה על סמך כתובות ה-IP של המקור מרשת המשנה שמוקדשת לקובץ המצורף של רשת Private Service Connect. כדי להתאים תנועה, אפשר להשתמש בכתובות IP של מקור ובטווחים של כתובות IP של יעד.
  • ‫Cloud Run: שירותי Cloud Run שמשתמשים ב-Direct VPC egress שולחים תעבורה ישירות ממכונות שפועלות ברשת משנה שצוינה ברשת ה-VPC. מדיניות חומת האש ברשת Cloud NGFW חלה על רשת המשנה שמשמשת את Cloud Run לסינון תעבורה. כדי להתאים תנועה, אפשר להשתמש בכתובת ה-IP של המקור ובטווחי כתובות ה-IP של היעד.
  • ‫GKE: אשכולות GKE מקוריים של VPC מקצים ל-Pods כתובות IP ישירות מטווחי כתובות IP משניים של רשת ה-VPC. כללי מדיניות של חומת אש ברשת יכולים לסנן תנועה על סמך טווחי כתובות IP של צמתי GKE ו-Pods, והם יכולים להשתמש בתגים מאובטחים ובחשבונות שירות. תגים מאובטחים מוצמדים למכונות הווירטואליות שמשמשות כצומתי GKE. אחרי כן, כללי חומת האש יכולים לטרגט תנועה מצמתים עם תגים ספציפיים או להפנות תנועה לצמתים כאלה. כללי חומת האש יכולים גם לכוון תנועה או להפיק תנועה מצמתי GKE על סמך הזהות של חשבון השירות שמשויך למאגר הצמתים.

מדיניות ברירת מחדל לדחיית תעבורת נתונים יוצאת

הטמעה של אסטרטגיית דחייה כברירת מחדל היא שיטת אבטחה מומלצת שמתבססת על העיקרון של הרשאות מינימליות. האסטרטגיה הזו מבטיחה שרק תנועת רשת שאושרה במפורש תותר, ושכל תנועה אחרת תיחסם כברירת מחדל. ההטמעה הזו מתבצעת על ידי מבנה של כללי חומת אש עם כללי ALLOW בעדיפות גבוהה לזרימות מוכרות ולגיטימיות, וכלל DENY בעדיפות נמוכה שכולל את כל השאר. בכל הרמות של Cloud NGFW אפשר להגדיר כללים שמבוססים על טווחי כתובות IP של המקור והיעד.

כללים במדיניות חומת האש יכולים להתאים ביעילות לתעבורת נתונים ממקורות שונים: מתת-הרשת של רשת החיבור של Agent Runtime ומתת-הרשת של יציאה ישירה מ-VPC ב-Cloud Run.

דוגמה למדיניות ברירת מחדל של תעבורת נתונים יוצאת (egress) חסומה:

  • יצירת מדיניות וכללים לחומת אש ברשת: יוצרים מדיניות חומת אש גלובלית או אזורית ומשייכים אותה לרשת ה-VPC. יוצרים כללים במדיניות חומת האש שמטרתם לסנן תעבורת נתונים בכיוון היציאה (--direction=EGRESS) על סמך טווחי כתובות ה-IP של המקור (--src-ip-ranges=SRC_IP_RANGES) וטווחי כתובות ה-IP של היעד (--dest-ip-ranges=DEST_IP_RANGES).
  • כללים ALLOW ספציפיים: משתמשים במספרי עדיפות נמוכים יותר, למשל 100-1000. הכללים האלה מאפשרים בדיוק את תנועת הרשת שנדרשת כדי שהסוכנים מבוססי ה-AI יפעלו. התנועה הזו כוללת תקשורת עם שירותים פנימיים אחרים, מאזני עומסים, ממשקי Google API נדרשים או נקודות קצה חיצוניות לגיטימיות. יוצרים כלל שתואם לתעבורת נתונים ממקור מתת-הרשת של החיבור לרשת של Agent Runtime או מתת-הרשת של Direct VPC egress ב-Cloud Run ליעדים הרצויים.
  • כלל DENY כללי: כדי לוודא שהכלל יהיה האחרון בסדר ההערכה, צריך להשתמש במספר העדיפות הגבוה ביותר, למשל 2147483647. הכלל הזה דוחה תנועה לכל יעד (--dest-ip-ranges=0.0.0.0/0) שלא תואם לאף אחד מ-ALLOW הכללים הקודמים.

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

שיקולים נוספים לגבי מדיניות Cloud NGFW

בנוסף לאסטרטגיית הדחייה שזמינה בכל הרמות של Cloud NGFW, אפשר להקשיח עוד יותר את אבטחת הרשת של ה-AI מרובה הסוכנים באמצעות תכונות של רמות בתשלום:

  • תכונות רגילות של Cloud NGFW:
    • אובייקטים של FQDN לנקודות קצה דינמיות: סוכני AI מתקשרים לעיתים קרובות עם ממשקי API חיצוניים, נקודות קצה של מודלים או מקורות נתונים שכתובות ה-IP שלהם עשויות להשתנות. כדי להבטיח גישה עקבית לשירותים הדרושים לפי שם הדומיין, צריך להשתמש באובייקטים של FQDN בכללי ALLOW.
    • אמצעי בקרה למיקום גיאוגרפי: אם לסוכני AI יש דרישות תאימות או שאסור להם ליצור אינטראקציה עם שירותים באזורים גיאוגרפיים ספציפיים, צריך להשתמש באובייקטים של מיקום גיאוגרפי (--src-region-codes=SRC_COUNTRY_CODES) בכללי חומת האש כדי להגביל את התנועה אל המיקומים האלה או מהם.
    • ‫Google Threat Intelligence: אפשר להשתמש ב-Google Threat Intelligence במסנני יציאה כדי לחסום באופן אוטומטי סוכנים להתחברות ליעדים זדוניים מוכרים, כמו שרתי שליטה ובקרה (C2), אמצעים להסתרת זהות כמו Tor ואתרים להפצת תוכנות זדוניות. השימוש ב-Google Threat Intelligence עוזר לצמצם את ההשפעה של סוכן שנפרץ. מומלץ לכלול את המסננים האלה של יעדים בכללים עם מספר העדיפות הגבוה יותר (סדר ההערכה הנמוך יותר) DENY.
  • תכונות של Cloud NGFW Enterprise:
    • בדיקה בשכבה 7: לסוכנים שמטפלים במידע אישי רגיש או שחשופים לסיכונים גבוהים יותר, בדיקת מטעני נתונים של מנות לאיתור איומים כמו תוכנות זדוניות, תוכנות ריגול וניצול לרעה שלא מנותחים על ידי כללי חומת האש בשכבת הרשת.
    • בדיקת TLS: כדי לאפשר למנוע הבדיקה לנתח תנועה מוצפנת, צריך להפעיל בדיקת TLS. השימוש בבדיקת TLS הוא חיוני כי רוב המתקפות המודרניות והתקשורת בין שרתי C2 מוצפנות.

לשיקולים נוספים בנושא הטמעה או למגבלות שעשויות לחול על הסביבה שלכם, כדאי לעיין במקורות המידע הבאים:

IAP

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

כדי לגשת לאפליקציות AI שמתארחות ב-GKE ומוגנות על ידי IAP, צריך להעניק לזהויות המשתמשים הראשיות את תפקיד המשתמש באפליקציית אינטרנט מאובטחת באמצעות IAP‏ (roles/iap.httpsResourceAccessor) ב-IAM במשאב שירות לקצה העורפי שמוגן באמצעות IAP. מומלץ להגדיר חשבון שירות מותאם אישית כזהות של סוכנים שנפרסו. שימוש בחשבון שירות בהתאמה אישית מאפשר להקצות הרשאות בצורה מדויקת יותר בהתאם לעיקרון של הרשאות מינימליות.

כדאי להקצות את התפקיד 'משתמש באפליקציית אינטרנט מאובטחת באמצעות IAP' ב-IAM ישירות לחשבונות השירות של סוכנים שיש להם הרשאה לגשת לסוכנים ולכלים אחרים שמארחים במשאב המותאם אישית של GKE‏ BackendConfig. כדי לאפשר גישה לאפליקציות Gemini Enterprise, צריך להקצות הרשאות על ידי קישור תפקיד ה-IAM‏ Discovery Engine Service Account‏ (roles/discoveryengine.serviceAgent) לפרויקט Gemini Enterprise.

VPC Service Controls

VPC Service Controls מצמצם את הסיכונים לזליגת נתונים על ידי שליטה קפדנית בגישה לממשקי API של Google. מומלץ לפרוס גבולות גזרה יחידים של מאקרו שכוללים את כל השירותים הנתמכים. הגישה הזו מספקת את ההגנה החזקה ביותר מפני גניבת נתונים. כדי להבטיח אכיפה עקבית של המדיניות בארכיטקטורות של VPC משותף, חשוב לכלול את הפרויקט המארח ואת כל פרויקטי השירות המשויכים באותם גבולות גזרה לשירות.

כדי לאבטח את האינטראקציה בין Gemini Enterprise לבין Cloud Run מעבר לגבולות הפרויקט, כדאי לפעול לפי ההמלצות הבאות:

  • פריסת גבולות גזרה יחידים של VPC Service Controls שכוללים את הפרויקטים של Gemini Enterprise ו-Cloud Run.
  • מוסיפים לרשימת השירותים המוגבלים את כל השירותים הנתמכים של VPC Service Controls. הגישה הזו עוזרת למנוע שינויים אדמיניסטרטיביים לא מורשים.
  • אכיפה של הגדרות כניסה והרשאה פנימיות כדי לחסום את כל הגישה לאינטרנט הציבורי לשירותי Cloud Run.

שירותי Cloud Run מאובטחים באמצעות IAM. למי שמבצע את הקריאה צריך להיות אימות, וצריך להיות לו תפקיד Cloud Run Invoker ב-IAM‏ (roles/run.invoker) בשירות היעד. התפקיד נבדק על ידי אימות של טוקן מכותרת ההרשאה. כדי לבצע קריאה לשירות Cloud Run, צריך להעניק לחשבונות שירות, כמו אלה שמשמשים את Gemini Enterprise, גם את התפקיד Cloud Run Invoker.

כשפורסים את Gemini Enterprise ואת Cloud Run בפרויקטים שונים, צריך להגדיר אזור של VPC Service Controls כדי להגדיר את תעבורת הנתונים הנכנסת (ingress) של Cloud Run כפנימית. בלי גבולות גזרה אלה, קריאות חוצות-פרויקטים מ-Gemini נחשבות לתעבורת נתונים חיצונית, מה שמאלץ אתכם להגדיר את תעבורת הנתונים הנכנסת (ingress) ל-Cloud Run ל'הכול' – מה שמשאיר את השירות חשוף לאינטרנט הציבורי.

  • ‫Cloud Run ingress all נתמך אם שני התנאים הבאים מתקיימים:
    • השירות VPC Service Controls לא מופעל.
    • ‫Cloud Run ו-Gemini Enterprise לא נמצאים באותו פרויקט.
  • רק Cloud Run ingress internal נתמך בכל שאר התצורות.

שיקולים נוספים לגבי VPC Service Controls

כשפורסים את Cloud Run בתוך היקף של VPC Service Controls, מומלץ להטמיע את אמצעי ההגנה הבאים כדי להבטיח הגנה מקיפה:

  • הגבלת הגדרות הכניסה המותרות: כדי למנוע ממפתחים לפרוס בטעות נקודות קצה שגלויות לציבור, צריך להגדיר את האילוץ run.allowedIngress של מדיניות הארגון. המגבלה הזו חלה רק על פריסות חדשות. יכול להיות שפריסות קודמות לא עומדות בדרישות. מומלץ לבדוק את כל שירותי Cloud Run הקיימים בתוך גבולות הגזרה, ולפרוס מחדש או לעדכן את השירותים שלא עומדים בהגדרות הנדרשות של תעבורת נתונים נכנסת (ingress) ותעבורת נתונים יוצאת (egress).
    • כדי לאפשר רק בקשות פנימיות, מגדירים את הערך internal.
    • כדי לאפשר בקשות דרך מאזן עומסים חיצוני של אפליקציות, מגדירים את הערך ל-internal-and-cloud-load-balancing.
  • הגבלת ההגדרות של יציאה מ-VPC: כדי לנתב את כל הבקשות היוצאות דרך ה-VPC כך שכללי חומת האש של ההיקף יוכלו לבדוק אותן, צריך להגדיר את ערך האילוץ של מדיניות הארגון run.allowedVPCEgress ל-all-traffic. ההגדרה הזו מחייבת שכל עדכון של Cloud Run ישתמש בתעבורת נתונים יוצאת (egress) ישירה של VPC או במחבר של חיבור לרשת (VPC) מאפליקציית serverless. המגבלה הזו חלה רק על פריסות חדשות. יכול להיות שפריסות קודמות לא עומדות בדרישות. מומלץ לבדוק את כל שירותי Cloud Run הקיימים בתוך גבולות הגזרה, ולפרוס מחדש או לעדכן את השירותים שלא עומדים בהגדרות הנדרשות של תעבורת נתונים נכנסת (ingress) ותעבורת נתונים יוצאת (egress).
  • מיקום משותף של קובצי אימג' של קונטיינרים ושירותים: המאגר של Artifact Registry שמכיל את קובצי האימג' של הקונטיינרים צריך להיות באותו היקף כמו שירות Cloud Run. שליפת תמונות בין גבולות גזרה נחסמת אוטומטית, אלא אם מגדירים כללי תעבורת נתונים נכנסת (ingress) ותעבורת נתונים יוצאת (egress) מפורשים.
  • ניהול רמות גישה: לא ניתן להשתמש בכללי מדיניות תעבורת נתונים נכנסת (ingress) של VPC Service Controls וברמות גישה שמסתמכות על זהויות של חשבונות משתמשים ב-IAM להפעלת Cloud Run. במקום זאת, צריך לנהל את הגישה באמצעות קריטריונים מבוססי-רשת או רמות גישה מבוססות-מכשיר.

הגנה מוגברת על המודל

‫Model Armor הוא שירות מבוסס-API שמספק אבטחה משופרת לאפליקציות AI. סוכני AI מקיימים אינטראקציה עם Model Armor על ידי ביצוע קריאות לניקוי הנחיות של משתמשים לפני שהן נשלחות ל-LLM, וגם לניקוי תשובות של מודלים לפני שהן מוחזרות למשתמש. ‫Model Armor בודק באופן פעיל את ההנחיות והתשובות של מודלי שפה גדולים (LLM), וכך מספק נקודת בדיקה חשובה לזיהוי סיכונים מתפתחים ונקודת בקרה ליישום תקנים של AI אחראי. אנחנו ממליצים להשתמש ב-Model Armor כדי לוודא שאתם עומדים בדרישות בנוגע למיקום הפיזי של הנתונים ובתקנות המשפטיות בנוגע לריבונות על נתונים. כדי להשתמש ב-Model Armor בתוך גבולות גזרה של Service Controls בענן וירטואלי פרטי (VPC), צריך להגדיר נקודת קצה (endpoint) של Private Service Connect (PSC) עבור נקודת הקצה האזורית של Model Armor בתוך רשת ה-VPC.

‫Model Armor הוא שירות אזורי שאפשר לגשת אליו באופן פרטי דרך נקודות קצה אזוריות של Private Service Connect ברשת ה-VPC. לדוגמה, קריאה לשירות us-central1 מתבצעת באמצעות נקודת הקצה האזורית modelarmor.us-central1.rep.googleapis.com. נקודות קצה אזוריות עוזרות להבטיח את מיקום אחסון הנתונים.

כדי להפעיל גישה לסוכנים, צריך להגדיר את הרכיבים הבאים בכל אזור שבו נדרש שירות הגנה מוגברת על המודל:

  1. יוצרים או מאתרים תת-רשת RFC 1918 באזור של רשת ה-VPC שבו נמצא שירות הגנה מוגברת על המודל.
  2. יוצרים נקודת קצה אזורית בתת-הרשת RFC 1918.
  3. יוצרים תחום פרטי ב-Cloud DNS ורשומה עבור שם המארח של נקודת הקצה האזורית של הגנה מוגברת על המודל (לדוגמה, modelarmor.us-central1.rep.googleapis.com) שמפנה לכתובת ה-IP של נקודת הקצה האזורית.
  4. כדי להשיג יכולת פעולה הדדית של Agent Runtime, צריך ליצור קישור DNS מ-Agent Runtime לאזור הפרטי של Cloud DNS שמשויך לרשת ה-VPC. כשסוכנים שולחים בקשות להגנה מוגברת על המודל, ‏ Cloud DNS מבצע התאמת נתונים (resolve) של בקשות לשם מארח לכתובת ה-IP של נקודת הקצה האזורית של Private Service Connect ברשת ה-VPC. השלב הזה לא נדרש לסוכנים שמארחים ב-Cloud Run וב-GKE.

כדי לשלב את Gemini Enterprise עם Model Armor, צריך ליצור תבנית Model Armor באותו פרויקט שבו נמצא Gemini Enterprise. המיקום של התבנית ושל אפליקציית Gemini Enterprise חייב להיות זהה.

למידע נוסף על הפעלת הגנה מוגברת על המודל, אפשר לעיין במקורות המידע הבאים:

Cloud Armor

‫Cloud Armor הוא שירות אבטחת רשת מבוזר שמגן על אפליקציות ושירותים מאחורי מאזני עומסים לפני שבקשות מגיעות לזמני הריצה של שירות הקצה העורפי. עומסי עבודה של סוכני AI כוללים נפחים גדולים של תקשורת בין-שירותים שמשתמשת ב-A2A, ב-MCP ובקריאות API. ההגנה של Cloud Armor מספקת שכבות נוספות של עמידות בתכנון האבטחה, עם הגבלת קצב, סינון WAF וכללים מותאמים אישית שתואמים לבקשות צפויות של סוכנים. על ידי צירוף מדיניות אבטחה של Cloud Armor לשירותי קצה עורפיים של מאזן עומסים של אפליקציות, אפשר לסנן את התעבורה כדי לזהות בקשות זדוניות, להגביל את קצב הבקשות ולצמצם את ההשפעה של התקפות DDoS.

אפשר לפרוס את Cloud Armor בארכיטקטורת רשת סוכנים בתרחישים הבאים:

  • ‫Cloud Run עם מאזן עומסים פנימי של אפליקציות (ALB): הגנה על סוכנים וכלים שפועלים ב-Cloud Run באמצעות מאזן עומסים פנימי של אפליקציות עם קצוות עורפיים של NEG ללא שרת. אפשר להחיל מדיניות אבטחה של בק-אנד על קבוצת ה-NEG בלי שרת (serverless) כדי לאכוף כללי WAF על תנועה פנימית ולהגביל את קצב העברת הנתונים. כדי לשלוט בתקשורת של הסוכנים, אתם יכולים להגדיר כללים מותאמים אישית נוספים על סמך כתובות IP וכותרות.
  • שער: הגנה על סוכנים וכלים שפועלים ב-GKE באמצעות הגדרת משאב Gateway למאזן עומסים גלובלי או אזורי חיצוני של אפליקציות (ALB) עם בק-אנד של NEG אזורי. משתמשים ב-Kubernetes Gateway API כדי להחיל את משאב GCPBackendPolicy עם מדיניות האבטחה המוגדרת של Cloud Armor. אם אתם משתמשים במאזן עומסים חיצוני אזורי של אפליקציות (ALB),‏ Cloud Armor תומך במדיניות אבטחה של קצה עורפי עם כללי WAF, אמצעי בקרה שמבוססים על כתובת IP ומיקום גיאוגרפי והגבלת קצב יצירת הבקשות. מאזני עומסים גלובליים חיצוניים של אפליקציות תומכים בכללי מדיניות לאבטחת קצה העורף (backend) ובכללי מדיניות נוספים לאבטחת קצה באמצעות Google Cloud Armor Adaptive Protection ו- Google Threat Intelligence.

Secure Web Proxy

‫Secure Web Proxy הוא שירות אזורי מנוהל שמוטמע ברשת ה-VPC כדי לסנן תעבורת HTTP/S שמקורה ברשת ה-VPC או ברשתות מחוברות כלשהן. הוא פועל כפרוקסי מרכזי ונקודת אכיפת אבטחה כדי לספק שליטה מפורטת ושקיפות לגבי תעבורת אינטרנט יוצאת. הוא גם משמש כ-proxy מפורש לתקשורת בין שירותים פנימיים.

‫Secure Web Proxy תומך בשלושה מצבי פריסה: מצב ניתוב של שרת proxy מפורש, מצב של קובץ מצורף עם שירות Private Service Connect ומצב של הנתב הבא. מומלץ להשתמש ב-Secure Web Proxy במצב ניתוב מפורש של proxy, שזהו הנושא העיקרי של המסמך הזה. במצב הזה, צריך להגדיר במפורש את לקוחות ה-HTTP כך שיצביעו ישירות על כתובת ה-IP או על שם המארח של ה-Secure Web Proxy.

כדי לפרוס Secure Web Proxy ברשת ה-VPC, צריך להגדיר רשת משנה של קצה קדמי ורשת משנה של proxy בלבד. Secure Web Proxy הוא שירות שמנוהל במלואו. כשפורסים את Secure Web Proxy, הוא פורס ומגדיר באופן אוטומטי את Cloud Router ו-Cloud NAT ברשת ה-VPC שלכם, כדי ליצור שילוב ספציפי עם משאב ה-Proxy. ההגדרה הזו מחייבת שכל הבקשות היוצאות יעברו דרך Secure Web Proxy לפני שהן יוצאות לאינטרנט.

שימוש ב-Secure Web Proxy כשרת proxy מפורש תומך בבקשות של סוכנים שמגיעות מממשקי Private Service Connect של Agent Runtime, מתעבורת נתונים יוצאת (egress) ישירה של Direct VPC ב-Cloud Run ומאשכולות GKE מקוריים של VPC. כשסוכנים שולחים בקשות ל-Secure Web Proxy באמצעות שיטת HTTP CONNECT, התנועה של סשן TCP עוברת מנהור ל-proxy, שבו מוחלים כללי מדיניות האבטחה. אם תעבורת הנתונים מותרת, Secure Web Proxy שולח את תעבורת הנתונים ליציאה מבוקרת מהאינטרנט או ליעדים ברשת פרטית שאפשר לנתב דרך רשת ה-VPC.

ניתוב מפורש של שרת proxy

כדי שהסוכנים יוכלו להגיע ליעדים באינטרנט או לטווחים של כתובות IP שלא ניתן לנתב ברשת ה-VPC, צריך להשתמש בהגדרת Proxy מפורשת ביציאה של Agent Runtime. כדי להבטיח יכולת פעולה הדדית של Agent Runtime, מומלץ להגדיר את משאב Secure Web Proxy עם כתובת IP מסוג RFC 1918 מרשת משנה של קצה קדמי ברשת ה-VPC. בהגדרה הזו, אפשר להגיע ישירות ל-Secure Web Proxy מ-Agent Runtime. לאחר מכן הוא יכול להעביר ב-proxy כל חיבור ליעדים של כתובות IP שלא ניתן לנתב שנמצאים ברשת ה-VPC או ברשתות מחוברות.

כדי לתמוך בשימוש בפלטפורמה לאירוח סוכנים ב-Secure Web Proxy במצב ניתוב מפורש, צריך להגדיר את משאבי הרשת הבאים:

  1. יוצרים או מזהים תת-רשת RFC 1918 ברשת ה-VPC כדי לארח את משאב Secure Web Proxy.
  2. יוצרים רשומת DNS של Cloud DNS עבור שם המארח של Secure Web Proxy (לדוגמה, swp.example.com) שמפנה לכתובת ה-IP של משאב Secure Web Proxy.
  3. כדי להשיג יכולת פעולה הדדית של Agent Runtime, צריך ליצור קישור DNS מ-Agent Runtime לאזור הפרטי של Cloud DNS שמשויך לרשת ה-VPC. כשסוכנים שולחים בקשות ל-Secure Web Proxy, ‏ Cloud DNS פותר את בקשות שם המארח לכתובת ה-IP של משאב Secure Web Proxy ברשת ה-VPC. השלב הזה לא נדרש לסוכנים שמארחים ב-Cloud Run וב-GKE.

הגדרות לשרת proxy של הסוכן

הדרך הרגילה להגדיר אפליקציות של סוכנים לשימוש ב-Proxy של HTTP(S) היא באמצעות הגדרת משתני הסביבה הבאים:

  • ‫HTTP_PROXY: כתובת ה-URL של שרת ה-proxy המפורש לתעבורת HTTP (לדוגמה, http://swp.example.com:8888). בהגדרה הזו נעשה שימוש בשיטת ה-HTTP CONNECT מהלקוח ל-proxy. למרות שצוין HTTP, ההצפנה באמצעות TLS נשמרת מקצה לקצה דרך ה-proxy, החל מזמן הריצה של הסוכן ועד לנקודת היעד.
  • ‫HTTPS_PROXY: כתובת ה-URL של שרת ה-proxy המפורש לתעבורת HTTPS (לדוגמה, https://swp.example.com:8888). בדומה להגדרה HTTP_PROXY, ההגדרה HTTPS_PROXY משתמשת ב-TLS כברירת מחדל. עם זאת, אתם יכולים לספק שכבת הצפנה נוספת על ידי הפעלת הצפנת TLS משלכם בנוסף ל-TLS שמוגדר כברירת מחדל. מידע נוסף זמין במאמר בנושא שירות רשות האישורים.
  • ‫NO_PROXY: רשימה מופרדת בפסיקים של שמות מארחים או כתובות IP שלא צריכים לעבור דרך ה-Proxy. לדוגמה, אם מוסיפים את metadata.google.internal ואת 169.254.169.254 לרשימה NO_PROXY, עומסי העבודה יכולים לגשת ישירות לשירות המטא-נתונים לצורך אימות והרשאה ל-Google APIs ולשירותים של Google.

כשמשתמשים בארגומנט env_vars כדי להגדיר משתנים במהלך הפריסה, הם הופכים לזמינים בסביבת זמן הריצה של הסוכן (לדוגמה, כשמשתמשים ב-os.environ ב-Python). רוב ספריות הלקוח הרגילות של HTTP מגלות את משתני הסביבה האלה ומשתמשות בהם באופן אוטומטי כדי לנתב את התנועה דרך ה-proxy שצוין. הגישה הזו נפוצה באפליקציות Python ובספריות לקוח של HTTP כמו requests. כשפורסים סוכנים, מגדירים משתני סביבה לשימוש ב-Secure Web Proxy לכל דומיין פרטי שהסוכנים צריכים להגיע אליו. חשוב לוודא שכל יעדי הדומיין הפרטיים כלולים גם ב-Cloud DNS.

בדוגמה הבאה מוצגת פריסה של פרוקסי של Agent Runtime מאובייקט של סוכן:

## specify environment variables (dictionary)
env_vars = {
    "OTHER_VARIABLE": "OTHER_VALUE",
    "HTTP_PROXY": "http://swp.example.com:8888",
    "HTTPS_PROXY": "http://swp.example.com:8888",
    "NO_PROXY": "localhost,127.0.0.1,metadata.google.internal,169.254.169.254,.googleapis.com,run.app,.gcr.io,.pkg.dev,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.internal"
}

remote_agent = aiplatform.agent_engines.create(
    agent=local_agent,
    config={
        "display_name": "Example agent using proxy",
        "env_vars": env_vars,
        ## ... other configs
    },
)

ב-Cloud Run אפשר להגדיר משתני סביבה ברמת עדכון השירות. בגישה הזו, משתני סביבה עם אותו שם שהוגדרו בקובץ אימג' של קונטיינר מוחלפים. הגישה הזו שימושית להגדרת פרמטרים תפעוליים כמו משתני proxy כשמופעלים מופעי השירות.

בדוגמה הבאה מוצגת הפקודה להגדרת משתני הסביבה כשפורסים שירות Cloud Run:

gcloud run deploy SERVICE_NAME \
--image=IMAGE_URL \
--set-env-vars="HTTP_PROXY=http://swp.example.com:8888,HTTPS_PROXY=http://swp.example.com:8888,NO_PROXY=localhost,127.0.0.1,metadata.google.internal,169.254.169.254,.googleapis.com,run.app,.gcr.io,.pkg.dev,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.internal"

כדי להטמיע הגדרת שרת Proxy מפורשת בתרמילי GKE, צריך להגדיר משאב ConfigMap שמציין את משתני ה-Proxy:

apiVersion: v1
kind: ConfigMap
metadata:
  name: agent-proxy-config
  namespace: ai-apps
data:
  HTTP_PROXY: "http://swp.example.com:8888"
  HTTPS_PROXY: "http://swp.example.com:8888"

  NO_PROXY: "localhost,127.0.0.1,metadata.google.internal,169.254.169.254,.googleapis.com,run.app,.gcr.io,.pkg.dev,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.internal"

כדי להחיל את מקשי ConfigMap על ה-Pods, משתמשים בשדה envFrom במניפסט של הקונטיינר. במפרט הזה, משתני הסביבה מוזרקים לקונטיינר בזמן הריצה.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: subagent-app
spec:
  template:
    spec:
      containers:
      -   name: my-container
        image: my-agent-app:latest
        envFrom:
        -   configMapRef:
            name: agent-proxy-config

שירות CA

CA Service (שירות CA) נדרש כשמגדירים את Secure Web Proxy או את Cloud NGFW לבדיקת TLS. כשבדיקת TLS מופעלת ויעד של עומס עבודה משתמש ב-TLS, שירות רשות האישורים יוצר וחותם על אישור עבור היעד הזה. כשהתעבורה המוצפנת של היעד האמיתי מגיעה אל Secure Web Proxy או אל Cloud NGFW, המערכת מבצעת פענוח של החבילה, בודקת אותה ואז אוכפת את המדיניות. אם המדיניות מאפשרת את החבילה, השירות מצפין מחדש את החבילה ליעד הסופי. אפשר גם להשתמש בשירות CA כדי לספק אישורים לשירותים אחרים בניהול Google.

שירות CA הוא שירות מנוהל. אחרי שמגדירים את CA Service, הוא מטפל בחתימה על אישורי עלים עד שתוקף אישור ה-CA הבסיסי פג. צריך לעדכן את אישורי ה-CA הבסיסיים כדי לוודא שהתוקף שלהם לא יפוג.

שירות CA תומך ביכולות האלה כדי לאפשר בדיקת תנועה וניהול אישורים בהיקף נרחב בארכיטקטורת AI מרובת סוכנים:

  • בדיקת TLS: כדי לבצע בדיקת TLS מלאה, צריך להשתמש ברשות אישורים פרטית. כדי לפענח ולנתח באופן מלא את נתוני ה-payload של HTTPS, מכשיר ה-proxy המתווך (Secure Web Proxy או Cloud NGFW) צריך לסיים את סשן ה-TLS עם הלקוח. הפרוקסי חייב להציג אישור תקף שהלקוח מקבל כאישור מהימן עבור הדומיין המבוקש.

    שירות CA יכול ליצור ולחתום באופן דינמי על אישור התחזות ספציפי לאתר, עבור האתר שהוגשה לגביו בקשה. כשהאישור הפרטי של רשות האישורים הבסיסית מותקן במאגר האישורים המהימנים של הלקוח, הוא מקבל את האישור שנוצר באופן דינמי כאישור תקף. הלקוח סומך על האישור שנשלח על ידי ה-proxy, ולכן הוא שולח את הבקשה. הפרוקסי מסיים את סשן ה-TLS, מפענח את החבילה, בודק את התוכן ואז אוכף את המדיניות.

  • הפצת אישורים: משאבי לקוח פנימיים כמו סוכני AI שפועלים ב-Agent Runtime, ב-Cloud Run או ב-GKE צריכים את אישור הבסיס הפרטי של רשות האישורים שנוסף למאגרי האישורים המקומיים שלהם. אם מאחסנים את המפתח הציבורי של אישור ה-CA הבסיסי ב-Secret Manager, סוכני ה-AI יכולים לשלוף את האישור בהפעלה ולהוסיף אותו למאגר האישורים המהימנים של המערכת.

    משאבי שרת פנימיים, כמו מאזני עומסים פנימיים של אפליקציות, צריכים אישורים שהונפקו על ידי רשות אישורים פרטית כדי לפעול כנקודות קצה מהימנות של שרתים ולסיים סשנים של TLS של לקוחות. מאזני עומסים של אפליקציות משולבים עם הגדרות הנפקה של Certificate Manager כדי לאפשר לשירות CA לחתום על בקשת האישור ולפרוס אותה במאזן העומסים באופן אוטומטי.

למידע נוסף על פעולות שקשורות לאישור, אפשר לעיין במקורות המידע הבאים:

אבטחת החיבור בין אפליקציות

סוכני הבסיס מתקשרים עם מגוון רחב של סוכני משנה ושרתי MCP שנפרסים בפלטפורמות שונות לאירוח בזמן ריצה. כל סביבה מציגה דרישות ייחודיות של רשת ואבטחה שצריך להפשיט בשכבת A2A או MCP.

התרשים הבא מציג את הרכיבים ואת נתיבי החיבור האפשריים שנתמכים במדריך העיצוב הזה:

דפוסי קישוריות Agent2Agent‏ (A2A) בין פלטפורמות אירוח שונות, כולל GKE, ‏ Cloud Run ו-Agent Runtime, וחיבורים לשרתי MCP ולאינטרנט.

בתרשים שלמעלה מוצג סיכום של אפשרויות החיבור האלה:

  • המשתמשים יוצרים אינטראקציה עם המערכת מבוססת הסוכנים באמצעות אפליקציית Gemini Enterprise.
  • אפליקציית Gemini Enterprise משתמשת בתשתית של Google כדי להתחבר לסוכן הבסיסי שפועל ב-GKE, ב-Cloud Run או ב-Agent Runtime.
  • אפליקציית Gemini Enterprise והסוכנים הבסיסיים משתמשים בתשתית של Google כדי להתחבר ל-Model Armor ול-LLM של Gemini ב-Agent Platform.
  • סוכני הבסיס יכולים להשתמש בתשתית של Google כדי להתחבר לסוכני משנה שפועלים ב-Cloud Run או ב-Agent Runtime.
  • הסוכנים הראשיים יכולים להשתמש בכתובות IP פרטיות כדי להתחבר לסוכני משנה שפועלים ב-Agent Runtime, ב-Cloud Run וב-GKE. החיבורים האלה צריכים להיות מנותבים דרך רשת VPC.
  • גם סוכני הבסיס וגם סוכני המשנה יכולים להתחבר לשרתי MCP שפועלים ב-Cloud Run או ב-GKE. סוכנים שמתחברים לשרתים של MCP יכולים להשתמש בתשתית של Google או ברשת VPC. שרתי ה-MCP מספקים גישה לכלים שמתארחים ב-Google Cloud, בתשתית מקומית, בענן אחר או באינטרנט.
  • אפשר להגיע ישירות לשירותים שמארחים באינטרנט דרך Secure Web Proxy.

בקטעים הבאים מפורטים משאבים של נתיבי נתונים בזמן ריצה ואמצעי אבטחה שנדרשים לאינטראקציות מאובטחות בין אפליקציות (A2A). המידע הזה משמש כסטנדרט ארכיטקטוני ליצירת קישוריות פרטית ולהטמעה של אמצעי ההגנה הרב-שכבתיים שנדרשים כדי להגן על נתיב הנתונים מקצה לקצה בין הסוכנים.

סוכן המקור של GKE

בטבלה הבאה מפורטים מקורות מידע שיעזרו לכם להגן על התנועה כש-GKE הוא סוכן המקור. התעבורה הזו עוברת דרך רשת ה-VPC שמארחת את אשכול GKE.

סוכן היעד (נתיב הנתונים) בקרת אבטחה
Agent Runtime (פנימי)
‫Cloud Run (פנימי)
‫Cloud Run (Private Service Connect ל-Google APIs)
גישה ל-Cloud Run (NEG ללא שרת)
GKE
אינטרנט דרך רשת VPC

סוכן מקור (פנימי) של Agent Runtime

בטבלה הבאה מפורטים מקורות מידע שיעזרו לכם להגן על התעבורה כש-Agent Runtime הוא סוכן המקור והתעבורה עוברת ישירות דרך התשתית של Google. בנתיבים האלה לא מעורבת רשת VPC.

סוכן היעד (נתיב הנתונים) בקרת אבטחה
Agent Runtime (פנימי)
‫Cloud Run (פנימי)

סוכן מקור של Agent Runtime (ממשק Private Service Connect)

בטבלה הבאה מפורטים משאבים שיעזרו לכם להגן על התנועה כש-Agent Runtime הוא סוכן המקור והתנועה עוברת דרך ממשק Private Service Connect ברשת VPC.

סוכן היעד (נתיב הנתונים) בקרת אבטחה
‫Cloud Run (Private Service Connect‏ GoogleAPIs)
גישה ל-Cloud Run (NEG ללא שרת)
GKE
אינטרנט דרך רשת VPC

סוכן מקור (פנימי) של Cloud Run

בטבלה הבאה מפורטים מקורות מידע שיעזרו לכם להגן על התנועה כש-Cloud Run הוא סוכן המקור והתנועה מועברת ישירות דרך התשתית של Google. בנתיבים האלה לא מעורבת רשת VPC.

סוכן היעד (נתיב הנתונים) בקרת אבטחה
Agent Runtime (פנימי)
‫Cloud Run (פנימי)

סוכן מקור של Cloud Run (Direct VPC egress)

בטבלה הבאה מפורטים משאבים שיעזרו לכם להגן על תעבורת הנתונים כש-Cloud Run הוא סוכן המקור ותעבורת הנתונים עוברת דרך רשת VPC באמצעות תעבורת נתונים יוצאת (egress) ישירה של VPC.

סוכן היעד (נתיב הנתונים) בקרת אבטחה
‫Cloud Run (Private Service Connect ל-Google APIs)
גישה ל-Cloud Run (NEG ללא שרת)
GKE
אינטרנט דרך רשת VPC
‫Agent Runtime Private Service Connect ל-Google APIs

אבטחת החיבור ל-MCP

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

  • אינטרנט:
    • VPC Service Controls
    • הגנה מוגברת על המודל
    • Cloud NGFW
    • Secure Web Proxy
  • ‫Google MCP:
    • VPC Service Controls
    • הגנה מוגברת על המודל

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

שותפים ביצירת התוכן

מחברים:

תורמי תוכן אחרים: