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

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

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

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

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

    gcloud config set project PROJECT_ID

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

  • מפעילים את Policy Simulator ואת ממשקי ה-API של מנהל המשאבים, אם הם עדיין לא מופעלים.

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

    כדי להפעיל ממשקי API, נדרשת ההרשאה serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד 'בעלים' (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד 'אדמין בממשק Service Usage' (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. נכנסים לדף Organization policies במסוף Google Cloud .

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

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

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

    • כדי לבדוק אילוץ חדש בהתאמה אישית, לוחצים על אילוץ בהתאמה אישית.

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

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

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

    2. בתיבה Constraint ID, מקלידים את השם שרוצים לתת לאילוץ המותאם אישית החדש. אילוץ מותאם אישית חייב להתחיל ב-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.

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

אפשר לראות את התוצאות גם בדף Simulation history במסוף 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. נכנסים לדף Organization policies במסוף 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 של מדיניות הארגון.

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

    אפשר לראות את התוצאות גם בדף Simulation history במסוף 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 שעות מושבתת אוטומטית. כדי לפתור את הבעיה, נסו להריץ את הסימולציה שוב או להקטין את הגודל שלה.
  • בניית הסימולציה לא תקינה: מדיניות הארגון המוצעת לא תקינה. לדוגמה, למדיניות המוצעת יש ביטוי תנאי לא תקין. כדי לפתור את הבעיה, צריך לתקן את המדיניות ולנסות שוב.
  • ההרשאה נדחתה: אין לכם הרשאה להריץ סימולציה. כדי לפתור את הבעיה, צריך לוודא שקיבלתם את התפקידים הנדרשים ולנסות שוב.

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