פריסת Secure Web Proxy בתור Agent Gateway

בדף הזה מוסבר איך להגדיר ולפרוס את המכונה של Secure Web Proxy בתור Agent Gateway.

סקירה כללית

עומסי עבודה של AI בארגון שנפרסים ב- Google Cloud דורשים גבולות רשת מובְנים כדי לשמור על תאימות לפרטיות הנתונים, למנוע דליפות של נתונים רגישים ולהגן מפני איומי AI חדשים כמו החדרת הנחיות.

‫Agent Gateway מספק ניהול אבטחה מרכזי, אכיפת זהויות ומעקות בטיחות לתוכן בתנועה יוצאת מסוכני AI אל מודלים גדולים של שפה (LLM), כלים של Model Context Protocol (MCP), ממשקי API חיצוניים, סוכנים מרוחקים ויעדי אינטרנט רגילים.

אתם יכולים לפרוס Agent Gateway בניהול Google או מכונה של Secure Web Proxy בתור Agent Gateway בניהול עצמי. שני מודלי הפריסה מספקים פתרון משותף לניהול משילות מידע ב-Gemini Enterprise Agent Platform, כולל כללי מדיניות גישה ריכוזיים, שילוב עם Agent Registry ומעקות בטיחות לתוכן.

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

  • ‫Agent Gateway בניהול Google: אפשרות שמתאימה למי שרוצה חוויה מנוהלת לחלוטין, בלי צורך בתחזוקה או בניהול של תשתית שרת ה-proxy ברשת. מידע נוסף מופיע במאמר Agent Gateway בניהול Google. המודל הזה מותאם לסוכנים שפועלים ב-Gemini Enterprise או ב-Agent Runtime ב-Gemini Enterprise Agent Platform.

  • ‫Secure Web Proxy בתור Agent Gateway בניהול עצמי: אתם יכולים לפרוס את המכונה של Secure Web Proxy בתור Agent Gateway אם אתם רוצים לשמור על שליטה מלאה בפרימטר של רשת ה-VPC, באישורי ה-CA הפרטיים ובניתוב של שרת ה-Proxy כדי לתמוך בסוכנים שפועלים ב-Google Kubernetes Engine ‏(GKE) או ב-Cloud Run.

יתרונות

פריסת Secure Web Proxy בתור Agent Gateway מספקת את היתרונות הבאים:

  • תשתית בשליטת הלקוח: אתם יכולים לנהל את שער Secure Web Proxy ברשת של הענן הווירטואלי הפרטי (VPC) שלכם, ולשמור על שליטה מלאה בניתוב הרשת, בכתובות ה-IP, באישורי ה-CA הפרטיים ובבדיקת ה-TLS.

  • אכיפה ריכוזית של מדיניות AI: אתם יכולים להגדיר כללי מדיניות הרשאות במשאב agentGateway. כך אתם יכולים לאכוף את המדיניות הזו ישירות בשער של Secure Web Proxy כדי להגביל את קריאות ה-API לכלי MCP, לסנן את היעדים החיצוניים של סוכני ה-AI ולהפעיל שירותים להסרת תוכן זדוני או רגיש כמו Model Armor.

  • תמיכה בסביבות זמן ריצה: אתם יכולים לנתב תנועה יוצאת מסוכני AI שמתארחים בסביבות זמן ריצה שונות, כמו GKE או Cloud Run, דרך מתחם שרת proxy אחד.

  • יכולת תצפית מותאמת לסוכנים: יומני הטרנזקציות ב-Cloud Logging מכילים באופן אוטומטי מטא-נתונים של הפעלת סוכני AI‏ (agentGatewayInfo), כולל שיטות MCP, שמות של כלים ושמות משאבים אחידים (URN) של יעדים ב-Agent Registry.

ארכיטקטורה

כך Secure Web Proxy מאבטח את תעבורת הנתונים היוצאת בתור Agent Gateway:

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

  2. ניתוב תנועה יוצאת: התנועה של הסוכן מנותבת אל Secure Web Proxy באמצעות ניתוב של שרת proxy בתוך ה-VPC או באמצעות צירופי שירות של Private Service Connect (PSC) בין רשתות VPC.

  3. הערכת מדיניות והסרת תוכן זדוני או רגיש: שירות Secure Web Proxy מסיים את חיבורי ה-TLS, אוכף את מדיניות ההרשאות של MCP ומפעיל שירותי תוספים כמו Model Armor או Identity-Aware Proxy ‏(IAP) כדי להסיר תוכן זדוני או רגיש מהמטענים הייעודיים (payloads) ולאמת את זהות הלקוח.

לפני שמתחילים

לפני שפורסים את המכונה של Secure Web Proxy בתור Agent Gateway, צריך לבצע את הפעולות הבאות:

  1. מפעילים את ממשקי ה-API הנדרשים הבאים של Google Cloud :

    gcloud services enable \
    networkservices.googleapis.com \
    networksecurity.googleapis.com \
    privateca.googleapis.com \
    certificatemanager.googleapis.com \
    serviceextensions.googleapis.com \
    agentregistry.googleapis.com \
    compute.googleapis.com

  2. מוודאים שיש לכם את התפקידים הנדרשים הבאים בניהול זהויות והרשאות גישה (IAM):

  3. מגדירים את משתני הסביבה הבאים לפריסה:

    export PROJECT_ID="my-project-id"
export PROJECT_NUMBER="my-project-number"
export REGION="us-central1"
export NETWORK_NAME="swp-vpc"
export PROXY_SUBNET_NAME="swp-proxy-subnet"
export PSC_NAT_SUBNET_NAME="swp-psc-nat-subnet"
export CA_POOL_NAME="swp-ca-pool"
export ROOT_CA_NAME="swp-root-ca"
export TLS_INSPECTION_POLICY_NAME="swp-tls-inspection-policy"
export SECURE_WEB_PROXY_NAME="swp-agent-gateway"
export SWP_IP_ADDRESS="10.129.0.10"
export SWP_CERTIFICATE_NAME="swp-cert"
export SERVER_TLS_POLICY_NAME="swp-server-tls-policy"
export GATEWAY_SECURITY_POLICY_NAME="swp-security-policy"
export SERVICE_ATTACHMENT_NAME="swp-service-attachment"
export AGENT_GATEWAY_NAME="my-agent-gateway"

  4. אופציונלי: אם Agent Runtime פועלים ברשתות VPC נפרדות או בסביבות מנוהלות, כמו אשכולות של GKE או Cloud Run בפרויקטים שונים, צריך לחשוף את Secure Web Proxy באמצעות צירוף שירות של Private Service Connect:

הגדרת בדיקת TLS

‫Secure Web Proxy סוגר חיבורי TLS כדי לבדוק כותרות HTTP, להעריך שיטות MCP ולנקות מטענים ייעודיים (payloads).

כדי להגדיר בדיקת TLS, יוצרים מאגר פרטי של רשויות אישורים (CA), רשות אישורים בסיסית ואז משאב tlsInspectionPolicy:

  1. יוצרים מאגר פרטי של רשויות להנפקת אישורים (CA).

    gcloud privateca pools create CA_POOL_NAME \
    --location=REGION \
    --tier=devops \
    --project=PROJECT_ID

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

    • ‫CA_POOL_NAME: שם מאגר ה-CA
    • ‫REGION: האזור שבו נוצר מאגר ה-CA
    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud

  2. יוצרים רשות אישורים בסיסית במאגר רשויות להנפקת אישורים (CA) הפרטי.

    gcloud privateca roots create ROOT_CA_NAME \
    --pool=CA_POOL_NAME \
    --location=REGION \
    --subject="CN=Agent Gateway SWP Root CA, O=MyOrganization" \
    --auto-enable \
    --project=PROJECT_ID

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

    • ‫ROOT_CA_NAME: השם של רשות האישורים ברמה הבסיסית (root CA)
    • ‫CA_POOL_NAME: שם מאגר ה-CA
    • ‫REGION: האזור שבו נוצרה רשות אישורי הבסיס
    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud

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

  3. נותנים לחשבון השירות של אבטחת רשת הרשאה לבקש אישורים.

    gcloud privateca pools add-iam-policy-binding CA_POOL_NAME \
    --location=REGION \
    --member="serviceAccount:service-PROJECT_NUMBER@gcp-sa-networksecurity.iam.gserviceaccount.com" \
    --role="roles/privateca.certificateRequester" \
    --project=PROJECT_ID

  4. יוצרים את המשאב tlsInspectionPolicy בקובץ בשם tls-inspection-policy.yaml.

    name: projects/PROJECT_ID/locations/REGION/tlsInspectionPolicies/TLS_INSPECTION_POLICY_NAME
caPool: projects/PROJECT_ID/locations/REGION/caPools/CA_POOL_NAME

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

    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud
    • ‫REGION: האזור שבו נוצר TlsInspectionPolicy
    • ‫TLS_INSPECTION_POLICY_NAME: שם המשאב של TlsInspectionPolicy
    • ‫CA_POOL_NAME: שם מאגר ה-CA

  5. כדי לייבא את המדיניות, מריצים את הפקודה gcloud network-security tls-inspection-policies import.

    gcloud network-security tls-inspection-policies import TLS_INSPECTION_POLICY_NAME \
    --source=tls-inspection-policy.yaml \
    --location=REGION \
    --project=PROJECT_ID

פריסת Secure Web Proxy

יוצרים שער Secure Web Proxy עם הגדרה של Mutual TLS ‏(mTLS).

  1. מוודאים שברשת ה-VPC יש תת-רשת של שרת proxy בלבד באזור שבו רוצים לפרוס את השער.

    gcloud compute networks subnets create PROXY_SUBNET_NAME \
    --purpose=REGIONAL_MANAGED_PROXY \
    --role=ACTIVE \
    --region=REGION \
    --network=NETWORK_NAME \
    --range=10.129.0.0/23

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

    • ‫PROXY_SUBNET_NAME: השם של רשת המשנה לשרתי proxy בלבד
    • ‫NETWORK_NAME: השם של רשת ה-VPC
    • ‫REGION: האזור שבו נוצרה תת-הרשת

  2. אופציונלי: בוחרים כתובת IP זמינה מטווח תת-הרשת של שרתי ה-Proxy בלבד – לדוגמה, 10.129.0.10 בתוך 10.129.0.0/23 – כדי להקצות ל-SWP_IP_ADDRESS.

    הערה: אם לא מוסיפים את השדה addresses בקובץ swp.yaml, ‏Secure Web Proxy מקצה באופן אוטומטי כתובת IP מרשת המשנה לשרתי proxy בלבד.

  3. כדי לוודא ששער Secure Web Proxy יכול לקבל באופן מאובטח חיבורים נכנסים של סוכני לקוח, צריך ליצור אישור שרת SSL/TLS אזורי בCertificate Manager.

    1. יוצרים אישור בניהול עצמי ומפתח פרטי.

      openssl req -x509 -newkey rsa:2048 -nodes \
    -keyout "swp.key" \
    -out "swp.crt" \
    -days 365 \
    -subj "/CN=SWP_IP_ADDRESS"

      מחליפים את SWP_IP_ADDRESS בכתובת ה-IP של שער Secure Web Proxy.

    2. כדי להעלות את האישור ל-Certificate Manager, מריצים את הפקודה gcloud certificate-manager certificates create.

      gcloud certificate-manager certificates create SWP_CERTIFICATE_NAME \
    --location=REGION \
    --certificate-file="swp.crt" \
    --private-key-file="swp.key" \
    --project=PROJECT_ID

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

      • ‫SWP_CERTIFICATE_NAME: שם משאב האישור
      • ‫REGION: האזור שבו נוצר האישור
      • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud

  4. כדי להפעיל mTLS בקצה הקדמי, יוצרים משאב ServerTlsPolicy. כדי לאפשר לעומסי עבודה, כמו Cloud Run, להעביר את אישורי הזהות שלהם לשירותים כמו IAP, צריך להגדיר את המדיניות באמצעות clientValidationMode: ALLOW_INVALID_OR_MISSING_CLIENT_CERT.

    הערה: אם אתם משתמשים ב-IAP, אל תגדירו ערך בשדה clientValidationTrustConfig כי הוא לא נתמך.

    1. יוצרים קובץ בשם server-tls-policy.yaml ומוסיפים את התוכן הבא:

      name: projects/PROJECT_ID/locations/REGION/serverTlsPolicies/SERVER_TLS_POLICY_NAME
mtlsPolicy:
  clientValidationMode: ALLOW_INVALID_OR_MISSING_CLIENT_CERT

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

      • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud
      • ‫REGION: האזור שבו נוצר ServerTlsPolicy
      • ‫SERVER_TLS_POLICY_NAME: שם המשאב של ServerTlsPolicy

    2. כדי לייבא את המדיניות, מריצים את הפקודה gcloud network-security server-tls-policies import.

      gcloud network-security server-tls-policies import SERVER_TLS_POLICY_NAME \
    --source=server-tls-policy.yaml \
    --location=REGION \
    --project=PROJECT_ID

  5. יוצרים מדיניות אבטחה של שער כדי לצרף את tlsInspectionPolicy.

    1. יוצרים קובץ בשם gateway-security-policy.yaml ומוסיפים את התוכן הבא:

      name: projects/PROJECT_ID/locations/REGION/gatewaySecurityPolicies/GATEWAY_SECURITY_POLICY_NAME
tlsInspectionPolicy: projects/PROJECT_ID/locations/REGION/tlsInspectionPolicies/TLS_INSPECTION_POLICY_NAME

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

      • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud
      • ‫REGION: האזור שבו נוצר GatewaySecurityPolicy
      • ‫GATEWAY_SECURITY_POLICY_NAME: שם המשאב של GatewaySecurityPolicy
      • ‫TLS_INSPECTION_POLICY_NAME: שם המשאב של TlsInspectionPolicy

    2. כדי לייבא את המדיניות, מריצים את הפקודה gcloud network-security gateway-security-policies import.

      gcloud network-security gateway-security-policies import GATEWAY_SECURITY_POLICY_NAME \
    --source=gateway-security-policy.yaml \
    --location=REGION \
    --project=PROJECT_ID

  6. יוצרים קובץ מפרט של Secure Web Proxy בשם swp.yaml.

    name: projects/PROJECT_ID/locations/REGION/gateways/SECURE_WEB_PROXY_NAME
type: SECURE_WEB_GATEWAY
addresses:
  - "SWP_IP_ADDRESS"
ports:
  - 443
routingMode: EXPLICIT_ROUTING_MODE
certificateUrls:
  - projects/PROJECT_ID/locations/REGION/certificates/SWP_CERTIFICATE_NAME
serverTlsPolicy: projects/PROJECT_ID/locations/REGION/serverTlsPolicies/SERVER_TLS_POLICY_NAME
network: projects/PROJECT_ID/global/networks/NETWORK_NAME
subnetwork: projects/PROJECT_ID/regions/REGION/subnetworks/PROXY_SUBNET_NAME
gatewaySecurityPolicy: projects/PROJECT_ID/locations/REGION/gatewaySecurityPolicies/GATEWAY_SECURITY_POLICY_NAME

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

    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud
    • ‫REGION: האזור שבו נוצר שער Secure Web Proxy
    • ‫SECURE_WEB_PROXY_NAME: השם של שער Secure Web Proxy
    • ‫SWP_IP_ADDRESS: כתובת ה-IP של שער Secure Web Proxy
    • ‫SWP_CERTIFICATE_NAME: שם האישור שמשויך לשער של Secure Web Proxy
    • ‫SERVER_TLS_POLICY_NAME: השם של המשאב ב-ServerTlsPolicy
    • ‫NETWORK_NAME: השם של רשת ה-VPC
    • ‫PROXY_SUBNET_NAME: השם של רשת המשנה לשרתי proxy בלבד
    • ‫GATEWAY_SECURITY_POLICY_NAME: שם המשאב של GatewaySecurityPolicy

  7. כדי לייבא את שער Secure Web Proxy, מריצים את הפקודה gcloud network-services gateways import.

    gcloud network-services gateways import SECURE_WEB_PROXY_NAME \
    --source=swp.yaml \
    --location=REGION \
    --project=PROJECT_ID

כדי לשנות את השדות האלה בשער קיים של Secure Web Proxy בלי לגרום להשבתה של עומס העבודה:

  1. יוצרים שער Secure Web Proxy אחר עם שם חדש וההגדרות הנדרשות.

  2. מעדכנים את המשאב agentGateway (selfManaged.resourceUris) כך שיפנה לשער הגישה החדש של Secure Web Proxy.

  3. מעדכנים את המשאב EgressRouting כך שיפנה לשער החדש של Secure Web Proxy.

  4. אחרי שמוודאים שהשער החדש מנהל בהצלחה את נתיבי התנועה, מסירים את השער הישן של Secure Web Proxy מהמשאב agentGateway ואז מוחקים את משאב השער הישן.

שיוך המכונה של Secure Web Proxy ל-Agent Gateway

כדי לשייך את המכונה של Secure Web Proxy למשאב agentGateway:

  1. יוצרים קובץ תצורה בשם agent-gateway.yaml.

    name: projects/PROJECT_ID/locations/REGION/agentGateways/AGENT_GATEWAY_NAME
selfManaged:
  resourceUris:
    - //networkservices.googleapis.com/projects/PROJECT_ID/locations/REGION/gateways/SECURE_WEB_PROXY_NAME
registries:
  - //agentregistry.googleapis.com/projects/PROJECT_ID/locations/REGION

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

    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud
    • ‫REGION: האזור שבו נוצר Agent Gateway
    • ‫AGENT_GATEWAY_NAME: השם של Agent Gateway
    • ‫SECURE_WEB_PROXY_NAME: השם של מכונת Secure Web Proxy

    אופציונלי: השדה registries משייך את Agent Gateway ל-Agent Registry. אם אתם לא רוצים להשתמש ב-Agent Registry כדי לפתור בעיות ביעד או בכלי, אל תציינו את השדה registries.

  2. כדי לייבא את המשאב agentGateway, מריצים את הפקודה gcloud beta network-services agent-gateways import.

    gcloud beta network-services agent-gateways import AGENT_GATEWAY_NAME \
    --source=agent-gateway.yaml \
    --location=REGION \
    --project=PROJECT_ID

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

כדי לנהל את תעבורת הנתונים היוצאת של סוכן ה-AI, צריך להגדיר קישורי תוספים ומדיניות הרשאה במשאב agentGateway. שרת ה-proxy מתעלם מכל כללי המדיניות שמצורפים ישירות למשאב Gateway של Secure Web Proxy.

‫Agent Gateway תומך בשתי שכבות הפיקוח הבאות:

  • קישורי תוספים: צירוף שירותי אבטחה ופיקוח חיצוניים, כמו IAP ו-Model Armor, ישירות ל-Agent Gateway באמצעות Service Extensions.

  • כללי מדיניות הרשאה: אכיפת ההגבלות של שיטת L7 MCP וכללי הרשת של L4.

צירוף קישורי תוספים ל-Agent Gateway

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

שלב 1: מקשרים את Identity-Aware Proxy ‏(IAP) ל-Agent Gateway

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

  1. יוצרים קובץ תצורה בשם ext-binding-iap.yaml.

    name: ext-binding-iap
target:
  resources:
  - "//networkservices.googleapis.com/projects/PROJECT_ID/locations/REGION/agentGateways/AGENT_GATEWAY_NAME"
failOpen: false
producerExtension: iap.googleapis.com
matchConditions:
- to:
    destination:
      resources:
      - prefix: "urn:mcp"
    notDestinations:
      hosts:
      - suffix: ".googleapis.com"

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

    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud
    • ‫REGION: האזור שבו נוצר הקישור של התוסף
    • ‫AGENT_GATEWAY_NAME: השם של Agent Gateway

  2. כדי לייבא את הקישור של התוסף, מריצים את הפקודה gcloud beta service-extensions extension-bindings import.

    gcloud beta service-extensions extension-bindings import ext-binding-iap \
    --source=extension-binding-iap.yaml \
    --location=REGION

מידע נוסף זמין במאמר הקצאת הרשאה ל-IAP.

שלב 2: קישור של Model Armor להסרת תוכן זדוני או רגיש מההנחיות ומהתשובות

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

  1. יוצרים קובץ תצורה בשם ext-binding-model-armor.yaml.

    name: ext-binding-model-armor
target:
  resources:
  - "//networkservices.googleapis.com/projects/PROJECT_ID/locations/REGION/agentGateways/AGENT_GATEWAY_NAME"
failOpen: false
producerExtension: modelarmor.googleapis.com
producerMetadata:
  model_armor_settings: '[
    {
      "request_template_id": "projects/PROJECT_ID/locations/REGION/templates/REQUEST_TEMPLATE_ID",
      "response_template_id": "projects/PROJECT_ID/locations/REGION/templates/RESPONSE_TEMPLATE_ID"
    }
  ]'
matchConditions:
- to:
    destination:
      resources:
      - prefix: "urn:mcp"

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

    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud
    • ‫REGION: האזור שבו נוצר הקישור של התוסף
    • ‫AGENT_GATEWAY_NAME: השם של Agent Gateway
    • ‫REQUEST_TEMPLATE_ID: מזהה תבנית הבקשה של Model Armor
    • ‫RESPONSE_TEMPLATE_ID: המזהה של תבנית התשובה של Model Armor

  2. כדי לייבא את הקישור של התוסף, מריצים את הפקודה gcloud beta service-extensions extension-bindings import.

    gcloud beta service-extensions extension-bindings import ext-binding-model-armor \
    --source=extension-binding-model-armor.yaml \
    --location=REGION

מידע נוסף זמין במאמר הענקת הרשאה ל-Model Armor ובקטע דוגמה 3: הפעלת בדיקה מעמיקה של המטען הייעודי (payload) באמצעות Model Armor באמצעות קישורי תוספים במאמר הגדרת מדיניות הרשאות ל-Secure Web Proxy.

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

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

  1. יוצרים קובץ תצורה בשם authz-policy-restrict-mcp-tools.yaml.

    name: authz-policy-restrict-mcp-tools
target:
  resources:
  - "projects/PROJECT_ID/locations/REGION/agentGateways/AGENT_GATEWAY_NAME"
policyProfile: REQUEST_AUTHZ
httpRules:
- to:
    operations:
    - mcp:
        baseProtocolMethodsOption: MATCH_BASE_PROTOCOL_METHODS
        methods:
        - name: "tools/list"
        - name: "tools/call"
          params:
          - exact: "get_weather"
          - exact: "get_location"
action: ALLOW

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

    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud
    • ‫REGION: האזור שבו נוצרה מדיניות ההרשאה
    • ‫AGENT_GATEWAY_NAME: השם של Agent Gateway

  2. כדי לייבא את מדיניות ההרשאות, מריצים את הפקודה gcloud network-security authz-policies import.

    gcloud network-security authz-policies import authz-policy-restrict-mcp-tools \
    --source=authz-policy-restrict-mcp-tools.yaml \
    --location=REGION \
    --project=PROJECT_ID

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

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

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

  • ‫GKE: משתמשים ב-Ambient Networking של Cloud Service Mesh כדי ליירט את תנועת הסוכנים היוצאת ברמת הצומת, ואז מעבירים אותה דרך מנהרת HTTP CONNECT למכונה של Secure Web Proxy. כדי להגדיר מדיניות ניתוב באשכול, קראו את המאמרים ניתוב תנועה יוצאת בסביבה דרך Secure Web Proxy ו-Agent Gateway ל-GKE.
  • ‫Cloud Run: מגדירים Direct VPC egress כדי לשלוח תעבורת נתונים יוצאת של הסוכן לרשת ה-VPC, שבה Ambient Networking של Cloud Run מפנה את הבקשות למכונה של Secure Web Proxy דרך מנהרת HTTP CONNECT שנושאת את הזהות של הסוכן. כדי להגדיר ניתוב לתעבורת נתונים יוצאת, קראו את המאמרים Direct VPC עם רשת VPC וAgent Gateway ל-Cloud Run.

טלמטריה, רישום ביומן ומעקב

כששער Secure Web Proxy משויך למשאב Agent Gateway, יומני העסקאות מונפקים במשאב הרגיל במעקב של Secure Web Proxy networkservices.googleapis.com/Gateway. הרישום ביומן מופעל כברירת מחדל עם תדירות דגימה של 1.0.

רישום ביומן

רשומות ביומן ב-Cloud Logging משתמשות בפורמט LoadBalancerLogEntry ומכילות את השדות הבאים של סוכן ה-AI ושל המטען הייעודי (payload) של האבטחה:

  • ‫agentGatewayInfo: מכיל מטא-נתונים על הטרנזקציה של הנציג:

    • ‫agentRegistryResource: שם המשאב המלא של היעד התואם ב-Agent Registry, כמו שרת MCP או מיומנות
    • ‫destinationUrn: מידע על ה-URN של היעד
    • ‫mcpInfo: פרטי הקריאה ל-MCP JSON-RPC, כולל השיטה, כמו tools/call או resources/read, ושם הכלי או ה-URI של המשאב

  • ‫authzPolicyInfo: תוצאות הערכת ההרשאה (ALLOWED או DENIED) ושמות כללי המדיניות התואמים

  • ‫tls: פרטי משא ומתן של TLS ומאפייני אימות של אישור לקוח קריפטוגרפי (mTLS), כמו clientCertPresent ו-clientCertSha256Fingerprint

מדדי מעקב

‫Agent Gateway מייצא את המדדים הבאים ל-Cloud Monitoring:

  • משך הזמן של ה-MCP:

    • ‫gcp.mcp.server.operation.duration: זמן האחזור של הפעולות ששרת הכלים של MCP מבצע
    • ‫gcp.mcp.client.operation.duration: משך הזמן של שיחת לקוח MCP מקצה לקצה הלוך ושוב

  • זמן אחזור ב-HTTP:

    • ‫http.server.request.duration: זמן האחזור של הביצוע לבקשות נכנסות של סוכנים שהשער מעבד
    • ‫http.client.request.duration: זמן האחזור של בקשות יוצאות מהשרת proxy ליעדים חיצוניים

  • קצב העברת הנתונים:

    • ‫gcp.server.request.total_size ו-gcp.server.response.total_size: הגודל בבייטים של הבקשות והתגובות שהשער מקבל ושולח
    • ‫gcp.client.request.total_size ו-gcp.client.response.total_size: הגודל בבייטים של הבקשות והתשובות שהשער שולח ליעדים חיצוניים

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