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

האצלת הרשאות באמצעות Service Extensions

בדף הזה מוסבר איך להשתמש ב-Service Extensions כדי להאציל הרשאה ל-Agent Gateway לשרת proxy לאימות זהויות (IAP), להגנה מוגברת על המודל ולמנועי הרשאה מותאמים אישית אחרים.

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

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

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

תוספים לאישור

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

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

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

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

לפני שמתחילים, חשוב לוודא שהדרישות הבאות מתקיימות:

ה-Agent Gateway נפרס. מידע נוסף זמין במאמר בנושא הגדרת שער לסוכן.
כדי לצרף כללי מדיניות הרשאה לשער, צריכה להיות לכם הרשאת IAM‏ agentGateway.use במשאב Agent Gateway שנפרס.

הגדרת מדיניות הרשאות באמצעות תוספים

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

העברת הרשאה ל-IAP

אתם יכולים להגדיר תוסף לאישור בקשות כדי להעביר את ההחלטות לגבי הרשאות גישה ל-IAP.

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

יוצרים את מדיניות ה-IAM הנדרשת ליציאה של הסוכנים והכלים. מידע נוסף זמין במאמר בנושא יצירת מדיניות של סוכני IAM.
במאמר הגדרת Agent Gateway במצב Agent-to-Anywhere (יציאה) מוסבר איך להפעיל את IAP כשיוצרים את Agent Gateway (באמצעות הפרמטר Access authorization).

כדי להשתמש ב-IAP, הסוכנים שלכם צריכים להיות רשומים במשאב Agent Registry שקשור לשער.
הגדרת תוסף הרשאות שיפנה אל IAP.
1. מגדירים את התוסף בקובץ YAML. משתמשים בערכים לדוגמה שצוינו. אם רוצים לפרוס את התוסף במצב audit-only של הרצה יבשה, כדי לבדוק את מדיניות ההרשאות בלי לאכוף אותה, אפשר לציין את השדה iamEnforcementMode בתוך הבלוק metadata.
```
cat >iap-request-authz-extension.yaml <<EOF
name: my-iap-request-authz-ext
service: iap.googleapis.com
failOpen: true
timeout: 1s
metadata:
  iapPolicyVersion: "V1"
EOF
```
  אם רוצים לפרוס את התוסף במצב audit-only של הרצה יבשה, כדי לבדוק את מדיניות ההרשאות בלי לאכוף אותה, אפשר לציין את השדה iamEnforcementMode בתוך הבלוק metadata. כך תוכלו לאמת את המדיניות ולצמצם את הסיכון לשיבוש התנועה בגלל שגיאות בהגדרות:
```
cat >iap-request-authz-extension.yaml <<EOF
name: my-iap-request-authz-ext
service: iap.googleapis.com
failOpen: true
timeout: 1s
metadata:
  iapPolicyVersion: "V1"
  iamEnforcementMode: "DRY_RUN"
EOF
```
  כשמוכנים להתחיל לאכוף את כללי המדיניות, צריך להסיר את השדה iamEnforcementMode: "DRY_RUN" מהבלוק metadata.
2. מייבאים את תוסף ההרשאה. משתמשים בgcloud service-extensions authz-extensions import עם ערכי הדוגמה הבאים.
```
gcloud service-extensions authz-extensions import my-iap-request-authz-ext \
    --source=iap-request-authz-extension.yaml \
    --location=LOCATION
```

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

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

cat >iap-request-authz-policy.yaml <<EOF
name: my-iap-request-authz-policy
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/my-iap-request-authz-ext"
EOF

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

מייבאים את מדיניות ההרשאות לפרויקט. משתמשים בgcloud network-security authz-policies importפקודה עם הערכים לדוגמה הבאים.
```
gcloud beta network-security authz-policies import my-iap-request-authz-policy \
    --source=iap-request-authz-policy.yaml \
    --location=LOCATION
```

העברת הרשאות ל-Model Armor

אתם יכולים להגדיר תוסף הרשאה כדי להעביר את ההחלטות לגבי אבטחת תוכן של מדיניות הרשאות ל-Model Armor.

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

המסוף

כדי להשתמש במסוף Google Cloud כדי להפעיל את Model Armor עבור Agent Gateway, פועלים לפי השלבים הבאים:

יוצרים את התבניות של Model Armor שנדרשות.
במאמר הגדרת Agent Gateway מוסבר איך להפעיל את Model Armor כשיוצרים את Agent Gateway (באמצעות תיבת הסימון Enable Model Armor). תבניות של Model Armor נתמכות במצבים Client-to-Agent ו-Agent-to-Anywhere.
כשמשתמשים ב-Model Armor, צריך להעניק לחשבון השירות של Agent Gateway את ההרשאות שנדרשות כדי להשתמש בתבניות של Model Armor. חשבון השירות הוא בפורמט: service-PROJECT_NUMBER@gcp-sa-dep., כאשר PROJECT_NUMBER הוא מספר הפרויקט שבו יצרתם את השער.

חובה להשלים את השלב הזה גם אם השער והתבניות נמצאים באותו פרויקט. נותנים את התפקידים הבאים:
- התפקידים roles/modelarmor.calloutUser ו-roles/serviceusage.serviceUsageConsumer בפרויקט שמכיל את השער.
- התפקיד roles/modelarmor.user בפרויקט שמכיל את תבניות הגנה מוגברת על המודל.
כדי להשלים את השלב הזה, צריך להשתמש ב-CLI של gcloud.
```
gcloud projects add-iam-policy-binding GATEWAY_PROJECT_ID \
    --member=serviceAccount:service-GATEWAY_PROJECT_NUMBER@gcp-sa-dep. \
    --role=roles/modelarmor.calloutUser
gcloud projects add-iam-policy-binding GATEWAY_PROJECT_ID \
    --member=serviceAccount:service-GATEWAY_PROJECT_NUMBER@gcp-sa-dep. \
    --role=roles/serviceusage.serviceUsageConsumer
gcloud projects add-iam-policy-binding MODEL_ARMOR_PROJECT_ID \
    --member=serviceAccount:service-GATEWAY_PROJECT_NUMBER@gcp-sa-dep. \
    --role=roles/modelarmor.user
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫GATEWAY_PROJECT_ID: מזהה הפרויקט שבו יצרתם את שער הגישה.
- ‫GATEWAY_PROJECT_NUMBER: מספר הפרויקט שבו יצרתם את שער הנתונים.
- ‫MODEL_ARMOR_PROJECT_ID: מזהה הפרויקט שמכיל את תבנית הגנה מוגברת על המודל.
אם אתם משתמשים בשער עבור Agent Runtime, גם לסוכן של Reasoning Engine Service נדרשות ההרשאות האלה, כפי שמתואר במאמר ניתוב תנועה של Agent Runtime דרך Agent Gateway.

gcloud

יוצרים את התבניות של Model Armor שנדרשות.
כשמשתמשים ב-Model Armor, צריך להעניק לחשבון השירות של Agent Gateway את ההרשאות שנדרשות כדי להשתמש בתבניות של Model Armor. חשבון השירות הוא בפורמט: service-PROJECT_NUMBER@gcp-sa-dep., כאשר PROJECT_NUMBER הוא מספר הפרויקט שבו יצרתם את השער.

חובה להשלים את השלב הזה גם אם השער והתבניות נמצאים באותו פרויקט. נותנים את התפקידים הבאים:
- התפקידים roles/modelarmor.calloutUser ו-roles/serviceusage.serviceUsageConsumer בפרויקט שמכיל את השער.
- תפקיד roles/modelarmor.user בפרויקט שמכיל את תבנית הגנה מוגברת על המודל.
```
gcloud projects add-iam-policy-binding GATEWAY_PROJECT_ID \
    --member=serviceAccount:service-GATEWAY_PROJECT_NUMBER@gcp-sa-dep. \
    --role=roles/modelarmor.calloutUser
gcloud projects add-iam-policy-binding GATEWAY_PROJECT_ID \
    --member=serviceAccount:service-GATEWAY_PROJECT_NUMBER@gcp-sa-dep. \
    --role=roles/serviceusage.serviceUsageConsumer
gcloud projects add-iam-policy-binding MODEL_ARMOR_PROJECT_ID \
    --member=serviceAccount:service-GATEWAY_PROJECT_NUMBER@gcp-sa-dep. \
    --role=roles/modelarmor.user
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫GATEWAY_PROJECT_ID: מזהה הפרויקט שבו יצרתם את שער הגישה.
- ‫GATEWAY_PROJECT_NUMBER: מספר הפרויקט שבו יצרתם את שער הנתונים.
- ‫MODEL_ARMOR_PROJECT_ID: מזהה הפרויקט שמכיל את תבנית הגנה מוגברת על המודל.

מגדירים את תוסף ההרשאה כך שיצביע על Model Armor.

מגדירים את התוסף בקובץ YAML. משתמשים בערכים לדוגמה שצוינו.

cat >ma-content-authz-extension.yaml <<EOF
name: my-ma-content-authz-ext
service: modelarmor.LOCATION.rep.googleapis.com
metadata:
  model_armor_settings: '[
    {
    "response_template_id": "projects/MODEL_ARMOR_PROJECT_ID/locations/LOCATION/templates/TEMPLATE_ID",
    "request_template_id": "projects/MODEL_ARMOR_PROJECT_ID/locations/LOCATION/templates/TEMPLATE_ID"
    }
  ]'
failOpen: true
timeout: 1s
EOF

מייבאים את תוסף ההרשאה. משתמשים בgcloud service-extensions authz-extensions import עם ערכי הדוגמה הבאים.
```
gcloud service-extensions authz-extensions import my-ma-content-authz-ext \
   --source=ma-content-authz-extension.yaml \
   --location=LOCATION
```

הגדרת מדיניות הרשאות באמצעות התוסף.
1. מגדירים מדיניות הרשאות שמשייכת את התוסף my-ma-content-authz-ext ל-Agent Gateway.
  Agent-to-Anywhere
  cat >ma-content-authz-policy.yaml <<EOF name: my-ma-content-authz-policy target: resources: - "projects/PROJECT_ID/locations/LOCATION/gateways/AGENT_GATEWAY_NAME" policyProfile: CONTENT_AUTHZ action: CUSTOM customProvider: authzExtension: resources: - "projects/PROJECT_ID/locations/LOCATION/authzExtensions/my-ma-content-authz-ext" httpRules: - to: operations: [ { "paths": [ { "prefix": "/" } ] } ] when: > request.headers['content-type'] == 'application/json' || request.headers['content-type'].startsWith('text/') EOF
  
  שימו לב לנקודות הבאות:
  
  הערך של policyProfile מוגדר כ-CONTENT_AUTHZ. המשמעות היא שספק המדיניות המותאמת אישית מעבד את התנועה של הבקשות והתגובות, כולל גוף הבקשה.
  
  הפרמטר httpRules מדגים איך להשתמש במאפייני CEL כדי ליצור תנאים שתואמים לתנועה הספציפית שרוצים להעביר ל-Model Armor לצורך הערכה. בדוגמה הזו, הכללים תואמים לכל התנועה עם סוגי התוכן application/json או text/. מומלץ להשתמש בכללים כאלה כדי להגביל את ההערכה של Model Armor לתנועה רלוונטית. כך תוכלו להפנות תנועה של LLM API, ‏ MCP ו-A2A נתמכים אל Model Armor, ולמעט תנועה פנימית כמו קריאות gRPC של סוכנים.
  Client-to-Agent
  cat >ma-content-authz-policy.yaml <<EOF name: my-ma-content-authz-policy target: resources: - "projects/PROJECT_ID/locations/LOCATION/gateways/AGENT_GATEWAY_NAME" policyProfile: CONTENT_AUTHZ action: CUSTOM customProvider: authzExtension: resources: - "projects/PROJECT_ID/locations/LOCATION/authzExtensions/my-ma-content-authz-ext" EOF
  
  הערך של policyProfile מוגדר כ-CONTENT_AUTHZ. המשמעות היא שספק המדיניות המותאמת אישית מעבד את התנועה של הבקשות והתגובות, כולל גוף הבקשה.
2. מייבאים את מדיניות ההרשאות לפרויקט. משתמשים בgcloud network-security authz-policies importפקודה עם הערכים לדוגמה הבאים.
```
gcloud network-security authz-policies import my-ma-content-authz-policy \
  --source=ma-content-authz-policy.yaml \
  --location=LOCATION
```

העברת הרשאה לתוספי הרשאה בהתאמה אישית

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

כשמשתמשים ביעדים מסוג FQDN, התוסף משתמש בפרוטוקול HTTP2 עם הצפנת TLS כדי לתקשר עם נקודות קצה ביציאה 443. עם זאת, התוסף לא מאמת את אישור השרת. לכן, כדי לשפר את האבטחה, צריך לוודא שנקודות הקצה שנפתרו נמצאות ברשת ה-VPC. בנוסף, צריך לוודא שהגדרתם DNS peering בין פרויקט Agent Gateway לבין רשת ה-VPC.

כדי להגדיר תוסף הרשאה עם מדיניות הרשאה עבור FQDN ספציפי, כמו mycustomauthz.internal.net, צריך לציין אותו כערך של service בקובץ ה-YAML של התוסף, כמו בדוגמה הבאה. בדוגמה הזו מניחים שפרסתם שרת ברשת ה-VPC שלכם שמטמיע את פרוטוקול ext_authz.
```
cat >custom-authz-extension.yaml <<EOF
name: my-custom-authz-ext
service: mycustomauthz.internal.net
failOpen: true
timeout: 1s
wireFormat: EXT_AUTHZ_GRPC
EOF
```

יוצרים את תוסף ההרשאה כדי להפנות לשירות המותאם אישית.

gcloud beta service-extensions authz-extensions import custom-authz-extension \
  --source=custom-authz-extension.yaml \
  --location=LOCATION

אחרי שיוצרים את התוסף, מגדירים CUSTOM מדיניות הרשאות שמעבירה את ההחלטות לתוסף ההרשאות.

  cat >authz-policy.yaml <<EOF
  name: authz-with-extension
  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/custom-authz-extension
  EOF

יוצרים את מדיניות ההרשאות.

gcloud network-security authz-policies import authz-policy-with-extension \
--source=authz-policy.yaml \
--location=LOCATION

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

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

כדי להבטיח אבטחה מקיפה, מומלץ להגדיר מדיניות הרשאה מותאמת אישית עם REQUEST_AUTHZ פרופיל מדיניות, ועוד מדיניות הרשאה מותאמת אישית עם CONTENT_AUTHZ פרופיל מדיניות.

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

מגדירים תוסף הרשאה של REQUEST_AUTHZ שמקצה הרשאות ל-IAP ומדיניות הרשאות שמפנה לתוסף.

מגדירים את תוסף ההרשאה. השדה iapPolicyVersion בקטע metadata הוא חובה וצריך להגדיר בו את הערך "V1".

cat >iap-extension.yaml <<EOF
name: iap-extension
service: iap.googleapis.com
failOpen: true
timeout: 1s
metadata:
  iapPolicyVersion: "V1"
EOF

יוצרים את תוסף ההרשאה.

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

מחליפים את LOCATION באזור של התוסף.

הגדרת מדיניות ההרשאות של REQUEST_AUTHZ שמעבירה הרשאות לתוסף.

cat >authz-policy-request-authz.yaml <<EOF
name: authz-iap
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/iap-extension"
EOF

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

‫PROJECT_ID: מזהה הפרויקט.
‫LOCATION: המיקום של המשאבים.
‫AGENT_GATEWAY_NAME: השם של Agent Gateway.

יוצרים את מדיניות ההרשאות.

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

מגדירים תוסף הרשאה של CONTENT_AUTHZ שמעביר את ההרשאה ל-הגנה מוגברת על המודל, ומדיניות הרשאה שמפנה לתוסף.

מגדירים את התוסף.

cat >ma-extension-file.yaml <<EOF
name: ma-extension
service: modelarmor.LOCATION.rep.googleapis.com
metadata:
  model_armor_settings: '[
    {
    "response_template_id": "projects/MODEL_ARMOR_PROJECT_ID/locations/LOCATION/templates/RESPONSE_TEMPLATE_ID",
    "request_template_id": "projects/MODEL_ARMOR_PROJECT_ID/locations/LOCATION/templates/REQUEST_TEMPLATE_ID"
    }
  ]'
failOpen: true
timeout: 1s
EOF

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

‫LOCATION: האזור שבו נמצאות התבניות של Model Armor.
‫MODEL_ARMOR_PROJECT_ID: מזהה הפרויקט שמכיל את תבניות Model Armor.
‫RESPONSE_TEMPLATE_ID: המזהה של תבנית התגובה.
‫REQUEST_TEMPLATE_ID: המזהה של תבנית הבקשה.

יוצרים את תוסף ההרשאה.

gcloud service-extensions authz-extensions import ma-extension \
--source=ma-extension-file.yaml \
--location=LOCATION

מגדירים את מדיניות ההרשאות של CONTENT_AUTHZ שמקצה הרשאות לתוסף.

cat >authz-policy-content-authz.yaml <<EOF
name: authz-ma
target:
  resources:
  - "projects/PROJECT_ID/locations/LOCATION/agentGateways/AGENT_GATEWAY_NAME"
policyProfile: CONTENT_AUTHZ
action: CUSTOM
customProvider:
  authzExtension:
    resources:
    - "projects/PROJECT_ID/locations/LOCATION/authzExtensions/ma-extension"
EOF

יוצרים את מדיניות ההרשאות.

gcloud network-security authz-policies import ma-authz-policy \
--source=authz-policy-content-authz.yaml \
--location=LOCATION

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

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

אפשר להגדיר תוסף הרשאה כדי להעביר את ההחלטות לגבי הגבלת כוונות ומגבלות בשפה טבעית למנוע המדיניות של Semantic governance (semanticGovernancePolicyEngine).

כדי ללמוד איך להקצות את מנוע המדיניות וליצור את CONTENT_AUTHZ מדיניות ההרשאות הנדרשת ואת הקישור של תוסף ההרשאות בשער, אפשר לעיין במאמר חיבור מנוע המדיניות ל-Agent Gateway.

הרשאה שמבוססת על מאפייני פרוטוקול MCP

Agent Gateway מנתח את מטען ה-payload של פרוטוקול MCP בבקשה ומאפשר להשתמש במאפיינים שחולצו במדיניות ההרשאות.

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

מגדירים את מדיניות ההרשאות.

ALLOW דוגמה למדיניות

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

כשכותבים מדיניות ALLOW, חשוב לציין baseProtocolMethodsOption: MATCH_BASE_PROTOCOL_METHODS כדי שפקודות RPC של MCP שלא קשורות לגישה, כמו initialize,‏ logging,‏ completion,‏ notifications ו-ping, ימשיכו לפעול. אם לא תעשו את זה, לא תוכלו ליצור סשן MCP.

cat >authz-policy-restrict-tools.yaml <<EOF
name: my-authz-policy-restrict-tools
target:
  resources:
  - "projects/PROJECT_ID/locations/LOCATION/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
EOF

DENY דוגמה למדיניות

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

cat >authz-policy-disallow-prompts.yaml <<EOF
name: my-authz-policy-disallow-prompts
target:
  resources:
  - "projects/PROJECT_ID/locations/LOCATION/agentGateways/AGENT_GATEWAY_NAME"
policyProfile: REQUEST_AUTHZ
httpRules:
- to:
    operations:
    - mcp:
        methods:
        - name: "prompts"
action: DENY
EOF

יוצרים את מדיניות ההרשאות.
```
gcloud network-security authz-policies import AUTHZ_POLICY_NAME \
--source=AUTH_POLICY_YAML_FILE_PATH \
--location=LOCATION
```
מחליפים את מה שכתוב בשדות הבאים:
- AUTHZ_POLICY_NAME: השם של מדיניות ההרשאות.
- ‫AUTH_POLICY_YAML_FILE_PATH: הנתיב לקובץ ה-YAML של מדיניות ההרשאות.
- ‫LOCATION: המיקום של המשאבים.

מגבלות

המגבלות הבאות חלות כשמשתמשים במדיניות הרשאות:

בשערים של סוכנים לכל מקום (יציאה), אפשר להגדיר עד ארבע מדיניות הרשאות מותאמת אישית לכל שער, ללא קשר לפרופיל המדיניות.
בשערי כניסה (ingress) של לקוחות לסוכנים, אפשר להגדיר עד CONTENT_AUTHZ מדיניות. מומלץ מאוד להשתמש ב-Model Armor כדי להגן מפני מתקפות של החדרת הנחיות. עם זאת, אם רוצים להשתמש בתוסף של מדיניות סמנטית לניהול גישה, צריך לוודא ש-Model Armor לא מוגדר בשער. אין תמיכה בסוגים אחרים של תוספי שירות ל-ingress.
אם אתם משתמשים בתוספים מותאמים אישית להרשאות עם פרופיל CONTENT_AUTHZ, הם צריכים לתמוך בפרוטוקול ext_proc ובמצב FULL_DUPLEX_STREAMED לאירועים של body.
אם מגדירים כמה כללי מדיניות מותאמים אישית להרשאה שמשתמשים באותו פרופיל, סדר הביצוע שלהם לא מובטח.

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

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

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

Codelab

האצלת הרשאות באמצעות Service Extensions

תוספים לאישור

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

הגדרת מדיניות הרשאות באמצעות תוספים

העברת הרשאה ל-IAP

העברת הרשאות ל-Model Armor

המסוף

gcloud

Agent-to-Anywhere

Client-to-Agent

העברת הרשאה לתוספי הרשאה בהתאמה אישית

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

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

הרשאה שמבוססת על מאפייני פרוטוקול MCP

מגבלות

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

Codelab: Govern agentic workloads with Agent Platform

מעקב אחרי Agent Gateway

פתרון בעיות ב-Agent Gateway

האצלת הרשאות באמצעות Service Extensions קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.

תוספים לאישור

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

הגדרת מדיניות הרשאות באמצעות תוספים

העברת הרשאה ל-IAP

העברת הרשאות ל-Model Armor

המסוף

gcloud

Agent-to-Anywhere

Client-to-Agent

העברת הרשאה לתוספי הרשאה בהתאמה אישית

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

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

הרשאה שמבוססת על מאפייני פרוטוקול MCP

מגבלות

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

Codelab: Govern agentic workloads with Agent Platform

מעקב אחרי Agent Gateway

פתרון בעיות ב-Agent Gateway

האצלת הרשאות באמצעות Service Extensions