עריכה של מדיניות לקביעת גבול הגישה לחשבונות משתמשים (PAB)

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

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

תפקידים שנדרשים לעריכת מדיניות לקביעת גבול הגישה לחשבונות משתמשים (PAB)

כדי לקבל את ההרשאה שנדרשת לעריכת כללי מדיניות של גבולות גישה לחשבונות משתמשים, צריך לבקש מהאדמין להקצות לכם את תפקיד ה-IAM‏ Principal Access Boundary Admin (roles/iam.principalAccessBoundaryAdmin) בארגון. כדי לקרוא הסבר על מתן תפקידים, ראו איך מנהלים את הגישה ברמת הפרויקט, התיקייה והארגון.

התפקיד המוגדר מראש הזה כולל את ההרשאה iam.principalaccessboundarypolicies.update, שנדרשת כדי לערוך מדיניות לקביעת גבול הגישה לחשבונות משתמשים (PAB).

יכול להיות שתוכלו לקבל את ההרשאה הזו גם בתפקידים בהתאמה אישית או בתפקידים אחרים שמוגדרים מראש.

תפקידים שנדרשים לעריכת קישורים של מדיניות לקביעת גבול הגישה לחשבונות משתמשים (PAB)

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

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

  • בקרת גישה לישויות מורשות (PAB) משתמש (roles/iam.principalAccessBoundaryUser) בארגון שלכם
  • עריכת קשרי מדיניות (policy bindings) של מדיניות גבולות גישה של חשבונות ראשיים שקשורים למאגרי זהויות של כוח עבודה: אדמין של מאגר זהויות של כוח עבודה ב-IAM (roles/iam.workforcePoolAdmin) במאגר הזהויות של כוח העבודה
  • עריכת קשרי מדיניות (policy bindings) למדיניות של גבולות גישה של חשבונות ראשיים שקשורים למאגרי זהויות של כוח עבודה: אדמין של מאגר זהויות של כוח עבודה ב-IAM (roles/iam.workloadIdentityPoolAdmin) בפרויקט שבו נמצא מאגר הזהויות של כוח העבודה
  • קבלת הסטטוס של פעולה ממושכת לעריכת קישור שמפנה למאגר זהויות של עומסי עבודה: צפייה בפעולות ב-IAM (roles/iam.operationViewer) בפרויקט שבבעלותו מאגר הזהויות של עומסי העבודה.
  • עריכת קשרי מדיניות למדיניות של גבולות גישה של חשבונות משתמשים שקשורים לדומיין ב-Google Workspace: אדמין IAM של מאגר Workspace (roles/iam.workspacePoolAdmin) בארגון
  • עריכת מדיניות של גבולות גישה של ישויות (Principal Access Boundary) שמקושרת לקבוצת הישויות של פרויקט: אדמין IAM של פרויקט (roles/resourcemanager.projectIamAdmin) בפרויקט
  • קבלת הסטטוס של פעולה ממושכת לעריכת קשירה שמפנה אל קבוצת חשבונות ראשיים בפרויקט: IAM Operation Viewer (roles/iam.operationViewer) בפרויקט
  • עריכת קישורי מדיניות למדיניות של הגבלת גישה לישויות מורשות שקשורה לקבוצת הישויות המורשות של תיקייה: אדמין IAM של תיקייה (roles/resourcemanager.folderIamAdmin) בתיקייה
  • עריכת מדיניות של קשרי מדיניות לקביעת הגישה לישויות מורשות (PAB) שקשורים לקבוצת הישויות המורשות של הארגון: אדמין ארגוני (roles/resourcemanager.organizationAdmin) בארגון

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

התפקידים המוגדרים מראש האלה מכילים את ההרשאות שנדרשות לעריכת קישורי מדיניות עבור מדיניות לקביעת גבול הגישה לחשבונות משתמשים (PAB). כדי לראות בדיוק אילו הרשאות נדרשות, אפשר להרחיב את הקטע ההרשאות הנדרשות:

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

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

  • iam.principalaccessboundarypolicies.bind בארגון
  • עריכת קשרי מדיניות למדיניות של גבולות גישה של ישויות (Principal) שקשורים למאגרי זהויות של כוח עבודה: iam.workforcePools.updatePolicyBinding במאגר הזהויות של כוח העבודה
  • עריכת קשרי מדיניות של מדיניות גבולות גישה של ישויות שקשורים למאגרי זהויות של כוח עבודה: iam.workloadIdentityPools.updatePolicyBinding בפרויקט שבבעלותו מאגר הזהויות של כוח העבודה
  • קבלת הסטטוס של פעולה ארוכת טווח לעריכת קישור שמפנה למאגר זהויות של כוח עבודה: iam.operations.get בפרויקט שבבעלותו מאגר הזהויות של כוח העבודה
  • עריכת קשרי מדיניות למדיניות של גבולות גישה של גורם מרכזי שקשורים לדומיין של Google Workspace: iam.workspacePools.updatePolicyBinding בארגון
  • עריכת קישורי מדיניות של מדיניות לקביעת הגישה לישויות מורשות (PAB) שקשורה לקבוצת החשבונות הראשיים של הפרויקט: resourcemanager.projects.updatePolicyBinding בפרויקט
  • כדי לקבל את הסטטוס של פעולה ממושכת לעריכת קישור שמפנה לקבוצת חשבונות משתמש בפרויקט: iam.operations.get בפרויקט
  • עריכת קישורי מדיניות למדיניות לקביעת הגישה לישויות מורשות שקשורה לקבוצת החשבונות הראשיים של התיקייה: resourcemanager.folders.updatePolicyBinding בתיקייה
  • עריכת קשרי מדיניות למדיניות לקביעת הגישה לישויות מורשות שקשורה לקבוצת הישויות המורשות של הארגון: resourcemanager.organizations.updatePolicyBinding בארגון

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

עריכה של מדיניות קיימת לקביעת גבול הגישה לחשבונות משתמשים (PAB)

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

אפשר לערוך מדיניות של גבולות גישה של משתמשים באמצעות מסוף Cloud de Confiance ,‏ ה-CLI של gcloud או IAM API בארכיטקטורת REST.

המסוף

  1. נכנסים לדף Principal Access Boundary policies במסוף Cloud de Confiance .

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

  2. בוחרים את הארגון שבבעלותו מדיניות הגבלת הגישה של החשבון הראשי שרוצים לערוך.

  3. לוחצים על מזהה המדיניות של המדיניות לקביעת הגישה לישויות מורשות שרוצים לערוך.

  4. לוחצים על עריכת המדיניות.

  5. כדי לערוך את הכללים של המדיניות:

    1. לוחצים על הכלל שרוצים לערוך.
    2. עורכים את התיאור של הכלל או את המשאבים שנכללים בו.
    3. לוחצים על סיום.
  6. כדי למחוק כלל מהמדיניות, לוחצים על מחיקה בשורה של הכלל.

  7. כדי לערוך את השם המוצג של המדיניות, עורכים את השדה שם מוצג.

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

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

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

  10. לוחצים על Save.

gcloud

הפקודה gcloud iam principal-access-boundary-policies update מעדכנת מדיניות קיימת לקביעת גבול הגישה לחשבונות משתמשים (PAB).

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

  • PAB_POLICY_ID: המזהה של מדיניות הגבלת הגישה של החשבון הראשי שרוצים לעדכן. לדוגמה: example-policy.
  • ORG_ID: המזהה של הארגון שבבעלותו מדיניות גבולות הגישה של הגורם המורשה. מזהי ארגונים הם מספרים, למשל 123456789012.
  • FIELD_TO_UPDATE=UPDATED_VALUE: השדות שרוצים לעדכן והערך המעודכן המתאים.

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

    • --display-name=DISPLAY_NAME: מחליפים את השם המוצג של המדיניות ב-DISPLAY_NAME.
    • --details-enforcement-version=ENFORCEMENT_VERSION: עדכון גרסת האכיפה של המדיניות ל-ENFORCEMENT_VERSION.
    • --details-rules=RULES_FILE.json: מחליפים את הכללים במדיניות של גבול הגישה לישויות מורשות בכללים שב-RULES_FILE.json. במאמר יצירת כללי מדיניות של גבולות גישה לחשבונות ראשיים מוסבר איך לעצב את קובץ הכללים.

      אם משתמשים בדגל הזה, אי אפשר להשתמש בדגל --add-details-rules.

    • --add-details-rules=RULES_FILE: הוספת הכללים ב-RULES_FILE.json לכללים הקיימים במדיניות. במאמר יצירת כללי מדיניות של גבולות גישה לחשבונות ראשיים מוסבר איך לעצב את קובץ הכללים.

      אם משתמשים בדגל הזה, אי אפשר להשתמש בדגל --details-rules.

    • --remove-details-rules=RULES_FILE: מסירים את הכללים ב-RULES_FILE.json מהכללים הקיימים במדיניות. במאמר יצירת כללי מדיניות של גבולות גישה לחשבונות ראשיים מוסבר איך לעצב את קובץ הכללים. רק כללים שתואמים בדיוק לאחד מהכללים ב-RULES_FILE.json יוסרו.

      אם משתמשים בדגל הזה, אי אפשר להשתמש בדגל --clear-rule-details.

    • --clear-details-rules: מחיקת כל הכללים מהמדיניות לקביעת גבול הגישה לחשבונות משתמשים (PAB).

      אם משתמשים בדגל הזה, אי אפשר להשתמש בדגל --remove-rule-details.

    רשימה מלאה של הדגלים שאפשר להשתמש בהם כדי לעדכן מדיניות של גבולות גישה של ישויות מופיעה בדף העזרה של הפקודה gcloud iam principal-access-boundary-policies update.

  • FORMAT: הפורמט של התגובה. אפשר להשתמש ב-json או ב-yaml.

מריצים את הפקודה הבאה:

‫Linux,‏ macOS או Cloud Shell

gcloud iam principal-access-boundary-policies update PAB_POLICY_ID \
    --organization=ORG_ID --location=global \
    --FIELD_TO_UPDATE=UPDATED_VALUE \
    --format=FORMAT

‏Windows (PowerShell)

gcloud iam principal-access-boundary-policies update PAB_POLICY_ID `
    --organization=ORG_ID --location=global `
    --FIELD_TO_UPDATE=UPDATED_VALUE `
    --format=FORMAT

Windows‏ (cmd.exe)

gcloud iam principal-access-boundary-policies update PAB_POLICY_ID ^
    --organization=ORG_ID --location=global ^
    --FIELD_TO_UPDATE=UPDATED_VALUE ^
    --format=FORMAT

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

Request issued for: [example-policy]
Waiting for operation [organizations/123456789012/locations/global/operations/operation-1715374208720-6181fae5e2034-2d8a712b-5c92e5b9] to complete...done.
Updated principalAccessBoundaryPolicy [example-policy].
{
  "name": "organizations/123456789012/locations/global/principalAccessBoundaryPolicies/example-policy",
  "uid": "puid_13364150419245236225",
  "etag": "W/\"Gh/PcTdJD/AWHUhPW45kdw==\"",
  "displayName": "Updated display name",
  "createTime": "2024-05-07T00:05:48.295209Z",
  "updateTime": "2024-05-10T20:50:09.200421Z",
  "details": [
    "rules": {
      [
        "description": "Make principals eligible to access example.com"
        "resources": {
          "//cloudresourcemanager.googleapis.com/organizations/123456789012"
        },
        "effect": ALLOW
      ]
    },
    "enforcementVersion": "1"
  ]
}

REST

השיטה principalAccessBoundaryPolicies.patch מעדכנת מדיניות קיימת לקביעת גבול הגישה לחשבונות משתמשים (PAB).

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

  • ORG_ID: המזהה של הארגון שבבעלותו מדיניות גבולות הגישה של הגורם המורשה. מזהי ארגונים הם מספרים, למשל 123456789012.
  • PAB_POLICY_ID: המזהה של מדיניות הגבלת הגישה של החשבון הראשי שרוצים לעדכן. לדוגמה: example-policy.
  • FIELDS_TO_UPDATE: רשימה מופרדת בפסיקים של השדות שרוצים לעדכן. אם לא מציינים את השדות לעדכון, IAM מחליף את המדיניות הקיימת בתוכן של גוף הבקשה.

    הערכים הקבילים הם displayName, ‏ details,‏ details.rules, ‏ details.rules.description,‏ details.rules.resources, ‏ details.rules.effect ו-details.enforcementVersion.

  • DISPLAY_NAME: אופציונלי. תיאור של המדיניות לקביעת גבול הגישה לחשבונות משתמשים (PAB) שכתוב בצורה שקריאה לאנשים – לדוגמה, Example policy. השם המוצג יכול לכלול עד 63 תווים.
  • PAB_RULES: רשימה של כללים להגבלת הגישה לחשבונות משתמשים, שמגדירים את המשאבים שחשבונות המשתמשים המושפעים יכולים לגשת אליהם. מדיניות לקביעת גבול הגישה לחשבונות משתמשים (PAB) יכולה לכלול עד 500 כללים. כל כלל הוא בפורמט הבא:

    {
      "description": "DESCRIPTION",
      "resources": [
        RESOURCES
      ],
      "effect": "ALLOW"
    }

    מחליפים את הערכים הבאים:

    • DESCRIPTION: אופציונלי. תיאור של כלל המדיניות לקביעת גבול הגישה לחשבונות משתמשים (PAB). התיאור יכול להכיל עד 256 תווים.
    • RESOURCES: רשימה של משאבים ב-מנהל המשאבים (פרויקטים, תיקיות וארגונים) שרוצים להגדיר לישויות מורשות אפשרות גישה אליהם. כל חשבון משתמש שחל עליו הכלל הזה יכול לגשת למשאבים האלה.

      כל מדיניות של גבולות גישה לחשבונות משתמשים יכולה להפנות למקסימום 500 משאבים בכל הכללים במדיניות.

  • ENFORCEMENT_VERSION: הגרסה של מדיניות הגישה לישויות מורשות ש-IAM משתמש בה כדי לאכוף את המדיניות. גרסת האכיפה קובעת אילו הרשאות נאכפות על ידי IAM במדיניות לקביעת גבול הגישה לחשבונות משתמשים (PAB).

    הערכים הקבילים הם 1,‏ 2,‏ 3,‏ 4 ו-latest .

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

ה-method של ה-HTTP וכתובת ה-URL:

PATCH https://iam.googleapis.com/v3/organizations/ORG_ID/locations/global/principalAccessBoundaryPolicies/PAB_POLICY_ID?updateMask=FIELDS_TO_UPDATE

תוכן בקשת JSON:

{
  "displayName": DISPLAY_NAME,
  "details": {
    "rules": [
      PAB_RULES
    ],
    "enforcementVersion": "ENFORCEMENT_VERSION",
  }
}

כדי לשלוח את הבקשה צריך להרחיב אחת מהאפשרויות הבאות:

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

{
  "name": "organizations/123456789012/locations/global/operations/operation-1715626721931-6185a7953ef76-76f80ee4-19cd1bf7",
  "metadata": {
    "@type": "type.googleapis.com/google.iam.v3.OperationMetadata",
    "createTime": "2024-05-13T18:58:43.721277235Z",
    "target": "organizations/123456789012/locations/global/principalAccessBoundaryPolicies/example-policy",
    "verb": "update",
    "requestedCancellation": false,
    "apiVersion": "v3"
  },
  "done": false
}

שינוי הישויות המורשות שעליהן חלה המדיניות לקביעת גבול הגישה לחשבונות משתמשים

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

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

עריכה של קישורי מדיניות קיימים למדיניות לקביעת גבול הגישה לחשבונות משתמשים (PAB)

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

אפשר לערוך את הקישור למדיניות באמצעות Cloud de Confiance המסוף, ה-CLI של gcloud או API בארכיטקטורת REST של IAM.

המסוף

  1. נכנסים לדף Principal Access Boundary policies במסוף Cloud de Confiance .

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

  2. בוחרים את הארגון שבבעלותו מדיניות הגבלת הגישה של החשבון הראשי שרוצים לערוך.

  3. לוחצים על מזהה המדיניות של המדיניות לקביעת הגישה לישויות מורשות שרוצים לערוך את ההרשאות שלה.

  4. לוחצים על הכרטיסייה Bindings (קישורים).

  5. מאתרים את המזהה של הקישור שרוצים לערוך. בשורה של הקישור, לוחצים על פעולות ואז על עריכת הקישור.

  6. כדי לעדכן את השם המוצג של הקישור, עורכים את השדה שם לתצוגה.

  7. כדי להוסיף תנאי לקישור:

    1. לוחצים על הוספת תנאי.
    2. בשדה כותרת, מזינים סיכום קצר של מטרת התנאי.
    3. אופציונלי: בשדה Description, מזינים תיאור ארוך יותר של התנאי.
    4. בשדה Expression (ביטוי), מזינים ביטוי תנאי שמשתמש בתחביר של Common Expression Language ‏(CEL). הביטוי צריך להתייחס למאפיינים principal.type או principal.subject. אין תמיכה במאפיינים אחרים.
    5. לוחצים על Save.
  8. כדי לעדכן תנאי קיים:

    1. לצד שם התנאי, לוחצים על עריכת התנאי.
    2. מעדכנים את הכותרת, התיאור או הביטוי של התנאי.
    3. לוחצים על Save.
  9. אופציונלי: כדי לבדוק את השינויים שביצעתם בקשירת המדיניות של גבולות הגישה של חשבון המשתמש באמצעות סימולטור המדיניות, לוחצים על בדיקת שינויים. בודקים את תוצאות הסימולציה ומעדכנים את שיוך המדיניות אם יש צורך.

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

  10. כדי לשמור את השינויים, לוחצים על שמירה.

gcloud

הפקודה gcloud iam policy-bindings update מעדכנת קישור מדיניות קיים.

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

  • BINDING_ID: המזהה של מדיניות ה-IAM שרוצים לעדכן. לדוגמה: example-binding.
  • RESOURCE_TYPE: סוג המשאב במנהל המשאבים (פרויקט, תיקייה או ארגון) שה-policy binding הוא צאצא שלו. אפשר להשתמש בערך project,‏ folder או organization

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

  • RESOURCE_ID: המזהה של הפרויקט, התיקייה או הארגון שהקישור למדיניות הוא צאצא שלהם. מזהי פרויקטים הם מחרוזות אלפאנומריות, כמו my-project. מזהי תיקיות וארגונים מכילים רק ספרות, למשל 123456789012.
  • FIELD_TO_UPDATE=UPDATED_VALUE: השדות שרוצים לעדכן והערך המעודכן המתאים.

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

    • --display-name=DISPLAY_NAME: מחליפים את השם המוצג של הקישור ב-DISPLAY_NAME.
    • --condition-description=CONDITION_DESCRIPTION: אם לקישור יש תנאי, מחליפים את תיאור התנאי ב-CONDITION_DESCRIPTION. אחרת, מוסיפים תנאי חדש לקשירה עם התיאור שצוין. אם משתמשים בדגל הזה כדי לעדכן קשר שאין לו תנאי, צריך להגדיר גם את הדגל --condition-expression.
    • --condition-expression=CONDITION_EXPRESSION: אם לקישור יש תנאי, מחליפים את ביטוי התנאי ב-CONDITION_EXPRESSION. אחרת, מוסיפים תנאי חדש לקשירה עם הביטוי שצוין.
    • --condition-title=CONDITION_TITLE: אם לקישור יש תנאי, מחליפים את שם התנאי ב-CONDITION_TITLE. אחרת, מוסיפים תנאי חדש לקשירה עם השם שצוין. אם משתמשים בדגל הזה כדי לעדכן קשר שלא מוגדרת לו תנאי, צריך להגדיר גם את הדגל --condition-expression.

    רשימה מלאה של השדות שאפשר לעדכן מופיעה בדף העזרה של הפקודה gcloud iam policy-bindings update.

  • FORMAT: הפורמט של התגובה. אפשר להשתמש ב-json או ב-yaml.

מריצים את הפקודה הבאה:

‫Linux,‏ macOS או Cloud Shell

gcloud iam policy-bindings update BINDING_ID \
    --RESOURCE_TYPE=RESOURCE_ID --location=global \
    --FIELD_TO_UPDATE=UPDATED_VALUE \
    --format=FORMAT

‏Windows (PowerShell)

gcloud iam policy-bindings update BINDING_ID `
    --RESOURCE_TYPE=RESOURCE_ID --location=global `
    --FIELD_TO_UPDATE=UPDATED_VALUE `
    --format=FORMAT

Windows‏ (cmd.exe)

gcloud iam policy-bindings update BINDING_ID ^
    --RESOURCE_TYPE=RESOURCE_ID --location=global ^
    --FIELD_TO_UPDATE=UPDATED_VALUE ^
    --format=FORMAT

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

Update request issued for: [my-binding]
Waiting for operation [organizations/123456789012/locations/global/operations/operation-1715374545618-6181fc272c6f9-55ff07f4-97d0ac76] to complete...done.
Updated policyBinding [my-binding].
{
  "createTime": "2024-05-06T18:08:24.729843Z",
  "displayName": "Updated display name",
  "etag": "W/\"xkdnPfTxoxyVqOwhQSJbMg==\"",
  "name": "organizations/123456789012/locations/global/policyBindings/example-binding",
  "policy": "organizations/123456789012/locations/global/principalAccessBoundaryPolicies/example-pab-policy",
  "policyKind": "PRINCIPAL_ACCESS_BOUNDARY",
  "policyUid": "puid_9519202237377675265",
  "target": {
    "principalSet": "//cloudresourcemanager.googleapis.com/organizations/123456789012"
  },
  "uid": "buid_9904260005517852673", 
  "updateTime": "2024-05-06T18:11:16.798841Z"
}

REST

השיטה policyBindings.patch מעדכנת קישור מדיניות קיים.

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

  • RESOURCE_TYPE: סוג המשאב במנהל המשאבים (פרויקט, תיקייה או ארגון) שה-policy binding הוא צאצא שלו. אפשר להשתמש בערך projects,‏ folders או organizations

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

  • RESOURCE_ID: המזהה של הפרויקט, התיקייה או הארגון שהקישור למדיניות הוא צאצא שלהם. מזהי פרויקטים הם מחרוזות אלפאנומריות, כמו my-project. מזהי תיקיות וארגונים מכילים רק ספרות, למשל 123456789012.
  • BINDING_ID: המזהה של מדיניות ה-IAM שרוצים לעדכן. לדוגמה: example-binding.
  • FIELDS_TO_UPDATE: רשימה מופרדת בפסיקים של השדות שרוצים לעדכן. אם לא מציינים את השדות לעדכון, IAM מחליף את הקישור הקיים בתוכן של גוף הבקשה.

    הערכים הקבילים הם displayName,‏ condition,‏ condition.expression,‏ condition.title ו-condition.description.

  • DISPLAY_NAME: אופציונלי. תיאור קריא של הקישור – לדוגמה, Example binding. השם המוצג יכול לכלול עד 63 תווים.
  • CONDITION_DETAILS: אופציונלי. ביטוי תנאי שמציין אילו חשבונות משתמשים בקבוצת חשבונות המשתמשים המדיניות לקביעת גבול הגישה לחשבונות משתמשים (PAB) נאכפת לגביהם. מכיל את השדות הבאים:

    • expression: ביטוי תנאי שמשתמש בתחביר של Common Expression Language ‏ (CEL). הביטוי צריך להתייחס למאפיינים principal.type או principal.subject. אין תמיכה במאפיינים אחרים.

      הביטוי יכול להכיל עד 10 אופרטורים לוגיים (&&,‏ ||,‏ !) ואורכו יכול להיות עד 250 תווים.

    • title: אופציונלי. סיכום קצר של מטרת התנאי.
    • description: אופציונלי. תיאור ארוך יותר של התנאי.

ה-method של ה-HTTP וכתובת ה-URL:

POST https://iam.googleapis.com/v3/RESOURCE_TYPE/RESOURCE_ID/locations/global/policyBindings/BINDING_ID?updateMask=FIELDS_TO_UPDATE

תוכן בקשת JSON:

{
  "displayName": DISPLAY_NAME,
  "condition": {
    CONDITION_DETAILS
  }
}

כדי לשלוח את הבקשה צריך להרחיב אחת מהאפשרויות הבאות:

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

{
  "name": "organizations/123456789012/locations/global/operations/operation-1715373159010-6181f6fcccfa7-dcd0055c-00c22cad",
  "metadata": {
    "@type": "type.googleapis.com/google.iam.v3.OperationMetadata",
    "createTime": "2024-05-10T20:32:39.254910121Z",
    "target": "organizations/123456789012/locations/global/policyBindings/example-binding",
    "verb": "update",
    "requestedCancellation": false,
    "apiVersion": "v3"
  },
  "done": false
}

בדיקת הסטטוס של פעולה ממושכת

כשמשתמשים ב-API בארכיטקטורת REST או בספריות הלקוח, כל שיטה שמשנה מדיניות לקביעת גבול הגישה לחשבונות משתמשים (PAB) או קישור מחזירה פעולה ממושכת (LRO). הפעולה הממושכת עוקבת אחרי הסטטוס של הבקשה ומציינת אם השינוי במדיניות או בהרשאה הושלם.

REST

השיטה operations.get מחזירה את הסטטוס של פעולה ממושכת.

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

  • OPERATION_NAME: השם המלא של הפעולה. השם הזה מופיע בתגובה לבקשה המקורית.

    שם הפעולה הוא בפורמט הבא:

          RESOURCE_TYPE/RESOURCE_ID/locations/global/operations/OPERATION_ID
        

ה-method של ה-HTTP וכתובת ה-URL:

GET https://iam.googleapis.com/v3/OPERATION_NAME

כדי לשלוח את הבקשה צריך להרחיב אחת מהאפשרויות הבאות:

אתם אמורים לקבל תגובת JSON שדומה לזו:

{
  "name": "organizations/314340013352/locations/global/operations/operation-1732752311821-627edd607a3df-9a62cdea-2a7d9f07",
  "metadata": {
    "@type": "type.googleapis.com/google.iam.v3.OperationMetadata",
    "createTime": "2024-11-28T00:05:12.006289686Z",
    "endTime": "2024-11-28T00:05:12.192141801Z",
    "target": "organizations/314340013352/locations/global/principalAccessBoundaryPolicies/example-policy",
    "verb": "create",
    "requestedCancellation": false,
    "apiVersion": "v3"
  },
  "done": true,
  "response": {
    PAB_POLICY
  }
}

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

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