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

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

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

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

• אם אתם משתמשים ב-Google Cloud CLI, צריך להגדיר את הפרויקט שבו רוצים להשתמש כדי לבצע קריאות ל-API:

  gcloud config set project PROJECT_ID

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

• מפעילים את Policy Simulator API ואת Resource Manager API.

  תפקידים שנדרשים להפעלת ממשקי API

  כדי להפעיל ממשקי API, נדרשת ההרשאה serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד 'בעלים' (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד 'אדמין בממשק 'שימוש בשירות'' (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידים

  הפעלת ממשקי ה-API

• אופציונלי: אפשר לקרוא מבוא לשירות מדיניות הארגון.

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

כדי לקבל את ההרשאות שדרושות להרצה של סימולציות ולגישה אליהן, צריך לבקש מהאדמין להקצות לכם את תפקיד ה-IAM OrgPolicy Simulator Admin (roles/policysimulator.orgPolicyAdmin) בארגון. כדי לקרוא הסבר על מתן תפקידים, ראו איך מנהלים את הגישה ברמת הפרויקט, התיקייה והארגון.

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

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

כדי להריץ סימולציות ולגשת אליהן, צריך את ההרשאות הבאות:

• orgpolicy.constraints.list
• orgpolicy.customConstraints.get
• orgpolicy.policies.list
• cloudasset.assets.searchAllResources
• cloudasset.assets.listResource
• cloudasset.assets.listOrgPolicy
• policysimulator.orgPolicyViolationsPreviews.list
• policysimulator.orgPolicyViolationsPreviews.get
• policysimulator.orgPolicyViolationsPreviews.create
• policysimulator.orgPolicyViolations.list

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

בדיקת שינוי במדיניות

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

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

בדיקת שינוי באילוץ מותאם אישית

המסוף

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

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

2. בתפריט לבחירת ארגון, בוחרים את משאב הארגון.

3. מבצעים אחת מהפעולות הבאות:

   • כדי לבדוק אילוץ מותאם אישית חדש, לוחצים על Custom constraint (אילוץ מותאם אישית).

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

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

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

   2. בתיבה מזהה אילוץ, מזינים את השם שרוצים לתת לאילוץ המותאם אישית החדש. אילוץ מותאם אישית חייב להתחיל ב-custom., ויכול לכלול רק אותיות רישיות, אותיות קטנות או מספרים, לדוגמה, custom.disableGkeAutoUpgrade. האורך המקסימלי של השדה הזה הוא 70 תווים, לא כולל הקידומת, לדוגמה, organizations/123456789/customConstraints/custom.. אל תכללו פרטים אישיים מזהים (PII) או נתונים רגישים במזהה האילוץ, כי הם עלולים להיחשף בהודעות שגיאה.

      אי אפשר לשנות את מזהה האילוץ אחרי שיוצרים אילוץ בהתאמה אישית.

   3. בתיבה Description (תיאור), מזינים תיאור קריא של האילוץ שיוצג כהודעת שגיאה אם המדיניות תופר. האורך המקסימלי של השדה הוא 2,000 תווים. אל תכללו בתיאור פרטים אישיים מזהים (PII) או מידע אישי רגיש, כי הם עלולים להיחשף בהודעות שגיאה.

   4. בתיבה Resource type, בוחרים את השם של משאב ה-REST‏ Google Cloudשמכיל את האובייקט והשדה שרוצים להגביל – לדוגמה, container.googleapis.com/NodePool. ברוב סוגי המשאבים אפשר להגדיר עד 20 אילוצים מותאמים אישית לכל משאב. אם תנסו ליצור אילוץ בהתאמה אישית למשאב שכבר הוגדר לו המספר המקסימלי של אילוצים בהתאמה אישית, הפעולה תיכשל.

   5. בקטע שיטת האכיפה, בוחרים אם לאכוף את ההגבלה על שיטת REST‏ CREATE, או על שיטות CREATE ו-UPDATE. לא כל השירותים של Google Cloud תומכים בשתי השיטות. כדי לראות את השיטות הנתמכות לכל שירות, מחפשים את השירות בקטע שירותים נתמכים.

   6. כדי להגדיר תנאי, לוחצים על Edit condition.

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

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

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

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

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

5. לוחצים על בדיקת אילוץ.

6. אם זה אילוץ חדש, יופיע החלונית Configure organization policy. כדי להגדיר מדיניות ארגון שאוכפת את האילוץ בהתאמה אישית:

   1. בתיבה Select scope (בחירת היקף), בוחרים את המשאב שרוצים לבדוק את האילוץ המותאם אישית לגביו.

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

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

   4. בקטע Enforcement, בוחרים באפשרות On.

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

   6. לוחצים על Done (סיום) ואז על Continue (המשך).

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

gcloud

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

   אם רוצים לבדוק שינויים באילוץ מותאם אישית קיים, אפשר להשתמש בפקודה organizations.customConstraints.get ה-CLI של gcloud כדי לאחזר את הייצוג הנוכחי של האילוץ המותאם אישית בפורמט JSON או YAML, ואז לערוך את הקובץ הזה.

   קובץ YAML שמגדיר אילוץ בהתאמה אישית נראה בערך כך:

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

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

   • ‫ORGANIZATION_ID: מזהה הארגון, למשל 123456789.

   • ‫CONSTRAINT_NAME: השם שרוצים לתת לאילוץ החדש בהתאמה אישית. אילוץ מותאם אישית חייב להתחיל ב-custom., ויכול לכלול רק אותיות רישיות, אותיות קטנות או מספרים, לדוגמה, custom.disableGkeAutoUpgrade. האורך המקסימלי של השדה הזה הוא 70 תווים, לא כולל הקידומת, לדוגמה, organizations/123456789/customConstraints/custom..

   • ‫RESOURCE_NAME: השם המלא שלGoogle Cloud משאב REST שמכיל את האובייקט והשדה שרוצים להגביל. לדוגמה, container.googleapis.com/NodePool. ברוב סוגי המשאבים אפשר להגדיר עד 20 אילוצים מותאמים אישית לכל משאב. אם תנסו ליצור אילוץ בהתאמה אישית למשאב שכבר הוגדר לו המספר המקסימלי של אילוצים בהתאמה אישית, הפעולה תיכשל. מידע נוסף על משאבי השירות שאפשר להשתמש בהם באילוצים מותאמים אישית זמין במאמר שירותים שתומכים באילוצים מותאמים אישית.

   • ‫METHOD1,METHOD2: רשימה של שיטות RESTful שבהן ייאכף האילוץ. הערך יכול להיות CREATE או CREATE ו-UPDATE. לא כל השירותים של Google Cloud תומכים בשתי השיטות. כדי לראות את השיטות הנתמכות לכל שירות, צריך לחפש את השירות בשירותים נתמכים.

   • ‫CONDITION: תנאי CEL שמתייחס למשאב שירות נתמך, לדוגמה: "resource.management.autoUpgrade == false". האורך המקסימלי של השדה הוא 1,000 תווים. פרטים על השימוש ב-CEL זמינים במאמר בנושא Common Expression Language.

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

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

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

   • ‫DISPLAY_NAME: שם קריא לאנשים של האילוץ. האורך המקסימלי של השדה הוא 200 תווים.

   • ‫DESCRIPTION: תיאור ידידותי למשתמש של האילוץ, שיוצג כהודעת שגיאה אם המדיניות תופר. אורך השדה הזה מוגבל ל-2, 000 תווים. מידע נוסף על יצירה וניהול של אילוצים בהתאמה אישית זמין במאמר יצירה וניהול של אילוצים בהתאמה אישית.

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

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

     name: organizations/ORGANIZATION_ID/policies/CONSTRAINT_NAME
     spec:
       rules:
       - enforce: true
     

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

     • ‫ORGANIZATION_ID במזהה הארגון, למשל 1234567890123.

     • ‫CONSTRAINT_NAME בשם האילוץ המותאם אישית שרוצים לבדוק. לדוגמה, custom.EnforceGKEBinaryAuthz.

   • כדי לבדוק את האכיפה של מגבלה מותאמת אישית באופן מותנה על סמך קיום תג מסוים, יוצרים קובץ JSON או YAML שמגדיר את מדיניות הארגון:

     name: organizations/ORGANIZATION_ID/policies/CONSTRAINT_NAME
     spec:
       rules:
       - condition:
           expression: CONDITION
         enforce: false
       - enforce: true
     

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

     • ‫ORGANIZATION_ID במזהה הארגון, למשל 1234567890123.

     • ‫CONSTRAINT_NAME בשם האילוץ המותאם אישית שרוצים לבדוק. לדוגמה, custom.EnforceGKEBinaryAuthz.

     • ‫CONDITION עם תנאי CEL שמפנה למשאב שירות נתמך, לדוגמה "resource.matchTag('env', 'dev')".

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

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

     name: organizations/ORGANIZATION_ID/policies/CONSTRAINT_NAME
     spec:
       inheritFromParent: true
     

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

     • ‫ORGANIZATION_ID במזהה הארגון, למשל 1234567890123.

     • ‫CONSTRAINT_NAME בשם האילוץ המותאם אישית שרוצים לבדוק. לדוגמה, custom.EnforceGKEBinaryAuthz.

3. כדי לדמות את השינוי באילוץ מותאם אישית, במדיניות הארגון או בשניהם, מריצים את הפקודה policy-intelligence simulate orgpolicy:

   gcloud policy-intelligence simulate orgpolicy \
     --organization=ORGANIZATION_ID \
     --custom-constraints=CONSTRAINT_PATH \
     --policies=POLICY_PATH
   

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

   • ‫ORGANIZATION_ID: מזהה הארגון, למשל 1234567890123. אין תמיכה בהדמיית שינויים בכמה ארגונים.

   • ‫CONSTRAINT_PATH: הנתיב המלא לאילוץ המותאם אישית שיצרתם או עדכנתם. לדוגמה, tmp/constraint.yaml. אם מגדירים את הדגל --policies, אין צורך להגדיר את הדגל --custom-constraints.

   • ‫POLICY_PATH: הנתיב המלא למדיניות הארגון שיצרתם או עדכנתם. לדוגמה, tmp/policy.yaml אם מגדירים את הדגל --custom-constraints, לא צריך להגדיר את הדגל --policies.

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

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

זוהי דוגמה לתגובה של סימולציה של מדיניות ארגונית. הסימולציה הזו כוללת אילוץ מותאם אישית שמגביל את היצירה של משאבי אשכול ב-Google Kubernetes Engine שבהם לא מופעלת Binary Authorization. במקרה הזה, אם השינוי המוצע יוחל, שני משאבי אשכול יפרו את המדיניות: orgpolicy-test-cluster בפרויקט simulator-test-project ו-autopilot-cluster-1 בפרויקט orgpolicy-test-0.

Waiting for operation [organizations/012345678901/locations/global/orgPolic
yViolationsPreviews/85be9a2d-8c49-470d-a65a-d0cb9ffa8f83/operations/1883a83
c-c448-42e5-a7c5-10a850928f06] to complete...done.
---
customConstraint:
  actionType: ALLOW
  condition: resource.binaryAuthorization.enabled == true
  methodTypes:
  - CREATE
  name: organizations/012345678901/customConstraints/custom.EnforceGKEBinaryAuthz
  resourceTypes:
  - container.googleapis.com/Cluster
name: organizations/012345678901/locations/global/orgPolicyViolationsPreviews/3dd47fd3-6df1-4156-8f10-413a3fc0ed83/orgPolicyViolations/b9fd23a5-7163-46de-9fec-7b9aa6af1113
resource:
  ancestors:
  - organizations/012345678901
  - projects/456789012345
  assetType: container.googleapis.com/Cluster
  resource: //container.googleapis.com/projects/simulator-test-project/locations/us-central1/clusters/orgpolicy-test-cluster
---
customConstraint:
  actionType: ALLOW
  condition: resource.binaryAuthorization.enabled == true
  methodTypes:
  - CREATE
  name: organizations/012345678901/customConstraints/custom.EnforceGKEBinaryAuthz
  resourceTypes:
  - container.googleapis.com/Cluster
name: organizations/012345678901/locations/global/orgPolicyViolationsPreviews/3dd47fd3-6df1-4156-8f10-413a3fc0ed83/orgPolicyViolations/e73896e6-7613-4a8d-8436-5df7a6455121
resource:
  ancestors:
  - organizations/012345678901
  - folders/789012345678
  - projects/456789012345
  assetType: container.googleapis.com/Cluster
  resource: //container.googleapis.com/projects/orgpolicy-test-0/locations/us-central1/clusters/autopilot-cluster-1

בדיקת שינוי באילוץ מנוהל

המסוף

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

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

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

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

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

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

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

7. בקטע Enforcement (אכיפה), בוחרים אם לאכוף את מדיניות הארגון הזו או לא.

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

9. לוחצים על בדיקת שינויים.

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

gcloud

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

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

     name: RESOURCE_TYPE/RESOURCE_ID/policies/CONSTRAINT_NAME
     spec:
       rules:
       - enforce: ENFORCEMENT_STATE
     

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

     • ‫RESOURCE_TYPE עם organizations,‏ folders או projects.

     • ‫RESOURCE_ID עם מזהה הארגון, מזהה התיקייה, מזהה הפרויקט או מספר הפרויקט, בהתאם לסוג המשאב שצוין ב-RESOURCE_TYPE.

     • ‫CONSTRAINT_NAME בשם האילוץ המנוהל שרוצים לבדוק. לדוגמה, iam.managed.disableServiceAccountKeyCreation.

     • ‫ENFORCEMENT_STATE עם true כדי לאכוף את מדיניות הארגון הזו כשהיא מוגדרת, או false כדי להשבית אותה כשהיא מוגדרת.

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

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

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

     name: organizations/ORGANIZATION_ID/policies/CONSTRAINT_NAME
     spec:
       inheritFromParent: true
     

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

   • ORGANIZATION_ID במזהה הארגון.

   • ‫CONSTRAINT_NAME בשם של האילוץ המנוהל שרוצים למחוק. לדוגמה, iam.managed.disableServiceAccountKeyCreation.

2. מריצים את הפקודה policy-intelligence simulate orgpolicy:

   gcloud policy-intelligence simulate orgpolicy \
     --organization=ORGANIZATION_ID \
     --policies=POLICY_PATH
   

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

   • ‫ORGANIZATION_ID במזהה הארגון, למשל 1234567890123. אין תמיכה בהדמיית שינויים בכמה ארגונים.

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

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

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

תוצאות של סימולטור המדיניות

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

כדי לראות את תוצאות הסימולציה, עוברים לדף היסטוריית הסימולציות.

מעבר להיסטוריית הסימולציות

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

הסטטוסים האפשריים של סימולציות:

• בתהליך: הסימולציה פועלת, אבל עדיין לא הסתיימה. אפשר להפעיל עד 50 סימולציות בו-זמנית.
• הושלמה: הסימולציה הושלמה.
• שגיאה: הסימולציה לא הושלמה בגלל שגיאה.

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

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

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

החלת שינוי במדיניות שנבדק

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

המסוף

1. כדי לאכוף אילוץ מותאם אישית בתוצאות של סימולטור המדיניות, עוברים לדף היסטוריית הסימולציות.

   מעבר להיסטוריית הסימולציות

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

3. אם דוח הסימולציה הזה כולל אילוץ בהתאמה אישית, לוחצים על שמירת האילוץ.

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

   כדי לאכוף את מדיניות הארגון באופן מיידי, לוחצים על ואז על Set policy (הגדרת מדיניות).

gcloud

1. כדי לאכוף אילוץ מותאם אישית, צריך להגדיר אותו כך שיהיה זמין למדיניות הארגון בארגון שלכם. כדי להגדיר אילוץ בהתאמה אישית, משתמשים בפקודה gcloud org-policies set-custom-constraint:

   gcloud org-policies set-custom-constraint CONSTRAINT_PATH
   

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

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

2. כדי להגדיר את מדיניות הארגון, משתמשים בפקודה gcloud org-policies set-policy:

   gcloud org-policies set-policy POLICY_PATH
   

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

   המדיניות תיכנס לתוקף תוך 15 דקות לכל היותר.

שמירת תוצאות הסימולציה

המסוף

אם אתם משתמשים במסוף Google Cloud , אתם יכולים לשמור את התוצאות של Policy Simulator כקובץ CSV.

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

   מעבר להיסטוריית הסימולציות

2. בוחרים את דוח הסימולציה שרוצים לשמור.

3. לוחצים על ייצוא התוצאות המלאות.

gcloud

אם אתם משתמשים ב-gcloud CLI, אתם יכולים לשמור את התוצאות של סימולטור המדיניות כקבצים בפורמט JSON או YAML.

כברירת מחדל, תוצאות הבדיקה ב-Google Cloud CLI מוצגות בפורמט YAML. כדי לשמור תוצאת בדיקה כקובץ YAML, מפנים מחדש את הפלט של הפקודה simulate orgpolicy כשמריצים את הסימולציה:

> FILENAME

מחליפים את FILENAME בשם של קובץ הפלט.

כדי לשמור תוצאת בדיקה כקובץ JSON, מוסיפים את הדגל הבא לפקודה simulate orgpolicy כשמריצים את הסימולציה:

--format=json > FILENAME

מחליפים את FILENAME בשם של קובץ הפלט.

שגיאות

השגיאות הבאות עלולות לגרום לסימולציה להיכשל:

• חריגה ממספר הסימולציות המקסימלי שמתבצעות בו-זמנית: למשתמש יש כבר 50 סימולציות שמתבצעות בו-זמנית, שזה המספר המקסימלי של סימולציות שמתבצעות בו-זמנית שלמשתמש יכולות להיות. כדי לפתור את הבעיה, צריך לחכות עד שאחת מהסימולציות שמתבצעות תסתיים, ואז לנסות להריץ שוב את הסימולציה.
• זמן קצוב לתפוגה: ההרצה של ההדמיה נמשכה יותר מדי זמן והיא הופסקה. כל סימולציה שנמשכת יותר מ-4 שעות מסתיימת אוטומטית בגלל חוסר פעילות (timeout). כדי לפתור את הבעיה, מומלץ להפעיל שוב את הסימולציה או להקטין את הגודל שלה.
• בניית הסימולציה לא תקינה: מדיניות הארגון המוצעת לא תקינה. לדוגמה, לכלל המדיניות המוצע יש ביטוי תנאי לא תקין. כדי לפתור את הבעיה, צריך לתקן את המדיניות ולנסות שוב.
• ההרשאה נדחתה: אין לכם הרשאה להריץ סימולציה. כדי לפתור את הבעיה, צריך לוודא שקיבלתם את התפקידים הנדרשים ולנסות שוב.

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

• מידע נוסף על אילוצים
• מידע נוסף על אפשרויות נוספות להתאמה אישית של המדיניות
• איך מגדירים מדיניות ארגונית על סמך תגים