‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

הגדרת Agent Gateway עם קישוריות ל-VPC

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

הגדרת קישוריות VPC מאפשרת לכם:

אכיפת תעבורת נתונים יוצאת ב-VPC: ניתוב תעבורת הנתונים שמגיעה מהסוכנים דרך מחבר הרשת של Private Service Connect אל רשת ה-VPC באמצעות מצב PRIVATE_RANGES_ONLY או ALL_TRAFFIC.
טווח סטטי של כתובות IP של מקור: תנועה יוצאת משתמשת בטווח כתובות ה-IP הפרטיות של רשת המשנה של חיבור הרשת של Private Service Connect ככתובת ה-IP של המקור. טווח כתובות ה-IP הסטטיות של המקור מאפשר להגדיר כללי מדיניות חומת אש לרשת ה-VPC, כדי לנהל את תעבורת הנתונים שמגיעה מהשער.
רזולוציית DNS בהתאמה אישית: פתרון שמות של דומיינים פרטיים פנימיים ושמות של דומיינים חיצוניים ישירות מהסוכנים באמצעות Cloud DNS Peering.
אבטחה היקפית: הגנה על התקשורת של הסוכן באמצעות גבולות גזרה לשירות של VPC Service Controls.
אימות של אישורים פרטיים או של אישורים בחתימה עצמית: התחברות ליעדים שמשתמשים ברשויות אישורים פרטיות או באישורים בחתימה עצמית.

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

איך פועל הקישוריות ל-VPC

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

מצבי תעבורת נתונים יוצאת (egress) של VPC

כדי להגדיר איך השער מנתב את התנועה דרך מחבר הרשת, משתמשים בהגדרה vpcEgress בתבנית הקישוריות.

‫Traffic to private IP address ranges (PRIVATE_RANGES_ONLY): ניתוב תנועה שמיועדת רק לטווחים של כתובות IP פרטיות לרשת ה-VPC. תעבורת הנתונים היוצאת מנותבת לרשת ה-VPC רק אם כתובת ה-IP של היעד נמצאת באחד מהטווחים הבאים:
- RFC 1918:‏ 10.0.0.0/8,‏ 172.16.0.0/12,‏ 192.168.0.0/16
- RFC 6598: 100.64.0.0/10
- Class E: 240.0.0.0/4
- private.googleapis.com: 199.36.153.8/30
- restricted.googleapis.com: 199.36.153.4/30
- נקודות קצה של PSC לממשקי Google API: אם אתם פורסים נקודת קצה מותאמת אישית של Private Service Connect לממשקי Google API באמצעות כתובת IP פרטית פנימית ברשת ה-VPC, התנועה לנקודת הקצה הזו מנותבת דרך רשת ה-VPC. חשוב לוודא שהגדרתם קישור בין רשתות שכנות (peering) ב-Cloud DNS בתבנית הקישוריות, כדי ש-Agent Gateway יפענח בצורה נכונה את הדומיינים של Google API לכתובת ה-IP של נקודת הקצה הפנימית של ה-PSC.
בקשות לממשקי Google API ציבוריים רגילים מטופלות באופן אוטומטי באמצעות גישה פרטית ל-Google, ותנועה שמיועדת לאינטרנט מנותבת ישירות דרך Agent Gateway במקום דרך רשת ה-VPC שלכם.
‫Traffic to all IP address ranges (ALL_TRAFFIC): כל התנועה היוצאת מהנציגים שלכם מנותבת דרך רשת ה-VPC, כולל אינטרנט ציבורי, ממשקי API חיצוניים של SaaS וכתובות שהן לא RFC 1918.
- ניתוב ואבטחה: מכיוון שההגדרה הזו מנתבת את כל התנועה היוצאת ל-VPC, אתם אחראים לנהל את הניתוב והאבטחה שלה. מוודאים שברשת ה-VPC יש נתיב ברירת מחדל (0.0.0.0/0) להעברת התנועה הזו לשערים היוצאים או למכשירי האבטחה (כמו חומות אש של הדילוג הבא או ממשקי Cloud Interconnect).
- תעבורת נתונים יוצאת לאינטרנט הציבורי: Agent Gateway שולח תעבורת נתונים יוצאת לרשת ה-VPC, ומשם היא יוצאת לאינטרנט הציבורי דרך שער Cloud NAT ברשת המשנה של מחבר הרשת של Private Service Connect. אם מקצים כתובות IP חיצוניות סטטיות לשער Cloud NAT, שירותים מרוחקים יכולים להוסיף לרשימת ההיתרים את תנועת הנתונים היוצאת של הסוכנים על סמך כתובות ה-IP האלה של המקור.
- ‫VPC Service Controls: כדי לתמוך בגבולות גזרה לשירות של VPC Service Controls, צריך להגדיר את מצב תעבורת הנתונים היוצאת (egress) ל-ALL_TRAFFIC.

פענוח DNS וניתוב תעבורת נתונים

כברירת מחדל, Agent Gateway פותר שמות דומיינים באמצעות DNS רקורסיבי ציבורי. אם הנציגים שלכם צריכים לגשת לעומסי עבודה פנימיים, לכלים פרטיים או לממשקי Google API שמתארחים בשמות דומיינים פרטיים ברשת ה-VPC שלכם (כמו corp.internal. או נקודות קצה של PSC), אתם יכולים להגדיר קישור בין רשתות שכנות (peering) ב-Cloud DNS כדי להעביר שאילתות DNS לאזורים המנוהלים הפרטיים של Cloud DNS ברשת שלכם.

בטבלה הבאה מפורטות הדרישות של קישור בין רשתות שכנות (peering) ב-Cloud DNS והתנהגות הניתוב של התנועה ליעדים שונים, כשקישוריות ה-VPC מוגדרת במצב ALL_TRAFFIC:

**טבלה:** פענוח DNS וניתוב תנועה במצב `ALL_TRAFFIC`
יעד התנועה	האם נדרש קישור בין רשתות שכנות (peering) ב-Cloud DNS?	פענוח DNS	נתיב תעבורת הנתונים היוצאת (egress)
שירותי IP פרטיים (RFC 1918 / פנימי)	כן (לדוגמה, `corp.internal.`)	התאמה באמצעות קישור בין רשתות שכנות (peering) ב-Cloud DNS עם האזור המנוהל הפרטי של Cloud DNS ברשת היעד של ה-VPC.	תעבורת הנתונים נכנסת לרשת ה-VPC דרך מחבר הרשת כדי להתחבר לעומסי עבודה פנימיים.
שמות מארחים ציבוריים עם כתובות IP פרטיות (Split-horizon DNS)	לא	הפתרון הוא שימוש ב-DNS רקורסיבי ציבורי רגיל בשרת ה-proxy של השער, בלי צורך בקישור בין רשתות שכנות (peering) ב-Cloud DNS.	תעבורת הנתונים נכנסת לרשת ה-VPC דרך מחבר הרשת כדי להתחבר לעומסי עבודה פנימיים.
ממשקי API ציבוריים באינטרנט וב-SaaS (דומיינים חיצוניים)	לא	הפתרון הוא שימוש ב-DNS רקורסיבי ציבורי רגיל בשרת ה-proxy של השער, בלי צורך בקישור בין רשתות שכנות (peering) ב-Cloud DNS.	תנועה נכנסת לרשת ה-VPC דרך מחבר הרשת ויוצאת לאינטרנט הציבורי באמצעות Cloud NAT שמוגדר ברשת המשנה.
ממשקי API שלGoogle Cloud (רגילים, בלי VPC Service Controls)	לא	הפתרון הוא שימוש ב-DNS רקורסיבי ציבורי רגיל בשרת ה-proxy של השער, בלי צורך בקישור בין רשתות שכנות (peering) ב-Cloud DNS.	תעבורת הנתונים נכנסת לרשת ה-VPC דרך מחבר הרשת ומנותבת באופן פרטי באמצעות גישה פרטית לשירותי Google שמופעלת ברשת המשנה, בלי להשתמש ב-Cloud NAT או בקישור בין רשתות שכנות (peering) ב-DNS.
ממשקי API שלGoogle Cloud (עם VPC Service Controls)	כן (ל-`googleapis.com.`)	הכתובת מפנה לטווח המוגבל של Google API ‏(`199.36.153.4/30`) או לנקודות קצה (endpoints) פנימיות של Private Service Connect באמצעות תחום Cloud DNS פרטי.	התנועה נכנסת לרשת ה-VPC דרך מחבר הרשת כדי לאכוף את כללי האבטחה ההיקפית של VPC Service Controls‏¹.

‫¹ אם הבקשות נכשלות בגלל הפרות של VPC Service Controls, כמו NETWORK_NOT_IN_SAME_SERVICE_PERIMETER או SECURITY_POLICY_VIOLATED ב-compute.googleapis.com או ב-dns.googleapis.com שמפנות לפרויקט המארח, צריך לוודא שהפרויקט המארח נמצא באותו מתחם אבטחה היקפית כמו פרויקט השער.

הדרישות לגבי אישור TLS

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

רשויות אישורים ציבוריות: כברירת מחדל, Agent Gateway נותן אמון באישורים שהונפקו על ידי רשויות אישורים (CA) ציבוריות מהימנות שעומדות בדרישות הסטנדרטיות לאישורי שרת (כולל שם חלופי של בעלים (SAN) שתואם לשם המארח של היעד).
רשויות אישורים פרטיות ואישורים חתומים באופן עצמי: אם היעד (סוכנים, כלים או שרתי MCP ברשת ה-VPC) משתמש ברשות אישורים פרטית או בתשתית מפתחות ציבוריים (PKI) פנימית, אתם יכולים להגדיר ישויות עוגן אמינות בהתאמה אישית באמצעות ההגדרה tlsConfig בתבנית הקישוריות.

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

אם הנציגים שלכם מתחברים לממשקי API של Google Cloud (*.googleapis.com) או לנקודות קצה ציבוריות אחרות של HTTPS, אתם צריכים להגדיר את additionalRoots ל-PUBLICLY_TRUSTED_ROOTS. בלי ההגדרה הזו, Agent Gateway לא ייתן אמון באישורים שחתומים על ידי Google בשביל googleapis.com.

חשוב לשים לב למגבלות הבאות כשמשתמשים ב-tlsConfig:
- כשמשתמשים ב-trustConfig כדי לנתב תנועה ליעדים שמשתמשים ברשויות אישורים פרטיות, צריך להחליף את קובצי ה-PEM באופן ידני. אי אפשר להחליף קובצי PEM באופן אוטומטי באמצעות מנהלי סודות, כמו Secret Manager שלGoogle Cloud.
- השדה trustConfig לא ניתן לשינוי אחרי שמגדירים אותו בתבנית קישוריות, ו-Agent Gateway לא מזהה באופן אוטומטי שינויים שבוצעו ב-tlsConfig (כמו עדכון של additionalRoots) בתבנית קישוריות מצורפת. הוראות לעדכון הגדרות TLS מופיעות במאמר עדכון הגדרות תעבורת הנתונים היוצאת של VPC.

אם Agent Gateway לא מצליח לאמת את שרשרת האישורים, החיבור נכשל.

תפקידים והרשאות נדרשים

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

פריסות של פרויקטים עצמאיים

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

פריסות של VPC משותף או פריסות בכמה פרויקטים

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

אם מקצים את Agent Gateway בפרויקט שירות, ורשת ה-VPC, מחבר הרשת או תחומי ה-DNS הפרטיים נמצאים בפרויקט המארח (TARGET_VPC_PROJECT_ID), הזהויות בפרויקט השירות לא מקבלות באופן אוטומטי הרשאות לאימות, לחיבור או להגדרת יחסי שכנות (peering) עם משאבי הרשת וה-DNS בפרויקט המארח. בנוסף להרשאות הרגילות של Agent Gateway, נותנים את התפקידים הבאים בפרויקט המארח:

**טבלה:** ההרשאות שנדרשות לפריסות של VPC משותף ופריסות בפרויקטים שונים
ישות מורשית או זהות	הענקת הרשאה בפרויקט	תפקיד IAM נדרש	מטרה
זהות להקצאה¹ (חשבון משתמש או חשבון שירות לפריסה)	פרויקט מארח (`TARGET_VPC_PROJECT_ID`)	צפייה ברשת Compute‏ (`roles/compute.networkViewer`) קורא DNS‏ (`roles/dns.reader`) אדמין של נקודת קצה אזורית לקישוריות לרשת (`roles/networkconnectivity.regionalEndpointAdmin`) אדמין של רשת צרכנים ב-Network Connectivity‏ (`roles/networkconnectivity.consumerNetworkAdmin`)	מאפשרת אימות בקצה העורפי של רשת ה-VPC, רשתות המשנה, מחבר הרשת ותחומי ה-DNS הפרטיים של היעד במהלך היצירה או העדכון של השער.
יוצר חיבור הרשת (האדמין שיוצר את החיבור ל-PSC)	פרויקט מארח (`TARGET_VPC_PROJECT_ID`)	משתמש ברשת Compute‏ (`roles/compute.networkUser`)	מאפשרת להשתמש ברשת משנה של VPC משותף בפרויקט המארח כדי ליצור מחבר רשת של Private Service Connect.
חיבור לרשת בפרויקט השירות (מומלץ)
סוכן השירות Agent Gateway Service Agent²	פרויקט מארח (`TARGET_VPC_PROJECT_ID`)	משתמש ברשת Compute‏ (`roles/compute.networkUser`) רשת שכנה (peering) ב-DNS‏ (`roles/dns.peer`)	מאפשר לסוכן השירות של Agent Gateway להשתמש ברשת המשנה של הפרויקט המארח בשביל מחבר הרשת, לחבר את ממשק Private Service Connect כדי לנתב את תעבורת הנתונים היוצאת (egress) וליצור קישור בין רשתות שכנות (peering) עם תחומי Cloud DNS פרטיים בפרויקט המארח.
חיבור רשת בפרויקט המארח
סוכן השירות Agent Gateway Service Agent²	פרויקט מארח (`TARGET_VPC_PROJECT_ID`)	אדמין של רשת Compute‏ (`roles/compute.networkAdmin`), או תפקיד בהתאמה אישית עם: `compute.networkAttachments.get` `compute.networkAttachments.update` `compute.regionOperations.get` רשת שכנה (peering) ב-DNS‏ (`roles/dns.peer`)	מאפשר לסוכן השירות של Agent Gateway לעדכן את מחבר הרשת של הפרויקט המארח כדי לאפשר את החיבור מפרויקט הדייר של Agent Gateway, לנתב את תעבורת הנתונים היוצאת (egress) ולבצע התאמה עם תחומי Cloud DNS פרטיים בפרויקט המארח.

‫¹ לזהות שמקצה את המשאבים, מספיקים גם תפקידים בסיסיים ברמת הפרויקט כמו צפייה (roles/viewer) או עריכה (roles/editor) בפרויקט המארח.

‫² סוכן השירות של Agent Gateway מופיע בפורמט הבא: service-AGENT_GATEWAY_PROJECT_NUMBER@gcp-sa-agentgateway.iam.gserviceaccount.com, כאשר AGENT_GATEWAY_PROJECT_NUMBER הוא מספר הפרויקט שבו מקצים את Agent Gateway. בפריסות של VPC משותף, הפרויקט הזה יכול להיות פרויקט שירות או פרויקט מארח.

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

הגדרת הקישוריות ל-VPC

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

יצירת חיבור רשת של Private Service Connect

יוצרים מחבר רשת של Private Service Connect ברשת ה-VPC של היעד.

חשוב לוודא שחיבור הרשת עומד בדרישות הבאות:

העדפת חיבור: מגדירים את חיבור הרשת כך שיקבל חיבורים באופן אוטומטי (--connection-preference=ACCEPT_AUTOMATIC).
דרישה לאותה רשת VPC: רשת המשנה של מחבר הרשת ורשת היעד שהוגדרה לקישור בין רשתות שכנות (peering) ב-DNS‏ (targetNetwork) חייבות להיות בדיוק באותה רשת VPC. אם רשת המשנה של מחבר הרשת שייכת לרשת שונה מהרשת המוגדרת כיעד לקישור בין רשתות שכנות (peering) ב-DNS, אימות ההגדרה ייכשל.
תמיכה ב-MTU של רשת VPC: Agent Gateway תומך ביחידת העברה מקסימלית (MTU) של עד 1,500 בייטים לרשת ה-VPC שמכילה את רשת המשנה של מחבר הרשת. אם ברשת ה-VPC הזו נעשה שימוש ב-MTU גדול יותר, כמו מסגרות ג'מבו, פנו ל-Cloud Customer Care כדי להתאים את שירות היצרן של Agent Gateway ל-MTU של ה-VPC בהתאמה אישית.
דרישות לגבי תת-הרשת: שימו לב לדרישות הבאות לגבי תת-הרשת של חיבור הרשת:
- טווח רשת המשנה: רשת המשנה של חיבור הרשת תומכת בכל הטווחים התקינים.
- גודל רשת המשנה: Agent Gateway דורש רשת משנה של /28 לפחות בשביל מחבר הרשת. רשת משנה /28 מספקת 12 כתובות IP שמישות, וזה מספיק למכונה אחת של Agent Gateway. אם אתם מתכננים לחבר כמה שערים לאותו מחבר רשת או לאותה רשת משנה, השתמשו ברשת משנה גדולה יותר (כמו /26 או /24) כדי למנוע מצב שבו לא נשארות כתובות IP פנויות.
- דרישה לגישה פרטית ל-Google: צריך להפעיל את הגישה הפרטית ל-Google (private_ip_google_access = true) ברשת המשנה שמארחת את חיבור הרשת.
פריסות של VPC משותף: לפריסות של VPC משותף, ראו טופולוגיות של פריסת VPC משותף.

שימו לב ל-URI המלא של המשאב של מחבר הרשת (לדוגמה, projects/NETWORK_ATTACHMENT_PROJECT_NUMBER/regions/NETWORK_ATTACHMENT_REGION/networkAttachments/NETWORK_ATTACHMENT_NAME). תצטרכו אותו כשתצרו את המשאב של תבנית הקישוריות בשלב מאוחר יותר.

אופציונלי: הגדרת קישור בין רשתות שכנות (peering) ב-DNS

קישור בין רשתות שכנות (peering) ב-DNS מאפשר ל-Agent Gateway לזהות שמות DNS באמצעות רשומות מאזור פרטי מנוהל ב-Cloud DNS ברשת ה-VPC שלכם. קישור בין רשתות שכנות (peering) ב-DNS נדרש רק כשהסוכנים צריכים לזהות שמות דומיינים פנימיים פרטיים (כמו corp.internal.) או לאכוף את VPC Service Controls לממשקי Google API‏ (googleapis.com.). הוא לא נדרש לדומיינים ציבוריים באינטרנט או לממשקי Google API רגילים בלי VPC Service Controls.

‫Agent Gateway תומך בקישור בין רשתות שכנות (peering) ב-DNS טרנזיטיבי רק עד דילוג טרנזיטיבי אחד, כלומר עד שלוש רשתות VPC. לדוגמה, אפשר לקשר בין vpc-net-a (רשת הדיירים של Agent Gateway) לבין vpc-net-b (הרשת המצורפת), שמקושרת ל-vpc-net-c (הרשת המרוחקת) כדי לפתור שאילתות DNS בכל השרשרת.

כדי להגדיר קישור בין רשתות שכנות (peering) ב-DNS:

מגדירים את תחום ה-DNS הפרטי ברשת ה-VPC המטורגטת. כדי להוסיף רשומות DNS לאזור ה-DNS הפרטי, קראו את המאמר הוספת קבוצת רשומות משאבים.
כדי להגדיר את תבנית הקישוריות שתאפשר את הקישור, צריך לאסוף את הפרטים הבאים:
- ‫Target network URI (targetNetwork): שימו לב ל-URI המלא של המשאב ברשת היעד של VPC, בפורמט הבא: projects/TARGET_VPC_PROJECT_ID/global/networks/TARGET_VPC_NETWORK_NAME. רשת היעד היא תמיד רשת ה-VPC שמכילה את רשת המשנה שאליה מפנה מחבר הרשת. אם רשת היעד היא רשת VPC משותפת, חשוב להשתמש במזהה הפרויקט המארח של ה-VPC המשותף.
- שמות דומיינים: סיומת אחת או יותר של אתרים לקישור בין רשתות שכנות (peering) ב-DNS. כל דומיין חייב להסתיים בנקודה (.) (לדוגמה, corp.internal. או googleapis.com.).
  
  במאמר תבניות דומיינים של קישור בין רשתות שכנות (peering) ב-DNS מוסבר איך להגדיר את השדה domains. לפריסות בכמה פרויקטים, כמו VPC משותף, ראו דרישות לתחום DNS ולקישור בין רשתות שכנות בכמה פרויקטים.

אופציונלי: הגדרת אישורי TLS מהימנים

אם היעד משתמש ב-CA פרטי או באישור בחתימה עצמית, צריך ליצור משאב TrustConfig ב-Certificate Manager. המשאב TrustConfig מגדיר את ישויות העוגן האמינות והאישורים שמשמשים את Agent Gateway לאימות חיבורי TLS.

מכינים את קובצי האישורים בפורמט PEM:
- מאגר אישורים: אישורי CA בסיסיים או אישורי ביניים בפורמט PEM. ‫Agent Gateway נותן אמון בכל אישור שרת ששרשרת האמון שלו מובילה לאחד מאישורי ה-CA האלה. מאגר האישורים חייב להכיל לפחות אישור CA אחד ברמת הבסיס או ברמת הביניים.
- אישורים ברשימת ההיתרים (אופציונלי): אישורי שרת בפורמט PEM שאתם רוצים לסמוך עליהם באופן מפורש, כמו אישור בחתימה עצמית.
מריצים את הפקודה הבאה כדי ליצור את המשאב TrustConfig. צריך ליצור את TrustConfig באותו פרויקט ובאותו אזור שבהם נמצאים Agent Gateway ותבנית הקישוריות.
```
gcloud certificate-manager trust-configs create TRUST_CONFIG_NAME \
    --location=LOCATION \
    --trust-store="trust-anchors=ROOT_CERT_FILE" \
    --allowlisted-certificates=ALLOWLISTED_CERT_FILE
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫TRUST_CONFIG_NAME: שם למשאב TrustConfig.
- ‫LOCATION: האזור של הגדרת האמון (לדוגמה, europe-west1). הוא חייב להיות אותו אזור של Agent Gateway ושל תבנית הקישוריות.
- ‫ROOT_CERT_FILE: הנתיב לאישור ה-CA ברמה הבסיסית (root) או ברמת הביניים (intermediate) בקידוד PEM.
- ‫ALLOWLISTED_CERT_FILE: (אופציונלי) הנתיב לאישור בקידוד PEM שרוצים לתת בו אמון באופן מפורש. אם אתם לא משתמשים באישורים מרשימת ההיתרים, השמיטו את הדגל הזה.
מידע נוסף על ניהול הגדרות האמון זמין במאמר יצירה וניהול של הגדרות אמון.

פריסת Agent Gateway

יוצרים את קובץ התצורה של תבנית הקישוריות:

יוצרים קובץ YAML בשם agw-connectivity-template.yaml:
```
name: projects/AGENT_GATEWAY_PROJECT_NUMBER/locations/LOCATION/agentConnectivityTemplates/CONNECTIVITY_TEMPLATE_NAME
accessPath: AGENT_TO_ANYWHERE
deploymentModel: CENTRALIZED
egressNetworkConfig:
  networkAttachment: projects/NETWORK_ATTACHMENT_PROJECT_NUMBER/regions/NETWORK_ATTACHMENT_REGION/networkAttachments/NETWORK_ATTACHMENT_NAME
  dnsPeeringConfig:
    domains:
      - DOMAIN_NAME
    targetNetwork: projects/TARGET_VPC_PROJECT_ID/global/networks/TARGET_VPC_NETWORK_NAME
  vpcEgress: VPC_EGRESS_MODE
  tlsConfig:
    trustConfig: projects/AGENT_GATEWAY_PROJECT_NUMBER/locations/LOCATION/trustConfigs/TRUST_CONFIG_NAME
    additionalRoots: ADDITIONAL_ROOTS_OPTION
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫AGENT_GATEWAY_PROJECT_NUMBER: מספר הפרויקט ב- Google Cloud שבו אתם מקצים את Agent Gateway. כדי לאחזר את מספר הפרויקט, מריצים את הפקודה: gcloud projects describe PROJECT_ID --format="value(projectNumber)".
- ‫LOCATION: האזור של תבנית הקישוריות (לדוגמה, europe-west1).
- ‫CONNECTIVITY_TEMPLATE_NAME: השם של משאב תבנית הקישוריות.
- ‫accessPath: נתיב הגישה המנוהלת של תבנית הקישוריות. מגדירים את הערך AGENT_TO_ANYWHERE (תבניות קישוריות נתמכות רק בשערי תעבורת נתונים יוצאת).
- ‫deploymentModel: מודל הפריסה של השער. מגדירים את הערך CENTRALIZED.
- ‫networkAttachment: ה-URI המלא של המשאב של מחבר הרשת של Private Service Connect:
  - ‫NETWORK_ATTACHMENT_PROJECT_NUMBER: מספר הפרויקט שבו יצרתם את חיבור הרשת. הפרויקט הזה יכול להיות אותו פרויקט של Agent Gateway, או פרויקט אחר אם אתם מקצים את Agent Gateway בפרויקט שירות של VPC משותף ויוצרים את מחבר הרשת בפרויקט המארח של ה-VPC המשותף.
  - ‫NETWORK_ATTACHMENT_REGION: האזור שמכיל את חיבור הרשת.
  - ‫NETWORK_ATTACHMENT_NAME: השם של חיבור הרשת.
  הערה: אי אפשר לשנות את השדה networkAttachment אחרי שמגדירים אותו בתבנית הקישוריות וב-Agent Gateway. אי אפשר לשנות את חיבור הרשת של שער קיים על ידי מעבר לתבנית קישוריות אחרת.
- ‫DOMAIN_NAME: (אופציונלי) סיומת אתר אחת או יותר לקישור בין רשתות שכנות (peering) ב-DNS (לדוגמה, corp.internal.,‏ googleapis.com. או .). מוסיפים פריט לרשימה בקטע domains לכל סיומת אתר שרוצים לקשר. כל ערך חייב להסתיים בנקודה (.) וצריך להיות לו אזור מנוהל פרטי תואם ב-Cloud DNS, שמורשה לרשת היעד.
  
  במאמר תבניות דומיינים של קישור בין רשתות שכנות (peering) ב-DNS מוסבר איך להגדיר את השדה domains.
- ‫targetNetwork: (אופציונלי) ה-URI המלא של המשאב של רשת VPC היעד לקישור בין רשתות שכנות (peering) ב-DNS. רשת היעד היא תמיד רשת ה-VPC שמכילה את רשת המשנה שאליה מפנה מחבר הרשת:
  - ‫TARGET_VPC_PROJECT_ID: מזהה הפרויקט שבבעלותו רשת ה-VPC המטורגטת. אם הרשת שמכילה את רשת המשנה שאליה מפנה מחבר הרשת היא רשת VPC משותפת, אז TARGET_VPC_PROJECT_ID הוא מזהה הפרויקט המארח של ה-VPC המשותף. תמיד צריך לציין את targetNetwork באמצעות מזהה הפרויקט ולא באמצעות מספר הפרויקט.
  - ‫TARGET_VPC_NETWORK_NAME: השם של רשת היעד ב-VPC.
- ‫VPC_EGRESS_MODE: הגדרת מצב הניתוב של תעבורת הנתונים היוצאת. צריך להגדיר את הערך PRIVATE_RANGES_ONLY או ALL_TRAFFIC.
- ‫tlsConfig: (אופציונלי) הגדרת ה-TLS לאימות אישור השרת כשמתחברים לנקודות קצה פרטיות באמצעות HTTPS:
  - ‫TRUST_CONFIG_NAME: השם של המשאב TrustConfig ב-Certificate Manager שמכיל את אישורי ה-CA הפרטיים או את ישויות העוגן האמינות.
  - ‫ADDITIONAL_ROOTS_OPTION: מציין אם לתת אמון ברשויות אישורים בסיסיות מהימנות באופן ציבורי, בנוסף להגדרת האמון בהתאמה אישית:
  - מגדירים את הערך PUBLICLY_TRUSTED_ROOTS (ברירת המחדל) כדי לתת אמון גם באישורים שאומתו על ידי הפרמטר trustConfig וגם בכל רשויות האישורים (CA) הציבוריות המהימנות. אם הסוכנים שלכם מתחברים גם לממשקי API שלGoogle Cloud (*.googleapis.com) או לנקודות קצה ציבוריות אחרות של HTTPS, אתם צריכים להגדיר את additionalRoots ל-PUBLICLY_TRUSTED_ROOTS. בלי ההגדרה הזו, Agent Gateway לא ייתן אמון באישורים של googleapis.com שחתומים על ידי Google.
  - מגדירים את הערך NO_ADDITIONAL_ROOTS כדי לתת אמון רק באישורים שאומתו על ידי הפרמטר trustConfig.
  הערה: אי אפשר לשנות את השדה trustConfig אחרי שמגדירים אותו בתבנית קישוריות, ו-Agent Gateway לא מזהה באופן אוטומטי שינויים במקום ב-tlsConfig (כמו עדכון של additionalRoots) כשתבנית הקישוריות מצורפת לשער. כדי לעדכן את הגדרות ה-TLS, קראו את המאמר עדכון הגדרות היציאה של VPC.
יוצרים את תבנית הקישוריות:

מריצים את הפקודה הבאה כדי ליצור את תבנית הקישוריות:
```
gcloud network-services agent-connectivity-templates import CONNECTIVITY_TEMPLATE_NAME \
    --source="agw-connectivity-template.yaml" \
    --location=LOCATION
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫CONNECTIVITY_TEMPLATE_NAME: השם של משאב תבנית הקישוריות.
- ‫LOCATION: המיקום שבו רוצים ליצור את המשאב של תבנית הקישוריות. לדוגמה, europe-west1.
הגדרת המשאב של Agent Gateway:

מגדירים משאב חדש של Agent Gateway במצב AGENT_TO_ANYWHERE. לשם כך, יוצרים קובץ תצורה של שער ב-YAML (לדוגמה, my-agent-gateway-vpc-egress.yaml) שמפנה לתבנית הקישוריות:
```
name: AGENT_GATEWAY_NAME
protocols:
  - MCP
googleManaged:
  governedAccessPath: AGENT_TO_ANYWHERE
agentConnectivityTemplate: projects/AGENT_GATEWAY_PROJECT_NUMBER/locations/LOCATION/agentConnectivityTemplates/CONNECTIVITY_TEMPLATE_NAME
registries:
  - AGENT_REGISTRY_PATH
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫AGENT_GATEWAY_NAME: השם של המשאב ב-Agent Gateway.
- ‫AGENT_GATEWAY_PROJECT_NUMBER: מספר הפרויקט ב- Google Cloud שבו אתם מקצים את Agent Gateway ואת תבנית הקישוריות. בפריסות של VPC משותף, הפרויקט הזה יכול להיות פרויקט שירות או פרויקט מארח. כדי לאחזר את מספר הפרויקט, מריצים את הפקודה: gcloud projects describe PROJECT_ID --format="value(projectNumber)".
- ‫LOCATION: המיקום של תבנית הקישוריות (לדוגמה, europe-west1).
- ‫CONNECTIVITY_TEMPLATE_NAME: השם של משאב תבנית הקישוריות.
  - ‫AGENT_REGISTRY_PATH: הנתיב למכונה האזורית של Agent Registry באותו פרויקט ואזור כמו השער, בפורמט //agentregistry.googleapis.com/projects/PROJECT_ID/locations/LOCATION. איך מתכננים את הפריסה של Agent Gateway
ייבוא ופריסה של Agent Gateway:

מריצים את הפקודה הבאה כדי ליצור את המשאב של Agent Gateway על סמך מפרט ה-YAML:
```
gcloud network-services agent-gateways import AGENT_GATEWAY_NAME \
    --source="my-agent-gateway-vpc-egress.yaml" \
    --location=LOCATION
```
מחליפים את LOCATION במיקום שבו רוצים ליצור את המשאב של Agent Gateway. לדוגמה, europe-west1.

שיקולים שקשורים לארכיטקטורה ולרשתות

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

עדכון ההגדרות של תעבורת הנתונים היוצאת (egress) ב-VPC

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

עדכון של הגדרות הקישור בין רשתות שכנות (peering) ב-DNS, מצב תעבורת הנתונים היוצאת ב-VPC או TLS (tlsConfig): בתבנית קישוריות, אי אפשר לשנות את השדה tlsConfig.trustConfig אחרי שמגדירים אותו, ועדכונים במקום של tlsConfig (כמו הוספה או שינוי של additionalRoots) לא נקלטים על ידי Agent Gateway מצורף. כדי לעדכן את הגדרות הקישור בין רשתות שכנות (peering) ב-DNS, את מצב התעבורה היוצאת ב-VPC או את הגדרות tlsConfig בשער קיים, צריך ליצור תבנית קישוריות חדשה שמשתמשת באותו networkAttachment עם ההגדרות המעודכנות, ולעדכן את Agent Gateway כך שיפנה לתבנית החדשה (או לבטל את הקישור של תבנית הקישוריות ולקשר אותה מחדש).
שינוי של חיבור הרשת: אי אפשר לשנות את networkAttachment אחרי שמגדירים אותו בתבנית הקישוריות וב-Agent Gateway. כדי לעבור לחיבור רשת אחר (או לרשת VPC אחרת לטירגוט), צריך ליצור תבנית קישוריות חדשה ו-Agent Gateway חדש.

טופולוגיות של פריסת VPC משותף

בארכיטקטורה של VPC משותף, אתם יכולים להקצות את Agent Gateway בפרויקט שירות או בפרויקט המארח. כשמקצים את Agent Gateway בפרויקט שירות, אפשר ליצור את מחבר הרשת בפרויקט השירות (מומלץ) או בפרויקט המארח:

מומלץ: חיבור רשת בפרויקט שירות:
1. יוצרים את רשת המשנה בפרויקט המארח.
2. יוצרים את מחבר הרשת בפרויקט השירות, ומפנים לרשת המשנה של הפרויקט המארח.
חיבור לרשת בפרויקט המארח:
1. יוצרים את רשת המשנה בפרויקט המארח.
2. יוצרים את חיבור הרשת בפרויקט המארח.

תאימות ל-VPC Service Controls

כדי לאכוף את גבולות הגזרה של VPC Service Controls על התקשורת של הסוכן, צריך לוודא ש:

מגדירים את vpcEgress ל-ALL_TRAFFIC בתבנית הקישוריות.
מפנים את בקשות ה-API של Google לטווח ה-IP של restricted.googleapis.com (199.36.153.4/30) או לנקודת קצה פנימית של Private Service Connect לממשקי Google API.
צריך להגדיר את פענוח ה-DNS של googleapis.com. יוצרים תחום DNS פרטי ב-Cloud DNS ברשת ה-VPC שממפה את *.googleapis.com ל-restricted.googleapis.com, וכוללים את googleapis.com. בשדה domains של תבנית הקישוריות.

לפרטים נוספים על הגדרת DNS, קראו את המאמר הגדרת DNS ל-googleapis.com במסמכי התיעוד של "גישה פרטית ל-Google".
בפריסות של VPC משותף, הפרויקט המארח שבבעלותו נמצאת רשת המשנה של מחבר הרשת וה-dnsPeeringConfig.targetNetwork חייבים להיות באותם גבולות גזרה לשירות כמו הפרויקט שבו פורסים את Agent Gateway. זה נכון גם כשיוצרים את חיבור הרשת בפרויקט השירות, כי רשת המשנה ורשת ה-VPC עדיין שייכות לפרויקט המארח. אם תחומי ה-DNS הפרטיים מתארחים בפרויקט DNS נפרד, צריך לכלול גם את הפרויקט הזה בהיקף.

תבניות דומיינים של קישור בין רשתות שכנות (peering) ב-DNS

בקטע הזה מתוארים דפוסי פתרון שמות דומיינים ואפשרויות להגדרת השדה domains בתבנית קישוריות.

הגדרת שם הדומיין: מגדירים את השדה domains בתבנית הקישוריות לפי השיקולים הבאים:

דומיינים פנימיים פרטיים: כדי לפתור שירותים פנימיים פרטיים שמתארחים ברשת ה-VPC (לדוגמה, service.corp.internal), צריך לציין את הסיומת של הדומיין הפנימי (למשל corp.internal.). צריך לאשר אזור מנוהל פרטי ב-Cloud DNS עם התאמה מדויקת לדומיין הזה בשביל רשת ה-VPC המטורגטת.
Split-horizon DNS (דומיין ציבורי עם כתובת IP מסוג RFC 1918): אם אתם משתמשים ב<b>תחום DNS</b> ציבורי כדי לארח רשומות שמפנות לכתובות IP פרטיות פנימיות (למשל, mcp.example.com שמפנה לכתובת RFC 1918 בשביל אישורים ציבוריים של Certificate Manager), השער פותר את הרשומות האלה באופן אוטומטי באמצעות DNS רקורסיבי ציבורי, בלי צורך בקישור בין רשתות שכנות (peering) ב-DNS.
ממשקי API שלGoogle Cloud עם VPC Service Controls: כשמגדירים את ALL_TRAFFIC לאכוף את VPC Service Controls, בקשות ל-Google API צריכות להפנות לטווח ה-IP של restricted.googleapis.com (199.36.153.4/30) או לנקודות קצה פנימיות של PSC. יוצרים תחום Cloud DNS פרטי ברשת ה-VPC שממפה את *.googleapis.com ל-restricted.googleapis.com, וכוללים את googleapis.com. בשדה domains של תבנית הקישוריות.
דפוסי פתרון של כמה דומיינים: אם הפריסה שלכם דורשת פתרון של כמה סיומות אתרים פרטיות, בחרו באחד מהדפוסים הבאים:
- קישור של כמה דומיינים נפרדים: מציינים רשימה של סיומות אתרים בשדה domains של dnsPeeringConfig (לדוגמה, corp.internal.,‏ prod.internal. ו-googleapis.com.). כל דומיין ברשימה חייב להסתיים בנקודה (.) ולהיות בעל אזור פרטי מנוהל תואם ב-Cloud DNS, שמורשה לרשת ה-VPC המטורגטת.
- סיומת אתר הורה מאוחדת (מומלץ): מאחדים שירותים פנימיים תחת סיומת אתר הורה משותפת (כמו *.internal. או *.corp.internal.) וכוללים את דומיין ההורה הזה ברשימת domains.
- קישור בין רשתות שכנות (peering) של שורש כולל עם אזור העברה פרטי: כוללים את "." בשדה domains של תבנית הקישוריות, ומגדירים אזור העברה פרטי של Cloud DNS לדומיין הבסיסי (.) ברשת ה-VPC, שמפנה למפענח רקורסיבי במעלה הזרם (כמו 8.8.8.8 או מפענח ארגוני פנימי). אזורים פרטיים ספציפיים יותר ב-VPC שלכם תואמים קודם כל לפי ההתאמה הארוכה ביותר של הסיומת, ושאילתות ציבוריות שלא תואמות נפתרות באמצעות ה-upstream forwarder.
  
  זהירות: מומלץ להימנע מהגדרה של אזור פרטי מוסמך לדומיין הבסיסי (.). אזור בסיסי מוסמך פותר רק רשומות שמוגדרות בתוכו ומחזיר NXDOMAIN לכל שאר הדומיינים, מה שיכול למנוע פתרון של נקודות קצה חיצוניות של SaaS ושל ממשקי API של Google Cloud .

דרישות לגבי תחום DNS וקישור בין פרויקטים שונים

ההגדרה dnsPeeringConfig של תבנית הקישוריות לא תומכת בקישור ישיר בין רשתות שכנות (peering) ב-Cloud DNS בין פרויקטים. כשמייבאים את תבנית הקישוריות, האימות נכשל אם רשת המשנה שאליה מפנה networkAttachment שייכת לרשת VPC שונה מ-targetNetwork, או אם אתם מסתמכים על קישור של תחום DNS בין פרויקטים משירות או מפרויקט חיצוני.

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

אזור פרטי מוסמך
אזור העברה
תחום קישור בין רשתות שכנות (peering) ב-Cloud DNS: צריך להיות משויך לרשת ה-VPC של הפרויקט המארח ולטרגט רשת VPC של יעד. ה-VPC של היעד צריך לפתור את השאילתה ישירות באמצעות אזור פרטי מוסמך. העברת השאילתה לתחום קישור בין רשתות שכנות (peering zone) אחר ב-DNS (שרשור) אינה נתמכת וגורמת לשגיאה NXDOMAIN.

הרחבת פרויקטים של שירות Agent Runtime באמצעות קבוצה ב-Google

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

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

יצירת קבוצת אבטחה: יוצרים קבוצת אבטחה במסוף Google Admin או על ידי הפעלת הפקודה gcloud identity groups create.

הערה: כדי להוסיף סוכני שירות לקבוצה ב-Google, צריך להפעיל את האפשרות חברים חיצוניים בקבוצה.
נותנים לקבוצה גישה לפרויקט המארח של Agent Gateway: מקשרים את הקבוצה לתפקיד "צפייה בשירותי רשת" (roles/networkservices.viewer) ב-AGENT_GATEWAY_PROJECT_ID:
```
gcloud projects add-iam-policy-binding AGENT_GATEWAY_PROJECT_ID \
    --member="group:GROUP_EMAIL" \
    --role="roles/networkservices.viewer"
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫AGENT_GATEWAY_PROJECT_ID: מזהה הפרויקט המארח של Agent Gateway.
- ‫GROUP_EMAIL: כתובת האימייל של קבוצת האבטחה (לדוגמה, agw-cross-project-runtime@example.com).
מוסיפים לקבוצה את סוכן השירות של Agent Runtime בכל פרויקט שירות: בכל פרויקט שירות של Agent Runtime, מוסיפים את סוכן השירות לקבוצת האבטחה באמצעות הפקודה gcloud identity groups memberships add:
```
gcloud identity groups memberships add \
    --group-email="GROUP_EMAIL" \
    --member-email="service-AGENT_RUNTIME_PROJECT_NUMBER@gcp-sa-aiplatform.iam.gserviceaccount.com"
```
מחליפים את הערך AGENT_RUNTIME_PROJECT_NUMBER במספר הפרויקט של Agent Runtime.

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

מדריך

הגדרת Agent Gateway עם קישוריות ל-VPC

איך פועל הקישוריות ל-VPC

מצבי תעבורת נתונים יוצאת (egress) של VPC

פענוח DNS וניתוב תעבורת נתונים

הדרישות לגבי אישור TLS

תפקידים והרשאות נדרשים

פריסות של פרויקטים עצמאיים

פריסות של VPC משותף או פריסות בכמה פרויקטים

הגדרת הקישוריות ל-VPC

יצירת חיבור רשת של Private Service Connect

אופציונלי: הגדרת קישור בין רשתות שכנות (peering) ב-DNS

אופציונלי: הגדרת אישורי TLS מהימנים

פריסת Agent Gateway

שיקולים שקשורים לארכיטקטורה ולרשתות

עדכון ההגדרות של תעבורת הנתונים היוצאת (egress) ב-VPC

טופולוגיות של פריסת VPC משותף

תאימות ל-VPC Service Controls

תבניות דומיינים של קישור בין רשתות שכנות (peering) ב-DNS

דרישות לגבי תחום DNS וקישור בין פרויקטים שונים

הרחבת פרויקטים של שירות Agent Runtime באמצעות קבוצה ב-Google

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

ניתוב התנועה של Agent Runtime דרך Agent Gateway

‫Codelab: ניהול עומסי עבודה של סוכנים באמצעות Agent Platform

‫Codelab: תעבורת נתונים יוצאת של Agent Gateway מ-Agent Runtime לרשתות VPC

הקצאת הרשאות ל-Agent Gateway

ניהול Agent Gateway

מעקב אחרי Agent Gateway

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

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

איך פועל הקישוריות ל-VPC

מצבי תעבורת נתונים יוצאת (egress) של VPC

פענוח DNS וניתוב תעבורת נתונים

הדרישות לגבי אישור TLS

תפקידים והרשאות נדרשים

פריסות של פרויקטים עצמאיים

פריסות של VPC משותף או פריסות בכמה פרויקטים

הגדרת הקישוריות ל-VPC

יצירת חיבור רשת של Private Service Connect

אופציונלי: הגדרת קישור בין רשתות שכנות (peering) ב-DNS

אופציונלי: הגדרת אישורי TLS מהימנים

פריסת Agent Gateway

שיקולים שקשורים לארכיטקטורה ולרשתות

עדכון ההגדרות של תעבורת הנתונים היוצאת (egress) ב-VPC

טופולוגיות של פריסת VPC משותף

תאימות ל-VPC Service Controls

תבניות דומיינים של קישור בין רשתות שכנות (peering) ב-DNS

דרישות לגבי תחום DNS וקישור בין פרויקטים שונים

הרחבת פרויקטים של שירות Agent Runtime באמצעות קבוצה ב-Google

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

ניתוב התנועה של Agent Runtime דרך Agent Gateway

‫Codelab: ניהול עומסי עבודה של סוכנים באמצעות Agent Platform

‫Codelab: תעבורת נתונים יוצאת של Agent Gateway מ-Agent Runtime לרשתות VPC

הקצאת הרשאות ל-Agent Gateway

ניהול Agent Gateway

מעקב אחרי Agent Gateway

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

הגדרת Agent Gateway עם קישוריות ל-VPC