הגדרת פרויקט לצוות

בדף הזה מופיעות דוגמאות להגדרת פרויקט לצוות שעובד עם Gemini Enterprise Agent Platform. בדף הזה מניחים שאתם כבר מכירים את המושגים של ניהול הזהויות והרשאות הגישה (IAM), כמו מדיניות, תפקידים, הרשאות וישויות מורשות, כפי שמתואר במאמרים בקרת גישה ל-Agent Platform באמצעות IAM ומושגים שקשורים לניהול הרשאות גישה.

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

סקירה כללית

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

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

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

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

פרויקט יחיד עם גישה משותפת לנתונים ולמשאבים של Agent Platform

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

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

מדיניות ההרשאה של הפרויקט ב-IAM יכולה להיראות כך:

‫
{
  "version": 1,
  "etag": "BwWKmjvelug=",
  "bindings": [
    {
      "role": "roles/aiplatform.user",
      "members": [
        "user:USER1_EMAIL_ADDRESS",
        "user:USER2_EMAIL_ADDRESS"
      ]
    },
    {
      "role": "roles/storage.admin",
      "members": [
        "user:USER1_EMAIL_ADDRESS",
        "user:USER2_EMAIL_ADDRESS"
      ]
    },
    {
      "role": "roles/aiplatform.serviceAgent",
      "members": [
        "user:service-PROJECT_NUMBER@gcp-sa-aiplatform-cc.iam.gserviceaccount.com"
      ]
    }
  ]
}

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

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

הפרדה בין נתונים למשאבים של Agent Platform

בדוגמה הזו, הנתונים של הצוות נמצאים בפרויקט נפרד מהמשאבים של Agent Platform.

אפשר להגדיר פרויקט בדרך הזו אם:

  • קשה מדי להעביר את הנתונים של הצוות לאותו פרויקט של משאבי Agent Platform.

  • הנתונים של הצוות דורשים שליטה ספציפית במי שיכול לגשת אליהם.

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

לדוגמה, אתם יכולים לתת לסוכני השירות של Agent Platform גישה לקטגוריה של Cloud Storage באמצעות מדיניות הרשאות שדומה לזו:

{
  "version": 1,
  "etag": "BwWKmjvelug=",
  "bindings": [
    {
      "role": "roles/storage.objectViewer",
      "members": [
        "user:service-PROJECT_NUMBER@gcp-sa-aiplatform-cc.iam.gserviceaccount.com",
        "user:service-PROJECT_NUMBER@gcp-sa-aiplatform.iam.gserviceaccount.com"
      ]
    }
  ]
}

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

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

{
  "version": 1,
  "etag": "BwWKmjvelug=",
  "bindings": [
    {
      "role": "roles/bigquery.user",
      "members": [
        "user:SERVICE_ACCOUNT_NAME@PROJECT_NUMBER.iam.gserviceaccount.com"
      ]
    }
  ]
}

במאמר ניהול הגישה לחשבונות שירות מוסבר איך מגדירים בקרת גישה לחשבונות שירות.

בפרויקט עם המשאבים של Agent Platform, אדמינים יכולים לתת למשתמשים גישה לנתונים על ידי הקצאת התפקיד 'משתמש בחשבון שירות' (roles/iam.serviceAccountUser) בחשבונות השירות שצוינו.

בידוד קוד שפחות מהימן בפרויקטים נפרדים נוספים

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

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