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

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

הערה: אם הארגון נוצר ב-3 במאי 2024 או אחרי התאריך הזה, האילוץ המנוהל הקודם iam.allowedPolicyMemberDomains נאכף כברירת מחדל, והדומיין שלכם מופיע כערך המותר היחיד.

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

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

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

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

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

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

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

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

המסוף

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

   כניסה לדף Organization policies

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

3. ברשימה, בוחרים את האילוץ המנוהל Restrict allowed policy members in IAM allow policies.

4. בדף פרטי המדיניות, לוחצים על ניהול המדיניות.

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

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

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

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

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

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

11. כדי לאכוף את מדיניות הארגון במצב פרימטר לבדיקות, לוחצים על Set dry run policy. איך בודקים את מדיניות הארגון

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

gcloud

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

   name: organizations/ORG_ID/policies/iam.managed.allowedPolicyMembers
   spec:
   rules:
    - enforce: true
      parameters:
        allowedMemberSubjects:
          - ALLOWED_MEMBER_1
          - ALLOWED_MEMBER_2
        allowedPrincipalSets:
          - ALLOWED_PRINCIPAL_SET_1
          - ALLOWED_PRINCIPAL_SET_2
   

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

   • ‫ORG_ID: המזהה המספרי של הארגון ב- Google Cloud.

   • ‫ALLOWED_MEMBER_1, ‏ALLOWED_MEMBER_2: החברים שאתם רוצים לתת להם תפקידים בארגון, לדוגמה user:[e-mail].

   • ‫ALLOWED_PRINCIPAL_SET_1, ALLOWED_PRINCIPAL_SET_2: קבוצות החשבונות הראשיים שאתם רוצים לתת להם תפקידים בארגון. לדוגמה: //cloudresourcemanager.googleapis.com/organizations/0123456789012.

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

2. מגדירים את המדיניות באמצעות הפקודה org-policies set-policy והדגל spec:

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

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

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

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

REST

כדי להגדיר את מדיניות הארגון, משתמשים ב-method‏ organizations.policies.create.

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

גוף בקשת ה-JSON מכיל את ההגדרה של מדיניות הארגון. אם האילוץ הזה לא תומך בפרמטרים, צריך להשמיט את הבלוק parameters מתחת ל-rules.

{
  "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"
          ]
        }
      }
    ]
  }
}

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

• ‫ORG_ID: המזהה המספרי של הארגון ב- Google Cloud.

• ‫CONSTRAINT_NAME: שם האילוץ שרוצים להגדיר.

• ‫ALLOWED_MEMBER_1, ‏ALLOWED_MEMBER_2: החברים שאתם רוצים לתת להם תפקידים בארגון, לדוגמה user:[e-mail].

• ‫ALLOWED_PRINCIPAL_SET_1, ALLOWED_PRINCIPAL_SET_2: קבוצות החשבונות הראשיים שאתם רוצים לתת להם תפקידים בארגון. לדוגמה: //cloudresourcemanager.googleapis.com/organizations/0123456789012.

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

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

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

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

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

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

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

      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

      לדוגמה, האילוץ הבא מגביל את הקצאת התפקידים לחברים בארגון ול[e-mail]:

      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:[e-mail]'])
            )
          )
        )"
      actionType: ALLOW
      displayName: Only allow organization members and service agents to be granted roles
      

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

   המסוף

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

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

      כניסה לדף Organization policies

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

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

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

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

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

   11. לוחצים על Create constraint.

   אחרי שמזינים ערך בכל שדה, הגדרת ה-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 , נכנסים לדף מדיניות הארגון.

      כניסה לדף Organization policies

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

   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.

המסוף

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

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

   כניסה לדף Organization policies

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

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

4. בדף פרטי המדיניות, לוחצים על ניהול המדיניות.

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

6. לוחצים על Add a rule.

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

   הערה: האילוץ של הגבלה לפי דומיין לא תומך באפשרות Deny All.

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

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

9. בקטע Custom values, מזינים בשדה קבוצת חשבונות משתמשים של הארגון או מזהה לקוח ב-Google Workspace.

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

11. לוחצים על סיום.

12. אם רוצים להגדיר את אילוץ ההגבלה לפי דומיין כתנאי לתג, לוחצים על Add condition.

    1. בשדה Title, נותנים שם לתנאי.

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

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

       1. בתפריט Condition type (סוג התנאי) בכרטיסייה Condition builder (הכלי להגדרת תנאים), בוחרים באפשרות Tag (תג).

       2. בוחרים את האופרטור של התנאי. כדי להתאים תג שלם, משתמשים באופרטור matches. כדי להתאים בין מפתח תג לערך תג, משתמשים באופרטור matches ID.

       3. אם בחרתם באופרטור matches, הזינו את השם של ערך התג במרחב השמות. אם בחרתם באופרטור מזהה תואם, הזינו את מזהי המפתח והערך.

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

       5. כדי למחוק ביטוי, לוחצים על הסמל X הגדול שמשמאל לשדות התנאי.

       6. כשמסיימים לערוך את התנאים, לוחצים על שמירה.

13. כדי לאכוף את המדיניות, לוחצים על הגדרת מדיניות.

gcloud

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

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

gcloud org-policies set-policy POLICY_PATH

כאשר POLICY_PATH הוא הנתיב המלא לקובץ ה-YAML של מדיניות הארגון, שאמור להיראות כך:

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

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

• ‫ORGANIZATION_ID במזהה של משאב הארגון שבו רוצים להגדיר את המדיניות.
• ‫PRINCIPAL_SET למזהים של חשבונות המשתמשים שרוצים לאשר. אפשר לכלול קבוצות של חשבונות משתמשים בארגון או מזהי לקוחות ב-Google Workspace. לדוגמה, is:principalSet://cloudresourcemanager.googleapis.com/organizations/01234567890123 או is:C03g5e3bc

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

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

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

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

המסוף

gcloud

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 , ה-CLI של gcloud או Cloud Resource Manager API.

console

כדי לקבל את מזהה המשאב של הארגון באמצעות מסוף Google Cloud :

1. נכנסים למסוף Google Cloud :

   כניסה למסוף Google Cloud

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

בדף Settings מוצג מזהה המשאב של הארגון.

gcloud

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

gcloud organizations list

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

API

כדי למצוא את מזהה המשאב של הארגון באמצעות Cloud Resource Manager API, משתמשים ב-method‏ organizations.search(), כולל שאילתה לדומיין. לדוגמה:

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

התשובה מכילה את המטא-נתונים של משאב הארגון ששייך ל-altostrat.com, כולל המזהה של משאב הארגון.

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

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

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

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

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

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

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

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

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

gcloud

אפשר להשתמש בפקודה gcloud organizations list כדי לראות את כל הארגונים שיש לכם בהם את ההרשאה resourcemanager.organizations.get:

gcloud organizations list

הפקודה הזו תחזיר את הערכים DISPLAY_NAME, ID (מזהה הארגון) ו-DIRECTORY_CUSTOMER_ID. מספר הלקוח ב-Google Workspace הוא DIRECTORY_CUSTOMER_ID.

API

אפשר להשתמש ב-Google Workspace Directory API כדי לאחזר את מספר הלקוח ב-Google Workspace.

כשאתם מחוברים כאדמינים ב-Google Workspace, אתם יכולים להיכנס למסמכי התיעוד של השיטה (method) ‏Customers: get ב-API וללחוץ על Execute. אחרי ההרשאה, התגובה תציג את מספר הלקוח שלכם.

לחלופין, אפשר להשתמש בלקוח API:

1. מקבלים טוקן גישה מסוג OAuth להיקף ההרשאות https://www.googleapis.com/auth/admin.directory.customer.readonly.

2. מריצים את הפקודה הבאה כדי לשלוח שאילתה ל-Directory API של Google Workspace:

   curl -# -X GET "https://www.googleapis.com/admin/directory/v1/customers/customerKey" \
   -H "Authorization: Bearer $access_token" -H "Content-Type: application/json"
   

הפקודה הזו תחזיר תגובת JSON שכוללת את פרטי הלקוח. מספר הלקוח ב-Google Workspace הוא id.

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

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

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

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

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

פעולה	מזהה של חשבון משתמש
הפעלת sink ביומן של BigQuery בחשבון לחיוב	serviceAccount:[e-mail]
הפעלת רישום ביומן של גישה לאחסון	serviceAccount:[e-mail]
איך משתמשים ב-Pub/Sub כנקודת קצה לאפליקציה ל-Google Chat	serviceAccount:[e-mail]
שימוש ב-Pub/Sub כדי לקבל התראות בזמן אמת למפתחים מ-Google Play	serviceAccount:[e-mail]
שימוש ב-Pub/Sub כדי לקבל התראות לגבי תקציבים בחיוב ב-Cloud	serviceAccount:[e-mail]
שימוש ב-Pub/Sub כדי לקבל התראות על חריגות בעלויות החיוב ב-Cloud	serviceAccount:[e-mail]
שימוש בכתובת URL חתומה עם Cloud CDN	serviceAccount:[e-mail]
אימות מקור פרטי באמצעות Cloud CDN	serviceAccount:[e-mail]

שירותים ציבוריים ב-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. יוצרים אילוץ בהתאמה אישית באמצעות הפונקציה memberSubjectMatches של CEL בביטוי התנאי של האילוץ.

   לדוגמה, ביטוי התנאי הבא מגביל את הקצאת התפקידים לחברים בארגון, 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 גישה במדיניות ההרשאות.