הגבלת זהויות באמצעות שיתוף מוגבל לדומיין

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

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

• האילוץ המנוהל iam.managed.allowedPolicyMembers
• מדיניות ארגונית מותאמת אישית שמפנה אל iam.googleapis.com/AllowPolicy המשאב
• האילוץ המנוהל מהדור הקודם iam.allowedPolicyMemberDomains

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

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

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

כדי לקבל את ההרשאות שדרושות בשביל לאכוף שיתוף מוגבל לדומיין, אתם צריכים לבקש מהאדמין לתת לכם את תפקיד ה-IAM Organization policy administrator (אדמין מדיניות ארגונית) ‏(roles/orgpolicy.policyAdmin) בארגון. כדי לקרוא הסבר על מתן תפקידים, ראו איך מנהלים את הגישה ברמת הפרויקט, התיקייה והארגון.

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

שימוש באילוץ iam.managed.allowedPolicyMembers כדי להטמיע שיתוף מוגבל לדומיין

POST https://orgpolicy.googleapis.com/v2/{parent=organizations/ORGANIZATION_ID}/policies

{
  "name": "organizations/ORG_ID/policies/CONSTRAINT_NAME",
  "spec": {
    "rules": [
      {
        "enforce": true,
        "parameters": {
          "allowedMemberSubjects": [
            "ALLOWED_MEMBER_1",
            "ALLOWED_MEMBER_2"
          ],
          "allowedPrincipalSets": [
            "ALLOWED_PRINCIPAL_SET_1",
            "ALLOWED_PRINCIPAL_SET_2"
          ]
        }
      }
    ]
  }
}

שימוש במדיניות ארגונית מותאמת אישית להטמעה של שיתוף מוגבל לדומיין

1. יצירת אילוץ מותאם אישית שמגביל את חשבונות המשתמשים שיכולים לקבל תפקידים בארגון:

   1. משתמשים בפונקציה memberInPrincipalSet CEL כדי להגדיר את חשבון המשתמש של הארגון ולהגביל את הקצאת התפקידים לחברים בארגון. מידע על איתור מזהה הארגון מופיע במאמר אחזור של קבוצת משתמשים ראשיים בארגון.

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

      name: organizations/ORG_ID/customConstraints/custom.allowInternalIdentitiesOnly
      resourceTypes: iam.googleapis.com/AllowPolicy
      methodTypes:
        - CREATE
        - UPDATE
      condition:
        "resource.bindings.all(
          binding,
          binding.members.all(member,
            MemberInPrincipalSet(member, ['//cloudresourcemanager.googleapis.com/organizations/ORG_ID'])
          )
        )"
      actionType: ALLOW
      displayName: Only allow organization members to be granted roles
      

   2. אפשר גם להוסיף פונקציות נוספות של CEL, שמחוברות באמצעות אופרטורים לוגיים (&&,‏ || או !), כדי לצמצם את ההגבלה. אפשר להוסיף כל אחת מהפונקציות הבאות:

      • memberInPrincipalSet
      • memberTypeMatches
      • memberSubjectMatches

      לדוגמה, ההגבלה הבאה מגבילה את הענקת התפקידים לחברים בארגון ול-admin@example.com:

      name: organizations/ORG_ID/customConstraints/custom.allowInternalIdentitiesOnly
      resourceTypes: iam.googleapis.com/AllowPolicy
      methodTypes:
        - CREATE
        - UPDATE
      condition:
        "resource.bindings.all(
          binding,
          binding.members.all(member,
            (
              MemberInPrincipalSet(member, ['//cloudresourcemanager.googleapis.com/organizations/ORG_ID'])
              ||
              MemberSubjectMatches(member, ['user:admin@example.com'])
            )
          )
        )"
      actionType: ALLOW
      displayName: Only allow organization members and service agents to be granted roles
      

2. מגדירים את האילוץ המותאם אישית:

   המסוף

   כדי ליצור אילוץ בהתאמה אישית:

   1. במסוף Google Cloud , נכנסים לדף מדיניות הארגון.

      מעבר למדיניות הארגון

   2. בכלי לבחירת פרויקטים, בוחרים את הפרויקט שרוצים להגדיר לו את מדיניות הארגון.
   3. לוחצים על add Custom constraint (הגבלה מותאמת אישית).
   4. בתיבה שם לתצוגה, מזינים שם שאנשים יכולים לקרוא למגבלה. השם הזה משמש בהודעות שגיאה, ואפשר להשתמש בו לצורך זיהוי וניפוי באגים. אל תשתמשו בפרטים אישיים מזהים (PII) או במידע אישי רגיש בשמות לתצוגה, כי השם הזה עלול להיחשף בהודעות שגיאה. השדה הזה יכול להכיל עד 200 תווים.
   5. בתיבה Constraint ID (מזהה ההגבלה), מזינים את המזהה שרוצים להגדיר להגבלה החדשה בהתאמה אישית. אילוץ מותאם אישית יכול להכיל רק אותיות (כולל אותיות גדולות וקטנות) או מספרים, למשל custom.allowInternalIdentitiesOnly. השדה הזה יכול להכיל עד 70 תווים, לא כולל הקידומת (custom.), לדוגמה, organizations/123456789/customConstraints/custom. אל תכללו פרטים אישיים מזהים (PII) או נתונים רגישים במזהה האילוץ, כי הם עלולים להיחשף בהודעות שגיאה.
   6. בתיבה Description, מזינים תיאור של האילוץ שכתוב בצורה שקריאה לאנשים. התיאור הזה משמש כהודעת שגיאה כשמתבצעת הפרה של המדיניות. לכלול פרטים על הסיבה להפרת המדיניות ואיך לפתור אותה. אל תכללו בתיאור פרטים אישיים מזהים (PII) או מידע אישי רגיש, כי הם עלולים להיחשף בהודעות שגיאה. השדה הזה יכול להכיל עד 2,000 תווים.
   7. בתיבה Resource type, בוחרים את השם של משאב REST‏ Google Cloud שמכיל את האובייקט והשדה שרוצים להגביל – לדוגמה, container.googleapis.com/NodePool. רוב סוגי המשאבים תומכים בעד 20 אילוצים מותאמים אישית. אם תנסו ליצור עוד אילוצים בהתאמה אישית, הפעולה תיכשל.
   8. אפשר לאכוף את ההגבלה הזו רק בשיטת REST‏ CREATE.

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

   9. כדי להגדיר תנאי, לוחצים על edit Edit condition.
   1. בחלונית Add condition, יוצרים תנאי CEL שמתייחס למשאב שירות נתמך, לדוגמה, resource.management.autoUpgrade == false. השדה הזה יכול להכיל עד 1,000 תווים. פרטים על השימוש ב-CEL זמינים במאמר בנושא Common Expression Language. מידע נוסף על משאבי השירות שאפשר להשתמש בהם באילוצים בהתאמה אישית זמין במאמר שירותים שתומכים באילוצים בהתאמה אישית.
   2. לוחצים על Save.
   10. בקטע פעולה, בוחרים אם לאשר או לדחות את השיטה שנבדקה אם התנאי מתקיים.

   הפעולה deny (דחייה) פירושה שהפעולה ליצירה או לעדכון של המשאב נחסמת אם התנאי מוערך כ-True.

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

   11. לוחצים על יצירת אילוץ.

   אחרי שמזינים ערך בכל שדה, מופיעה משמאל הגדרת ה-YAML המקבילה לאילוץ המותאם אישית הזה.

   gcloud

   1. כדי ליצור אילוץ בהתאמה אישית, יוצרים קובץ YAML בפורמט הבא:

   name: organizations/ORGANIZATION_ID/customConstraints/CONSTRAINT_NAME
   resourceTypes: RESOURCE_NAME
   methodTypes:
     - CREATE
   condition: "CONDITION"
   actionType: ACTION
   displayName: DISPLAY_NAME
   description: DESCRIPTION

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

   • ‫ORGANIZATION_ID: מזהה הארגון, למשל 123456789.
   • ‫CONSTRAINT_NAME: השם שרוצים לתת לאילוץ המותאם אישית החדש. אילוץ מותאם אישית יכול להכיל רק אותיות (כולל אותיות רישיות וקטנות) או מספרים, למשל, custom.allowInternalIdentitiesOnly. השדה הזה יכול להכיל עד 70 תווים, לא כולל הקידומת (custom.) – לדוגמה, organizations/123456789/customConstraints/custom. אל תכללו פרטים אישיים מזהים (PII) או נתונים רגישים במזהה האילוץ, כי הם עלולים להיחשף בהודעות שגיאה.
   • ‫RESOURCE_NAME: השם מוגדר במלואו של המשאב Google Cloudשמכיל את האובייקט והשדה שרוצים להגביל. לדוגמה: iam.googleapis.com/AllowPolicy. רוב סוגי המשאבים תומכים בעד 20 אילוצים מותאמים אישית. אם תנסו ליצור עוד אילוצים בהתאמה אישית, הפעולה תיכשל.
   • ‫methodTypes: שיטות ה-REST שבהן האילוץ נאכף. הערך יכול להיות רק CREATE.

   כדי לראות את השיטות הנתמכות לכל שירות, מחפשים את השירות ב שירותים שתומכים באילוצים בהתאמה אישית.

   • ‫CONDITION: תנאי CEL שנכתב על סמך ייצוג של משאב שירות נתמך. השדה הזה יכול להכיל עד 1,000 תווים. לדוגמה: "resource.bindings.all( binding, binding.members.all(member, MemberInPrincipalSet(member, ['//cloudresourcemanager.googleapis.com/organizations/ORG_ID']) ) )".

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

   • ‫ACTION: הפעולה שתתבצע אם התנאי condition יתקיים. הערך יכול להיות רק ALLOW.

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

   • DISPLAY_NAME: שם קריא לאנשים של האילוץ. השם הזה מופיע בהודעות שגיאה ויכול לשמש לזיהוי ולניפוי באגים. אל תשתמשו בפרטים אישיים מזהים (PII) או במידע אישי רגיש בשמות המוצגים, כי השם הזה עלול להיחשף בהודעות שגיאה. השדה הזה יכול להכיל עד 200 תווים.
   • ‫DESCRIPTION: תיאור ידידותי למשתמש של האילוץ שיוצג כהודעת שגיאה אם המדיניות תופר. השדה הזה יכול להכיל עד 2,000 תווים.
   2. אחרי שיוצרים קובץ YAML לאילוץ חדש בהתאמה אישית, צריך להגדיר אותו כדי שיהיה זמין למדיניות הארגון בארגון. כדי להגדיר אילוץ בהתאמה אישית, משתמשים בפקודה gcloud org-policies set-custom-constraint:

   gcloud org-policies set-custom-constraint CONSTRAINT_PATH

   מחליפים את CONSTRAINT_PATH בנתיב המלא לקובץ האילוצים המותאמים אישית. לדוגמה, /home/user/customconstraint.yaml.

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

   3. כדי לוודא שהאילוץ המותאם אישית קיים, משתמשים בפקודה gcloud org-policies list-custom-constraints:

   gcloud org-policies list-custom-constraints --organization=ORGANIZATION_ID

   מחליפים את ORGANIZATION_ID במזהה של משאב הארגון.

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

3. אכיפת מדיניות הארגון המותאמת אישית:

   כדי לאכוף אילוץ, יוצרים מדיניות ארגון שמפנה אליו, ואז מחילים את מדיניות הארגון הזו על משאב Google Cloud .

   המסוף

   1. במסוף Google Cloud , נכנסים לדף מדיניות הארגון.

      מעבר למדיניות הארגון

   2. מכלי לבחירת פרויקטים, בוחרים את הפרויקט שרוצים להגדיר לו את מדיניות הארגון.
   3. מהרשימה בדף מדיניות הארגון, בוחרים את האילוץ כדי לראות את הדף פרטי המדיניות של האילוץ הזה.
   4. כדי להגדיר את מדיניות הארגון עבור המשאב הזה, לוחצים על ניהול מדיניות.
   5. בדף עריכת מדיניות, בוחרים באפשרות במקום המדיניות של המשאב הראשי.
   6. לוחצים על Add a rule.
   7. בקטע Enforcement (אכיפה), בוחרים אם מדיניות הארגון הזו נאכפת או לא.
   8. אופציונלי: כדי להגדיר את מדיניות הארגון כתלויה בתג, לוחצים על הוספת תנאי. הערה: אם מוסיפים כלל מותנה למדיניות ארגון, צריך להוסיף לפחות כלל לא מותנה אחד, אחרת אי אפשר לשמור את המדיניות. מידע נוסף על מדיניות ארגונית עם תגים
   9. לוחצים על בדיקת שינויים כדי לדמות את ההשפעה של מדיניות הארגון. מידע נוסף זמין במאמר בדיקת שינויים במדיניות הארגון באמצעות סימולטור המדיניות.
   10. כדי לאכוף את המדיניות של הארגון במצב פרימטר לבדיקות, לוחצים על הגדרת המדיניות להרצת בדיקה. מידע נוסף זמין במאמר בנושא בדיקת מדיניות הארגון.
   11. אחרי שמוודאים שמדיניות הארגון במצב הרצה יבשה פועלת כמו שרוצים, לוחצים על הגדרת מדיניות כדי להגדיר את המדיניות הפעילה.

   gcloud

   1. כדי ליצור מדיניות ארגונית עם כללים בוליאניים, יוצרים קובץ YAML של מדיניות שמפנה לאילוץ:

   name: projects/PROJECT_ID/policies/CONSTRAINT_NAME
   spec:
     rules:
     - enforce: true
   
   dryRunSpec:
     rules:
     - enforce: true

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

   • ‫PROJECT_ID: הפרויקט שבו רוצים לאכוף את האילוץ.
   • CONSTRAINT_NAME: השם שהגדרתם לאילוץ המותאם אישית. לדוגמה, custom.allowInternalIdentitiesOnly.
   2. כדי לאכוף את מדיניות הארגון במצב הרצה יבשה, מריצים את הפקודה הבאה עם הדגל dryRunSpec:

   gcloud org-policies set-policy POLICY_PATH --update-mask=dryRunSpec

   מחליפים את POLICY_PATH בנתיב המלא לקובץ ה-YAML של מדיניות הארגון. יחלפו עד 15 דקות לפני שהמדיניות תיכנס לתוקף.

   3. אחרי שמוודאים שמדיניות הארגון במצב הרצה יבשה פועלת כמו שרוצים, מגדירים את המדיניות הפעילה באמצעות הפקודה org-policies set-policy והדגל spec:

   gcloud org-policies set-policy POLICY_PATH --update-mask=spec

   מחליפים את POLICY_PATH בנתיב המלא לקובץ ה-YAML של מדיניות הארגון. יחלפו עד 15 דקות לפני שהמדיניות תיכנס לתוקף.

שימוש באילוץ iam.allowedPolicyMemberDomains כדי להטמיע שיתוף מוגבל לדומיין

האילוץ של הגבלת הדומיין הוא אילוץ מנוהל מדור קודם עם רשימה constraint_type. אפשר לציין קבוצה של חשבונות ראשיים של ארגון או מזהה לקוח של Google Workspace ברשימה allowed_values של אילוץ הגבלת דומיין. מידע נוסף זמין במאמר ההבדל בין קבוצת המנהלים הראשית של הארגון לבין מזהה הלקוח של Google Workspace.

הארגון הראשי והמזהה שלכם ב-Google Workspace לא מקבלים הרשאה באופן אוטומטי. כדי לאפשר לגורמים בארגון שלכם לגשת למשאבים בארגון, צריך לכלול את קבוצת הגורמים הראשית של הארגון או את מזהה Google Workspace כקבוצת גורמים מורשית.

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

אפשר להגדיר מדיניות ארגון שבה אילוץ ההגבלה לפי הדומיין יחול על כל משאב שנכלל ברשימת המשאבים הנתמכים. לדוגמה, קטגוריות של Cloud Storage, מערכי נתונים ב-BigQuery או מכונות וירטואליות ב-Compute Engine.

gcloud org-policies set-policy POLICY_PATH

name: organizations/ORGANIZATION_ID/policies/iam.allowedPolicyMemberDomains
spec:
  rules:
  - condition: # This condition applies to the values block.
      expression: "resource.matchTag('ORGANIZATION_ID/environment', 'dev')"
    values:
      allowedValues:
      - PRINCIPAL_SET
  - values:
      allowedValues:
      - PRINCIPAL_SET

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

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

הודעת שגיאה לדוגמה

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

ERROR: (gcloud.projects.set-iam-policy) FAILED_PRECONDITION:
One or more users named in the policy do not belong to a permitted customer.

אחזור של קבוצת ישויות של ארגון

אפשר לקבל את מזהה משאב הארגון באמצעות מסוף Google Cloud,‏ Google Cloud CLI או Cloud Resource Manager API. Google Cloud

gcloud organizations list

GET https://cloudresourcemanager.googleapis.com/v3/organizations:search{query=domain:altostrat.com}

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

principalSet://iam.googleapis.com/organizations/01234567890123

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

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

מידע נוסף על מזהי חשבונות משתמשים ב-IAM מופיע במאמר מזהים של חשבונות משתמשים.

אחזור מספר לקוח ב-Google Workspace

הזנת מזהה הלקוח ב-Google Workspace מאפשרת להעניק תפקידים בארגון לגורמים הבאים:

• כל הזהויות בכל הדומיינים שמשויכים למספר הלקוח שלכם ב-Google Workspace
• כל מאגרי הזהויות של כוח העבודה בארגון
• כל חשבונות השירות ומאגרי הזהויות של עומסי העבודה בכל פרויקט בארגון
• כל סוכני השירות שמשויכים למשאבים בארגון.

יש שתי דרכים להשיג את מזהה הלקוח ב-Google Workspace שמשמש לאילוץ הגבלת הדומיין:

gcloud organizations list

הגדרת חריגים להגבלת השיתוף בדומיין

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

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

אם אתם משתמשים במדיניות ארגונית בהתאמה אישית או באילוץ המנוהל iam.managed.allowedPolicyMembers כדי להטמיע שיתוף מוגבל לדומיין, כדאי להוסיף את החשבונות האלה כחריגים לאילוץ השיתוף המוגבל לדומיין. כדי להוסיף חשבון כחריג, מוסיפים את מזהה הגורם המרכזי של החשבון לרשימת החברים המורשים.

אם אתם משתמשים במגבלה מנוהלת מדור קודם iam.allowedPolicyMemberDomains כדי להגביל את השיתוף לדומיין, יכול להיות שתצטרכו לאלץ גישה לחשבון כדי לבצע את הפעולות שמופיעות ברשימה.

שירותים ציבוריים ב-Cloud Run

ב-Cloud Run אפשר להגדיר שירותים כציבוריים. עם זאת, אם תטמיעו שיתוף מוגבל לדומיין, משתמשים מחוץ לארגון לא יוכלו לגשת לשירותי Cloud Run ציבוריים.

כדי לאפשר למשתמשים לגשת לשירותים ציבוריים של Cloud Run, צריך להשבית את בדיקת IAM של Cloud Run Invoker בשירותי Cloud Run. מידע נוסף מופיע במאמר השבתה של Cloud Run Invoker לשירותים.

שיתוף נתונים אחרים באופן ציבורי

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

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

כדי להוסיף חריגה ל-allUsers ול-allAuthenticatedUsers, צריך ליצור מדיניות ארגונית מותאמת אישית מותנית שמבוססת על תגי משאבים.

1. יוצרים מפתח תג במשאב הארגון.

   gcloud resource-manager tags keys create allUsersIngress \
     --parent=organizations/ORGANIZATION_ID
   

   מחליפים את ORGANIZATION_ID במזהה הארגון.

2. יוצרים ערך תג למפתח התג שיצרתם.

   gcloud resource-manager tags values create True \
   --parent=ORGANIZATION_ID/allUsersIngress \
   --description="Allow allUsers to access internal Cloud Run services"
   

3. מצרפים את התג למשאבים שרוצים לשתף עם הציבור.

4. יוצרים אילוץ מותאם אישית באמצעות פונקציית ה-CEL‏ memberSubjectMatches בביטוי התנאי של האילוץ.

   לדוגמה, ביטוי התנאי הבא מגביל את הקצאת התפקידים לחברים בארגון, allUsers ו-allAuthenticatedUsers:

   name: organizations/ORGANIZATION_ID/customConstraints/custom.allowInternalAndSpecialIdentitiesOnly
   resourceTypes: iam.googleapis.com/AllowPolicy
   methodTypes:
     - CREATE
     - UPDATE
   condition:
     "resource.bindings.all(
       binding,
       binding.members.all(member,
         (
           MemberInPrincipalSet(member, ['//cloudresourcemanager.googleapis.com/organizations/ORG_ID'])
           ||
           MemberSubjectMatches(member, ['allUsers', 'allAuthenticatedUsers'])
         )
       )
     )"
   actionType: ALLOW
   displayName: Only allow organization members, allusers, and allAuthenticatedUsers to be granted roles
   

5. יוצרים מדיניות ארגון שאוכפת את האילוץ המותאם אישית.

   name: organizations/ORGANIZATION_ID/policies/iam.allowedPolicyMemberDomains
   spec:
     rules:
     - allowAll: true
       condition:
         expression: resource.matchTag("ORGANIZATION_ID/allUsersIngress", "True")
         title: allowAllUsersIngress
   

6. אוכפים את מדיניות הארגון.

   gcloud org-policies set-policy POLICY_PATH
   

   מחליפים את POLICY_PATH בנתיב ובשם הקובץ של מדיניות הארגון.

מדיניות הארגון המותנית מאפשרת להעניק הרשאות לזהות allUsers במשאבים שתויגו בתג allUsersIngress: true.

כפיית גישה לחשבון

אם אתם צריכים לאלץ גישה לחשבון בפרויקט שמפר את ההגבלות של הדומיין:

1. מסירים את מדיניות הארגון שמכילה את אילוץ ההגבלה לפי הדומיין.

2. מעניקים גישה לחשבון לפרויקט.

3. מטמיעים מחדש את מדיניות הארגון עם אילוץ ההגבלה לפי הדומיין.

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

1. יוצרים קבוצת Google בדומיין המותר.

2. משתמשים במרכז האדמינים של Google Workspace כדי להשבית את הגבלת הדומיין עבור הקבוצה הזו.

3. מוסיפים את חשבון השירות לקבוצה.

4. נותנים לקבוצה ב-Google גישה במדיניות ההרשאות.