הגדרת Agent Gateway

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

לפני שאתם מגדירים שער, כדאי לקרוא את המושגים הבסיסיים ואת הרכיבים העיקריים בסקירה הכללית על Agent Gateway.

ההרשאות הנדרשות

כדי ליצור ולנהל את Agent Gateways, צריך את ההרשאות הבאות: אתם יכולים לקבל את ההרשאות האלה באמצעות תפקידים בהתאמה אישית או באמצעות תפקידים מוגדרים מראש אחרים.

ההרשאות הנדרשות

  • agentregistry.agents.list
  • agentregistry.endpoints.list
  • agentregistry.mcpServers.list
  • compute.networkAttachments.create
  • compute.networkAttachments.delete
  • compute.networkAttachments.get
  • compute.networkAttachments.list
  • compute.networkAttachments.update
  • compute.regionOperations.get
  • compute.regions.list
  • modelarmor.templates.list
  • networksecurity.authzPolicies.create
  • networksecurity.authzPolicies.delete
  • networksecurity.authzPolicies.get
  • networksecurity.authzPolicies.list
  • networksecurity.operations.get
  • networkservices.agentConnectivityTemplates.create
  • networkservices.agentConnectivityTemplates.delete
  • networkservices.agentConnectivityTemplates.get
  • networkservices.agentConnectivityTemplates.list
  • networkservices.agentConnectivityTemplates.update
  • networkservices.agentGateways.create
  • networkservices.agentGateways.delete
  • networkservices.agentGateways.get
  • networkservices.agentGateways.list
  • networkservices.agentGateways.update
  • networkservices.agentGateways.use
  • networkservices.authzExtensions.create
  • networkservices.authzExtensions.delete
  • networkservices.authzExtensions.get
  • networkservices.authzExtensions.list
  • networkservices.authzExtensions.update
  • networkservices.authzExtensions.use
  • networkservices.operations.get
  • certificatemanager.trustconfigs.create
  • certificatemanager.trustconfigs.get
  • certificatemanager.trustconfigs.list
  • certificatemanager.trustconfigs.use

ממשקי ה-API הנדרשים

מפעילים את ממשקי ה-API המינימליים הנדרשים בפרויקט ב- Google Cloud שבו פורסים את Agent Gateway:

  • ‫Compute Engine API ‏ (compute.googleapis.com): מספק תשתית רשת בסיסית, רשתות משנה, ניתוב וחיבורי רשת של Private Service Connect ‏ (PSC).
  • ‫Network Security API‏ (networksecurity.googleapis.com): יוצר ואוכף כללי מדיניות הרשאה (authzPolicies) לתנועה בשער.
  • ‫Network Services API (networkservices.googleapis.com): מנהל את המשאבים של Agent Gateway (agentGateways), תבניות קישוריות (agentConnectivityTemplates) ותוספים שמפנים לבדיקת הרשאות (authzExtensions).
  • ‫Identity and Access Management API‏ (iam.googleapis.com): ניהול חשבונות שירות ומערכת גישה מאוחדת לכללי מדיניות (UAP) של IAM לזהויות של נציגים.
  • ‫Identity-Aware Proxy API (iap.googleapis.com): מאמת את התנועה של הסוכן, נקודת הקצה והשרת.
  • ‫Agent Registry API (agentregistry.googleapis.com): רושם ומנהל סוכנים, שרתי MCP ונקודות קצה של כלים הכפופים לשער.

כדי להפעיל את ממשקי ה-API המינימליים הנדרשים, מריצים את הפקודה הבאה:

gcloud services enable \
    compute.googleapis.com \
    networksecurity.googleapis.com \
    networkservices.googleapis.com \
    iam.googleapis.com \
    iap.googleapis.com \
    agentregistry.googleapis.com \
    --project=PROJECT_ID

מחליפים את PROJECT_ID במזהה הפרויקט שבו פורסים את Agent Gateway.

בהתאם לתכונות, לכלי התצפית ולסביבות זמן הריצה של הסוכנים שבהם אתם משתמשים עם Agent Gateway, יכול להיות שתצטרכו להפעיל גם ממשקי API אופציונליים:

ממשקי API אופציונליים לפי תכונה

  • קישוריות VPC פרטית ו-TLS:
    • ‫Cloud DNS API (dns.googleapis.com): נדרש רק אם מגדירים קישוריות VPC עם קישור בין רשתות שכנות (peering) ב-Cloud DNS לזיהוי דומיינים פרטיים.
    • ‫Certificate Manager API (certificatemanager.googleapis.com): נדרש רק אם מגדירים ישויות עוגן אמינות מותאמות אישית של TLS (TrustConfig) כשמתחברים לקצוות עורפיים פרטיים שמשתמשים ברשויות אישורים פרטיות או באישורים חתומים באופן עצמי.
  • בטיחות וסינון תוכן ב-AI:
    • ‫Model Armor API (modelarmor.googleapis.com): נדרש רק אם מפעילים את מעקות הבטיחות של Model Armor כדי לבדוק ולסנן החדרת פרומפטים, תוכן רעיל ומידע אישי רגיש.
  • ניטור וביקורת:
    • ‫Cloud Logging API (logging.googleapis.com): מתעד את יומני הגישה לשער, את יומני הביקורת של האבטחה ואת האירועים של הערכת המדיניות בהרצה יבשה.
    • <!--Cloud Monitoring API (): Tracks gateway health, latency, throughput, and error rates, and configures operational alerts.-->Cloud Monitoring API ‏(monitoring.googleapis.com): מעקב אחרי תקינות השער, זמן האחזור, קצב הנתונים ושיעורי השגיאות, והגדרת התראות תפעוליות.
    • ‫Observability API (observability.googleapis.com): מספק יכולת תצפית מאוחדת ומרכזי בקרה תפעוליים לפעילות של הסוכן והשער.
    • ‫Telemetry API (telemetry.googleapis.com): אוסף ומעביר נתוני טלמטריה בזמן ריצה ומדדי ביצועים בין רכיבי הפלטפורמה.
    • ‫Cloud Trace API (cloudtrace.googleapis.com): מספק מעקב מבוזר כדי לבדוק בקשות מרובות דילוגים בין סוכנים ורכיבי בקצה העורפי.
  • Agent Runtime ופיקוח סמנטי:
    • ‫Agent Platform API‏ (aiplatform.googleapis.com): נדרש בפרויקטים שמארחים סוכנים של Agent Runtime או משתמשים במדיניות פיקוח בשפה טבעית.
    • ‫Discovery Engine API‏ (discoveryengine.googleapis.com): נדרש בפרויקטים שמארחים אפליקציות וסוכנים של Gemini Enterprise.
    • ‫Agent Identity API (agentidentity.googleapis.com): נדרש רק אם אתם מנהלים את פרטי הכניסה היוצאים באמצעות מנהל האימות של Agent Identity או צופים בספקי האימות של Agent Identity במסוף Google Cloud .

תכנון הפריסה של Agent Gateway

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

בחירת מצב הפריסה

‫Agent Gateway תומך בשני מצבי פריסה:

  • מלקוח לסוכן (ingress): אבטחת התקשורת מהלקוחות לסוכנים שפועלים ב- Google Cloud.
  • מסוכן לכל מקום (תעבורת נתונים יוצאת): אבטחת התקשורת מהסוכנים שלכם ליעדים חיצוניים, לממשקי API ציבוריים ולשרתי MCP.

בוחרים את סביבת זמן הריצה, הפרויקט והאזור לפריסה.

‫Agent Gateway מנהל את התנועה מסוכנים שפועלים ב-Gemini Enterprise וב-Runtime.

  • ‫Agent Runtime: ‏Agent Gateway תומך במצבים Agent-to-Anywhere (תעבורת נתונים יוצאת) ו-Client-to-Agent (תעבורת נתונים נכנסת). במצב "סוכן לכל מקום", הסוכנים יכולים להיות באותו פרויקט של השער או בפרויקט אחר. במצב Client-to-Agent, הסוכנים צריכים להיות באותו פרויקט שבו נמצא השער. בשני המצבים, הסוכנים צריכים להיות באותו אזור כמו השער.

  • ‫Gemini Enterprise: ‏Agent Gateway תומך רק במצב "סוכן לכל מקום" (תעבורת נתונים יוצאת). ב-Gemini Enterprise, כל שער מנהל אינטראקציות של סוכנים רק במסגרת הפרויקט והאזור שבהם הוא פרוס.

כדי לנהל סוכנים ב-Gemini Enterprise וב-Runtime, אתם יכולים להשתמש במכונה אחת של Agent Gateway. אפשר גם לפרוס מכונות Agent Gateway נפרדות ל-Gemini Enterprise ול-Runtime.

דוגמאות לתבניות פריסה

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

פיקוח על סוכני Runtime בכמה פרויקטים

בדפוס הפריסה הזה, פורסים Agent Gateway מסוג Agent-to-Anywhere (תעבורת נתונים יוצאת) בפרויקט ייעודי לניהול משתמשים. סוכני זמן הריצה נפרסים בפרויקטים נפרדים באותו אזור שבו נמצא השער, ויכולים להיות שייכים לכל תיקייה בארגון.

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

בפרויקט הפיקוח המרכזי:

  • יוצרים את Agent Gateway. מוודאים שהשער משויך למכונה של Agent Registry.
  • רושמים סוכנים בפרויקטים שונים, יחד עם כלים, שרתים או נקודות קצה (endpoints), באמצעות Agent Registry שמצורף לשער.
  • נותנים הרשאות IAM בפרויקטים שונים לסוכן השירות של זמן הריצה בכל פרויקט שבו נמצאים הסוכנים, כדי שהסוכנים בפרויקטים האלה יוכלו להתחבר לשער בפרויקט הפיקוח. לדוגמה, ראו ניתוב תנועה בזמן ריצה דרך Agent Gateway.
  • מגדירים כללי מדיניות של IAP, בקרת גישה לישויות מורשות (PAB) ו-Workload Identity שתואמות ל-SPIFFE, כדי לנהל ולאבטח את תעבורת הנתונים היוצאת (egress) לנקודות קצה מורשות.
  • יוצרים את התבניות של Model Armor שרוצים להשתמש בהן לתעבורת נתונים יוצאת.
  • אם אתם רוצים להעביר נתונים יוצאים לרשת VPC, אתם יכולים ליצור בפרויקט הפיקוח את מחבר הרשת של PSC, ישויות עוגן אמינות בהתאמה אישית ל-TLS‏ (tlsConfig) לרשויות אישורים פרטיות, והגדרת קישור בין רשתות שכנות (peering) ב-DNS.

בפרויקטים של Agent Runtime:

  • פורסים את הסוכנים ומקשרים אותם לשער המרכזי בפרויקט הפיקוח.

שימו לב: אפשר להשתמש בניהול בכמה פרויקטים רק בסביבת זמן ריצה עם שערים מסוג Agent-to-Anywhere (תעבורת נתונים יוצאת). אי אפשר להשתמש ב-Gemini Enterprise.

ניהול משותף של סוכני Gemini Enterprise ו-Runtime

בדפוס הפריסה הזה, כל התנועה מאפליקציות Gemini Enterprise ומסוכני Runtime מנותבת דרך Agent Gateway אחד.

הנה דוגמה לפריסה:

  • אפליקציית Gemini Enterprise נפרסת כפריסה של global.
  • סוכני זמן הריצה נפרסים באזור אחד (us-central1) שתואם לפריסה של Gemini Enterprise.
  • ‫Agent Gateway נפרס באותו אזור (us-central1).
  • מופע us-central1 Agent Registry משויך ל-Agent Gateway. אתם צריכים לרשום את הנציגים והיעדים במכונה הזו של Agent Registry.
פיקוח עצמאי על סוכני Gemini Enterprise ו-Runtime

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

  • אפליקציית Gemini Enterprise פרוסה ב-global, ב-us או ב-eu.
  • סוכני זמן הריצה נפרסים בכל אזור שבו הם נדרשים.
  • מכונות של Agent Gateway נפרסות בכל אזור שבו נמצאים הסוכנים והאפליקציות.
  • אתם צריכים לרשום את הסוכנים והיעדים במכונה האזורית של Agent Registry שמשויכת לכל שער.

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

כל נציג שמנוהל על ידי Agent Gateway צריך זהות ייחודית משלו (מזהה SPIFFE). מכיוון שכללי מדיניות הגישה של IAM תלויים ב-Workload Identity, תנועה מסוכנים לא מזוהים נחסמת כברירת מחדל.

אתם יכולים להקצות Agent Identity כשאתם פורסים סוכן ב-Runtime או מקצים אותו לעומסי עבודה קיימים של סוכנים. איך משתמשים ב-Agent Identity עם Runtime

רישום הסוכנים ומשאבי היעד

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

  1. מזהים את המכונה האזורית של Agent Registry שבה רוצים להשתמש. כל Agent Gateway משויך למרשם אזורי אחד (//agentregistry.googleapis.com/projects/PROJECT_ID/locations/REGION) באותו פרויקט ובאותו אזור שבהם השער נפרס:

    • ‫Agent Runtime: מפנים למרשם האזורי באותו פרויקט ובאותו אזור שבהם נפרס ה-Agent Gateway. רושמים סוכנים בפרויקטים שונים ברגיסטרי האזורי של פרויקט הפיקוח המרכזי שמארח את השער.
    • ‫Gemini Enterprise: צריך להפנות למאגר האזורי באותו פרויקט ואזור כמו Agent Gateway (us-central1 לאפליקציות global ו-us, או europe-west1 לאפליקציות eu). למידע נוסף, קראו את המאמר תכנון המיפויים של המיקום ושל Agent Registry.

    חשוב לוודא שהמופע של המרשם האזורי שאתם משייכים ל-Agent Gateway הוא המופע שבו רשומים הסוכנים, נקודות הקצה ושרתי ה-MCP שלכם.

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

  3. מומלץ: לזהות ולרשום את כל הכלים, שרתי ה-MCP ונקודות הקצה ל-API שהסוכנים יקראו להם (כולל ממשקי API חיוניים של הפלטפורמה). כדי שהסוכן יוכל לגשת ליעדים, תמיד צריך לתת לזהות של הסוכן את ההרשאה iap.resources.egressViaIAP באמצעות מדיניות גישה של IAM. מומלץ לרשום משאבים ב-Agent Registry כדי שתוכלו לאכוף מדיניות מפורטת לכל משאב ואמצעי בקרה ברמת הכלי. אם היעדים לא רשומים, צריך לתת לסוכן את ההרשאה הזו על ידי הגדרת כללי מדיניות לנקודות קצה לא רשומות.

    יעדים בפרויקט שונה מהשער חייבים להיות רשומים ב-Agent Registry בפרויקט של השער. יעדים כאלה תקפים רק לסוכני זמן ריצה במצב Agent-to-Anywhere.

    הוראות מפורטות במדריכים הבאים:

הגדרת כללי מדיניות של בקרת גישה

לכל Agent Gateway צריך להיות משויכת מדיניות הרשאה.

‫IAM (במצב Agent-to-Anywhere בלבד)

מגדירים מדיניות IAM שמקצה את ההרשאה iap.resources.egressViaIAP לחשבון המשתמש של זהות הנציג, לכל אחד ממשאבי היעד שרשמתם ב-Agent Registry.

כברירת מחדל, Agent Gateway חוסם את כל התנועה, אלא אם מדיניות הגישה של IAM מאשרת במפורש גישה של הסוכן למשאבי היעד על ידי מתן ההרשאה iap.resources.egressViaIAP לזהות הסוכן.

מומלץ לרשום יעדים במרשם הסוכנים כי זה מאפשר להגדיר את היקף המדיניות למשאבים ספציפיים ולהחיל אמצעי בקרה מפורטים על הכלים. אם היעדים לא רשומים ב-Agent Registry, צריך לתת לסוכן את ההרשאה iap.resources.egressViaIAP באמצעות הגדרת מדיניות לנקודות קצה לא רשומות.

חשוב לוודא שכל קישור ברמת המרשם תואם למכונה האזורית של Agent Registry שהוגדרה ל-Agent Gateway.

להוראות, ראו יצירת כללי מדיניות של סוכני IAM.

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

Model Armor

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

מידע נוסף זמין במאמרים הבאים:

מדיניות פיקוח בשפה טבעית

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

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

מנועי הרשאה בהתאמה אישית

(אופציונלי) אם רוצים להקצות הרשאות למנועי הרשאות בהתאמה אישית או למערכות של צד שלישי באמצעות Service Extensions, צריך לוודא שמנועי ההרשאות בהתאמה אישית זמינים כשפורסים את השער.

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

הגדרת Agent Gateway במצב "סוכן לכל מקום" (תעבורת נתונים יוצאת)

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

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

  • תעבורת נתונים יוצאת (egress) של רשת VPC: השער מנתב את תנועת הסוכנים באופן פרטי לרשת VPC באמצעות חיבורי רשת של Private Service Connect. אתם יכולים לבחור אם לנתב את כל התנועה דרך רשת ה-VPC‏ (ALL_TRAFFIC) או רק את התנועה שמיועדת לטווחי כתובות IP פרטיות (PRIVATE_RANGES_ONLY).

    כדי להגדיר Agent Gateway עם תעבורת נתונים יוצאת ב-VPC, צריך לפעול לפי ההוראות במאמר הגדרת קישוריות VPC ל-Agent Gateway.

כדי ליצור משאב Agent Gateway לתקשורת מסוכן לכל מקום:

מסוף Google Cloud

  1. נכנסים לדף Agent Gateway במסוף Google Cloud .

    כניסה לדף Gateways

  2. לוחצים על הוספת שער.
  3. מזינים שם.
  4. ברשימה Region, בוחרים אזור.
  5. בשדה Deployment mode, מוודאים שהאפשרות Google-managed מסומנת.
  6. בקטע Agent registries, בוחרים את המרשם האזורי שתואם לאזור של Agent Gateway. איך מתכננים את הפריסה של Agent Gateway
  7. ברשימה Governed Access Path, בוחרים באפשרות Agent-to-Anywhere (Agent Egress).

  8. בקטע Access Authorization, בוחרים איך ה-IAP יטפל בתנועה:

    • כדי לפרוס את השער במצב פרימטר לבדיקות, שבו השער מאפשר לכל התנועה לעבור ורק יוצר יומני ביקורת, בוחרים באפשרות Audit-only (שמגדירה את iamEnforcementMode: "DRY_RUN" בתוסף שמפנה לבדיקת הרשאות). מדיניות ה-IAM לא נאכפת על ידי IAP במצב פרימטר לבדיקות. אחרי שאתם בטוחים שהכל תקין, אתם יכולים להשבית את מצב ההרצה לניסיון כדי לאכוף את מדיניות ה-IAM.
    • כדי לחסום בקשות שאין להן מדיניות IAM מפורשת של Allow, בוחרים באפשרות אכיפת כללי מדיניות (שכותבת את iamEnforcementMode: "ENFORCED" בתוסף שמפנה לבדיקת הרשאות כשיוצרים שער, או מסירה את iamEnforcementMode כשמעדכנים שער קיים). האפשרות הזו מומלצת לסביבות ייצור.
    • בקטע Policy model, בוחרים באפשרות Unified Access Policy.

  9. אופציונלי: בקטע אבטחת AI, מגדירים אבטחה נוספת:

    1. כדי להגן על האינטראקציות של מודל ה-AI באמצעות Model Armor, מפעילים את האפשרות Enable Model Armor.
    2. בוחרים מהרשימה תבנית שחלה על בקשות נכנסות לשער.

    3. כדי להשתמש בתבנית אחרת לתגובות, מבטלים את הסימון של Use same template for requests and responses ובוחרים תבנית מהרשימה.

  10. לוחצים על הוספת שער.

gcloud

אתם מגדירים את Agent Gateways באופן הצהרתי באמצעות YAML.

  1. מגדירים את המשאב ושומרים את ההגדרות בקובץ YAML. בדוגמה הזו נשתמש ב-my-agent-gateway-egress.yaml.

    name: AGENT_GATEWAY_NAME
protocols:
  - MCP
googleManaged:
  governedAccessPath: AGENT_TO_ANYWHERE
registries:
  - AGENT_REGISTRY_PATH

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫AGENT_GATEWAY_NAME: השם של המשאב ב-Agent Gateway.
    • ‫AGENT_REGISTRY_PATH: הנתיב למכונה האזורית של Agent Registry באותו פרויקט ואזור כמו השער, בפורמט //agentregistry.googleapis.com/projects/PROJECT_ID/locations/LOCATION. איך מתכננים את הפריסה של Agent Gateway

  2. מריצים את הפקודה הבאה כדי ליצור משאב של Agent Gateway על סמך מפרט ה-YAML:

    gcloud network-services agent-gateways import AGENT_GATEWAY_NAME \
 --source="my-agent-gateway-egress.yaml" \
 --location=LOCATION

    מחליפים את LOCATION במיקום שבו רוצים ליצור את המשאב של Agent Gateway. לדוגמה, us-central1.

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

  3. יצירת מדיניות הרשאה כדי לאכוף כללי מדיניות מרכזיים של בקרת גישה ומשילות על תנועה שעוברת דרך Agent Gateway. בשלבים הבאים מוסבר איך להגדיר מדיניות הרשאה שמשתמשת ב-IAP.

    1. מגדירים תוסף שמפנה לבדיקת הרשאות ב-IAP. מגדירים את התוסף בקובץ YAML, למשל iap-request-authz-extension.yaml. משתמשים בערכים לדוגמה שסופקו:

      cat >iap-request-authz-extension.yaml <<EOF
name: AUTHORIZATION_EXTENSION_NAME
service: iap.googleapis.com
failOpen: false
timeout: 1s
metadata:
  iapPolicyVersion: "V2"
EOF

      אם רוצים לפרוס את התוסף במצב הרצה (dry run) לביקורת בלבד כדי לבדוק את מדיניות ההרשאה בלי לאכוף אותה, אפשר לציין את השדה iamEnforcementMode בתוך הבלוק metadata. כך תוכלו לאמת את המדיניות ולצמצם את הסיכון לשיבוש בתנועה בגלל שגיאות בהגדרות:

      cat >iap-request-authz-extension.yaml <<EOF
name: AUTHORIZATION_EXTENSION_NAME
service: iap.googleapis.com
failOpen: false
timeout: 1s
metadata:
  iapPolicyVersion: "V2"
  iamEnforcementMode: "DRY_RUN"
EOF

      כשתהיו מוכנים להתחיל לאכוף את כללי המדיניות, הסירו את השדה iamEnforcementMode: "DRY_RUN" מהבלוק metadata. במאמר ביקורת על הפרות מדיניות בהרצה יבשה בכל אמצעי הבקרה מוסבר איך לבדוק הפרות בהרצה יבשה בכל אמצעי הבקרה לפני שמפעילים את האכיפה.

    2. מייבאים את קובץ התצורה בפורמט YAML לתוסף שמפנה לבדיקת הרשאות.

      gcloud beta service-extensions authz-extensions import AUTHORIZATION_EXTENSION_NAME \
  --source=iap-request-authz-extension.yaml \
  --location=LOCATION

      מחליפים את AUTHORIZATION_EXTENSION_NAME בשם של התוסף שמפנה לבדיקת הרשאות, לדוגמה my-iap-request-authz-ext.

    3. מגדירים מדיניות הרשאה בקובץ YAML, כמו iap-request-authz-policy.yaml, כדי לשייך את התוסף לשער:

      cat >iap-request-authz-policy.yaml <<EOF
name: AUTHORIZATION_POLICY_NAME
target:
  resources:
    - "projects/PROJECT_ID/locations/LOCATION/agentGateways/AGENT_GATEWAY_NAME"
policyProfile: REQUEST_AUTHZ
action: CUSTOM
customProvider:
  authzExtension:
    resources:
      - "projects/PROJECT_ID/locations/LOCATION/authzExtensions/AUTHORIZATION_EXTENSION_NAME"
EOF

      מחליפים את מה שכתוב בשדות הבאים:

      • ‫AUTHORIZATION_POLICY_NAME: שם מדיניות ההרשאה, לדוגמה my-iap-request-authz-policy
      • ‫PROJECT_ID: מזהה הפרויקט

    4. מייבאים את קובץ התצורה בפורמט YAML למדיניות הרשאה.

      gcloud network-security authz-policies import AUTHORIZATION_POLICY_NAME \
  --source=iap-request-authz-policy.yaml \
  --location=LOCATION

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

Terraform

כדי להקצות באופן הצהרתי Agent Gateway מסוג Agent-to-Anywhere (תעבורת נתונים יוצאת) ואת המדיניות והתוסף שמפנה לבדיקת הרשאות של IAP שמשויכים אליו בפרויקט ניהול מרכזי באמצעות הספק google:

  1. יוצרים את המשאב google_network_services_agent_gateway ומשייכים את המכונה האזורית של Agent Registry:

    resource "google_network_services_agent_gateway" "egress_gateway" {
  project   = "PROJECT_ID"
  location  = "LOCATION"
  name      = "AGENT_GATEWAY_NAME"
  protocols = ["MCP"]

  google_managed {
    governed_access_path = "AGENT_TO_ANYWHERE"
  }

  registries = [
    "//agentregistry.googleapis.com/projects/PROJECT_ID/locations/LOCATION",
  ]
}

  2. מגדירים את ה-IAP google_network_services_authz_extension ומצרפים אותו לשער באמצעות google_network_security_authz_policy:

    resource "google_network_services_authz_extension" "iap_request_authz_ext" {
  project   = "PROJECT_ID"
  location  = "LOCATION"
  name      = "my-iap-request-authz-ext"
  service   = "iap.googleapis.com"
  timeout   = "1s"
  fail_open = false

  metadata = {
    iapPolicyVersion = "V2"
    # Uncomment the following line to deploy in dry-run (audit-only) mode:
    # iamEnforcementMode = "DRY_RUN"
  }
}

resource "google_network_security_authz_policy" "iap_request_authz_policy" {
  project        = "PROJECT_ID"
  location       = "LOCATION"
  name           = "my-iap-request-authz-policy"
  policy_profile = "REQUEST_AUTHZ"
  action         = "CUSTOM"

  target {
    resources = [
      google_network_services_agent_gateway.egress_gateway.id
    ]
  }

  custom_provider {
    authz_extension {
      resources = [
        google_network_services_authz_extension.iap_request_authz_ext.id
      ]
    }
  }
}

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

    עיינו שוב בקטע תכנון הפריסה של Agent Gateway בדף הזה, וודאו שהסוכנים רשומים ב-Agent Registry ושהסוכן קיבל את ההרשאה iap.resources.egressViaIAP לכל היעדים שהוא מנסה להתחבר אליהם. אם נתקלתם בבעיות בקישוריות, קראו את המאמר פתרון בעיות בקישוריות ל-Agent Gateway.

איך פורסים סוכנים ומנתבים תנועה דרך Agent Gateway

הגדרת Agent Gateway במצב "לקוח לסוכן" (תעבורת נתונים נכנסת)

בקטע הזה מוסבר איך להגדיר Agent Gateway לתקשורת בין לקוח לסוכן.

כך יוצרים משאב של Agent Gateway:

מסוף Google Cloud

  1. נכנסים לדף Agent Gateway במסוף Google Cloud .

    כניסה לדף Gateways

  2. לוחצים על הוספת שער.
  3. מזינים שם.
  4. ברשימה Region, בוחרים אזור.
  5. בשדה Deployment mode, מוודאים שהאפשרות Google-managed מסומנת.
  6. משאירים את ההגדרה Agent registry כמו שהיא. המאגר לא משמש להעברת נתונים נכנסים.
  7. ברשימה Governed Access Path, בוחרים באפשרות Client-to-Agent (ingress)‎.

  8. אופציונלי: בקטע אבטחה באמצעות AI, מגדירים אבטחה נוספת:

    1. כדי להגן על האינטראקציות של מודל ה-AI באמצעות Model Armor, מפעילים את האפשרות Enable Model Armor.

    2. בוחרים מהרשימה תבנית שחלה על בקשות נכנסות לשער.

    3. כדי להשתמש בתבנית אחרת לתגובות, מבטלים את הסימון של Use same template for requests and responses ובוחרים תבנית מהרשימה.

  9. לוחצים על הוספת שער.

gcloud

אתם מגדירים את Agent Gateways באופן הצהרתי באמצעות YAML.

  1. מגדירים את המשאב ושומרים את ההגדרות בקובץ YAML. בדוגמה הזו נשתמש ב-my-agent-gateway-ingress.yaml.

    name: AGENT_GATEWAY_NAME
protocols:
  - MCP
googleManaged:
  governedAccessPath: CLIENT_TO_AGENT

    מחליפים את AGENT_GATEWAY_NAME בשם של המשאב Agent Gateway.

  2. מריצים את הפקודה הבאה כדי ליצור משאב של Agent Gateway על סמך מפרט ה-YAML:

    gcloud network-services agent-gateways import AGENT_GATEWAY_NAME \
 --source="my-agent-gateway-ingress.yaml" \
 --location=LOCATION

    מחליפים את LOCATION במיקום שבו רוצים ליצור את המשאב של Agent Gateway. לדוגמה, us-central1.

Terraform

כדי להקצות משאב של Agent Gateway מסוג Client-to-Agent (ingress)‎ באופן הצהרתי באמצעות הספק google:

resource "google_network_services_agent_gateway" "ingress_gateway" {
  project   = "PROJECT_ID"
  location  = "LOCATION"
  name      = "AGENT_GATEWAY_NAME"
  protocols = ["MCP"]

  google_managed {
    governed_access_path = "CLIENT_TO_AGENT"
  }
}

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

בשלב הבא, תלמדו איך לפרוס סוכנים ולנתב תנועה דרך Agent Gateway.

פריסת סוכנים וניתוב תנועה דרך Agent Gateway

כדי לפרוס סוכן Agent Runtime שמנתב תנועה דרך Agent Gateway, קראו את המאמר ניתוב תנועה דרך Agent Gateway.

כדי לפרוס סוכן Gemini Enterprise שמנתב תנועה דרך Agent Gateway, קראו את המאמר ניתוב תנועה של Gemini Enterprise דרך Agent Gateway.

Codelabs

ב-Codelabs הבאים מוסבר איך להגדיר את Agent Gateway ולהשתמש בו:

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

מדריך

איך מנתבים את התנועה של Agent Runtime דרך Agent Gateway כדי ליצור קישוריות מאובטחת ומנוהלת.

מדריך

איך להעביר את ההרשאה ל-Agent Gateway אל IAP, אל Model Armor או אל שירות הרשאות בהתאמה אישית.

מדריך

איך מציגים, מעדכנים, מוחקים ומבטלים את השיוך של משאבי Agent Gateway.

מדריך

איך עוקבים אחרי Agent Gateway.

פתרון בעיות

איך פותרים בעיות בקישוריות של Agent Gateway.

מדריך

איך מנתבים את התנועה של Gemini Enterprise דרך Agent Gateway.