במאמר הזה מוסבר איך אדמינים יכולים לראות, ליצור ולנהל כללי מדיניות בהתאמה אישית של הארגון. כללי מדיניות בהתאמה אישית מאפשרים לכם להתאים אישית את השליטה בשדות הספציפיים שמוגבלים על ידי כללי המדיניות של הארגון.
לפני שמתחילים
- למידע נוסף על כללי המדיניות והאילוצים של הארגון ואיך הם פועלים, קראו את המבוא לשירות מדיניות הארגון.
התפקידים הנדרשים
כדי לקבל את ההרשאות שדרושות לניהול מדיניות הארגון, בקשו מהאדמין לתת לכם את התפקידים הבאים ב-IAM ברמת הארגון:
- אדמין של מדיניות הארגון (
roles/orgpolicy.policyAdmin) -
כדי להפעיל ממשקי API של Google Cloud :
צרכן של שימוש בשירות (
roles/serviceusage.serviceUsageConsumer)
להסבר על מתן תפקידים, ראו איך מנהלים את הגישה ברמת הפרויקט, התיקייה והארגון.
יכול להיות שאפשר לקבל את ההרשאות הנדרשות גם באמצעות תפקידים בהתאמה אישית או תפקידים מוגדרים מראש.
כדי להקצות את הניהול של מדיניות הארגון, אפשר להוסיף תנאי IAM לקישור התפקיד של אדמין מדיניות הארגון. כדי לשלוט במשאבים שבהם חשבון משתמש יכול לנהל את כללי המדיניות של הארגון, אתם יכולים להתנות את קישור התפקיד בתג מסוים. מידע נוסף זמין במאמר יצירת מדיניות ארגון.
אילוצים בהתאמה אישית
אילוץ בהתאמה אישית מוגדר בקובץ YAML, שבו מצוינים המשאבים, השיטות, התנאים והפעולות שכפופים לאילוץ. ההתנהגות של אילוצים בהתאמה אישית והפרמטרים הנתמכים הם ספציפיים לכל שירות. התנאים לאילוצים מותאמים אישית מוגדרים באמצעות Common Expression Language (CEL).
הגדרת אילוץ בהתאמה אישית
אפשר ליצור אילוץ בהתאמה אישית ולהגדיר אותו לשימוש במדיניות הארגון באמצעות מסוף Google Cloud או Google Cloud CLI.
המסוף
כדי ליצור אילוץ בהתאמה אישית:
- במסוף Google Cloud , נכנסים לדף מדיניות הארגון.
- בכלי לבחירת פרויקטים, בוחרים את הפרויקט שרוצים להגדיר לו את מדיניות הארגון.
- לוחצים על Custom constraint.
- בתיבה Display name, מזינים שם לאילוץ שיהיה קריא לאנשים. השם הזה מופיע בהודעות שגיאה ואפשר להשתמש בו לזיהוי ולניפוי באגים. אל תשתמשו בפרטים אישיים מזהים (PII) או במידע רגיש בשמות לתצוגה, כי השם הזה עלול להיחשף בהודעות שגיאה. השדה הזה יכול להכיל עד 200 תווים.
-
בתיבה Constraint ID, מזינים את המזהה שרוצים לתת לאילוץ החדש בהתאמה אישית. אילוץ בהתאמה אישית יכול להכיל רק אותיות (כולל אותיות רישיות וקטנות) או מספרים, לדוגמה
custom.disableGkeAutoUpgrade. השדה הזה יכול להכיל עד 70 תווים, לא כולל הקידומת (custom.), לדוגמה,organizations/123456789/customConstraints/custom. אל תכללו פרטים אישיים מזהים או מידע רגיש במזהה האילוץ, כי הם עלולים להיחשף בהודעות שגיאה. - בתיבה Description, מזינים תיאור קריא לאנשים של האילוץ. התיאור הזה משמש כהודעת שגיאה כשיש הפרה של המדיניות. ציינו פרטים על הסיבה להפרת המדיניות ואיך לפתור את הבעיה. אל תכללו פרטים אישיים מזהים או מידע רגיש בתיאור, כי הם עלולים להיחשף בהודעות שגיאה. השדה הזה יכול להכיל עד 2,000 תווים.
-
בתיבה Resource type, בוחרים את השם של משאב ה- Google Cloud REST שמכיל את האובייקט והשדה שרוצים להגביל, לדוגמה
container.googleapis.com/Cluster. רוב סוגי המשאבים תומכים בעד 20 אילוצים בהתאמה אישית. אם תנסו ליצור יותר אילוצים בהתאמה אישית, הפעולה תיכשל. -
אפשר לאכוף את האילוץ הזה רק ב-REST
CREATE. - כדי להגדיר תנאי, לוחצים על עריכת התנאי.
-
בחלונית Add condition, יוצרים תנאי CEL שמתייחס למשאב שירות נתמך, לדוגמה
resource.management.autoUpgrade == false. השדה הזה יכול להכיל עד 1,000 תווים. לפרטים על השימוש ב-CEL, קראו את המאמר Common Expression Language. מידע נוסף על משאבי השירות שבהם אפשר להשתמש באילוצים המותאמים אישית מופיע במאמר שירותים שנתמכים באילוצים מותאמים אישית. - לוחצים על Save.
- בקטע Action, בוחרים אם לאשר או לדחות את השיטה שנבדקה אם התנאי מתקיים.
- לוחצים על Create constraint.
כדי לראות את השיטות הנתמכות לכל שירות, חפשו את השירות במאמר שירותים שתומכים באילוצים בהתאמה אישית.
פעולת הדחייה פירושה שהפעולה ליצירה או לעדכון של המשאב נחסמת אם התנאי מקבל את הערך true.
פעולת ההרשאה מאפשרת ליצור או לעדכן את המשאב רק אם התנאי מתקיים. כל מקרה אחר, מלבד אלה שרשומים במפורש בתנאי, נחסם.
אחרי שמזינים ערך בכל שדה, הגדרת ה-YAML המקבילה לאילוץ המותאם אישית הזה מופיעה בצד שמאל.
gcloud
- כדי ליצור אילוץ בהתאמה אישית, יוצרים קובץ YAML בפורמט הבא:
-
ORGANIZATION_ID: מזהה הארגון, למשל123456789. -
CONSTRAINT_NAME: השם שרוצים לתת לאילוץ החדש בהתאמה אישית. אילוץ בהתאמה אישית יכול להכיל רק אותיות (כולל אותיות רישיות וקטנות) או מספרים, לדוגמה,custom.disableGkeAutoUpgrade. השדה הזה יכול להכיל עד 70 תווים, לא כולל הקידומת (custom.) – לדוגמה,organizations/123456789/customConstraints/custom. אל תכללו פרטים אישיים מזהים (PII) או מידע רגיש במזהה האילוץ, כי הם עלולים להיחשף בהודעות שגיאה. -
RESOURCE_NAME: השם המלא של המשאב ב- Google Cloudשמכיל את האובייקט והשדה שרוצים להגביל. לדוגמה,container.googleapis.com/NodePool. רוב סוגי המשאבים תומכים בעד 20 אילוצים בהתאמה אישית. אם תנסו ליצור יותר אילוצים בהתאמה אישית, הפעולה תיכשל. -
methodTypes: שיטות ה-REST שעליהן נאכף האילוץ. הערך יכול להיות רקCREATE. -
CONDITION: תנאי CEL שנכתב כנגד ייצוג של משאב שירות נתמך. השדה הזה יכול להכיל עד 1,000 תווים. לדוגמה,"resource.management.autoUpgrade == false". -
ACTION: הפעולה שצריך לבצע אם התנאיconditionמתקיים. הערכים האפשריים הםALLOWו-DENY. -
DISPLAY_NAME: שם קריא לאנשים של האילוץ. השם הזה מופיע בהודעות שגיאה ואפשר להשתמש בו לזיהוי ולניפוי באגים. אל תשתמשו בפרטים אישיים מזהים (PII) או במידע רגיש בשמות המוצגים, כי השם הזה עלול להיחשף בהודעות שגיאה. השדה הזה יכול להכיל עד 200 תווים. -
DESCRIPTION: תיאור ידידותי למשתמש של האילוץ, שיוצג כהודעת שגיאה במקרה של הפרת המדיניות. השדה הזה יכול להכיל עד 2,000 תווים. -
אחרי שיוצרים את קובץ ה-YAML לאילוץ חדש בהתאמה אישית, צריך להגדיר אותו כדי שיהיה זמין למדיניות הארגון. כדי להגדיר אילוץ בהתאמה אישית, משתמשים בפקודה
gcloud org-policies set-custom-constraint: -
כדי לוודא שהאילוץ המותאם אישית קיים, משתמשים בפקודה
gcloud org-policies list-custom-constraints:
name: organizations/ORGANIZATION_ID/customConstraints/CONSTRAINT_NAME resourceTypes: RESOURCE_NAME methodTypes: - CREATE condition: "CONDITION" actionType: ACTION displayName: DISPLAY_NAME description: DESCRIPTION
מחליפים את מה שכתוב בשדות הבאים:
כדי לראות את השיטות הנתמכות בכל שירות, חפשו את השירות במאמר שירותים שתומכים באילוצים בהתאמה אישית.
הפעולה allow פירושה שאם התנאי מקבל את הערך true, מותר ליצור או לעדכן את המשאב. זה גם אומר שכל מקרה אחר, מלבד המקרה שמופיע במפורש בתנאי, חסום.
פעולת הדחייה פירושה שאם התנאי מקבל את הערך True, הפעולה ליצירה או לעדכון של המשאב נחסמת.
gcloud org-policies set-custom-constraint CONSTRAINT_PATH
מחליפים את CONSTRAINT_PATH בנתיב המלא לקובץ האילוץ בהתאמה אישית. לדוגמה, /home/user/customconstraint.yaml.
בסיום הפעולה, האילוצים המותאמים אישית יהיו זמינים כמדיניות של הארגון ברשימת Google Cloud כללי המדיניות של הארגון.
gcloud org-policies list-custom-constraints --organization=ORGANIZATION_ID
מחליפים את ORGANIZATION_ID במזהה של משאב הארגון.
למידע נוסף, קראו את המאמר הצגת מדיניות הארגון.
עדכון של אילוץ בהתאמה אישית
כדי לעדכן אילוץ מותאם אישית, אפשר לערוך את האילוץ במסוףGoogle Cloud או ליצור קובץ YAML חדש ולהשתמש שוב בפקודה set-custom-constraint ב-CLI של gcloud. אין ניהול גרסאות של אילוצים בהתאמה אישית, ולכן הפעולה הזו מחליפה את האילוץ הקיים בהתאמה אישית. אם האילוץ המותאם אישית כבר נאכף, האילוץ המותאם אישית המעודכן נכנס לתוקף באופן מיידי.
המסוף
במסוף Google Cloud , נכנסים לדף מדיניות הארגון.
לוחצים על הכלי לבחירת פרויקטים בחלק העליון של הדף.
בכלי לבחירת פרויקטים, בוחרים את המשאב שרוצים לעדכן את מדיניות הארגון שלו.
בוחרים את כלל מדיניות של הארגון שרוצים לערוך מהרשימה שבדף מדיניות הארגון כדי לפתוח את דף הפרטים Policy details של אותו כלל מדיניות של הארגון.
לוחצים על Edit constraint.
משנים את השם המוצג, התיאור, שיטת האכיפה, התנאי והפעולה. אי אפשר לשנות את מזהה האילוץ או את סוג המשאב אחרי שיוצרים את האילוץ.
לוחצים על שמירת השינויים.
gcloud
מריצים את הפקודה
gcloud org-policies describe-custom-constraintכדי לקבל את האילוץ הנוכחי בהתאמה אישית.gcloud org-policies describe-custom-constraint CONSTRAINT_NAME \ --organization=ORGANIZATION_ID \ --format=FORMAT > PATHמחליפים את מה שכתוב בשדות הבאים:
ORGANIZATION_ID: מזהה הארגון, למשל123456789.
CONSTRAINT_NAME: השם של האילוץ בהתאמה אישית, לדוגמהcustom.disableGkeAutoUpgrade.
FORMAT: הפורמט של מדיניות ההרשאות. אפשר להשתמש ב-jsonאו ב-yaml.
PATH: הנתיב לקובץ הפלט החדש של האילוץ המותאם אישית.
משנים את העותק המקומי של האילוץ המותאם אישית בהתאם לשינויים שרוצים לבצע בשם המוצג, בתיאור, בשיטת האכיפה, בתנאי ובפעולה. אי אפשר לשנות את מזהה האילוץ או את סוג המשאב אחרי שיוצרים את האילוץ.
אחרי שמעדכנים את קובץ ה-YAML של האילוץ המותאם אישית, מגדירים אותו כדי שיהיה זמין למדיניות הארגון. כדי להגדיר אילוץ בהתאמה אישית, משתמשים בפקודה
gcloud org-policies set-custom-constraint:gcloud org-policies set-custom-constraint CONSTRAINT_PATHמחליפים את
CONSTRAINT_PATHבנתיב המלא לקובץ האילוץ בהתאמה אישית.
בסיום העדכון, האילוץ המותאם אישית המעודכן יהיה זמין למדיניות הארגון. אם האילוץ המקורי כבר נאכף, האילוץ המעודכן נכנס לתוקף באופן מיידי.
מחיקת אילוץ בהתאמה אישית
אפשר למחוק אילוץ מותאם אישית באמצעות מסוף Google Cloud או Google Cloud CLI.
המסוף
במסוף Google Cloud , נכנסים לדף מדיניות הארגון.
לוחצים על הכלי לבחירת פרויקטים בחלק העליון של הדף.
בכלי לבחירת פרויקטים, בוחרים את המשאב שרוצים למחוק את מדיניות הארגון שלו.
בוחרים את האילוץ שרוצים למחוק מהרשימה בדף מדיניות הארגון כדי לפתוח את הדף Policy details של אותו אילוץ.
לוחצים על מחיקה.
כדי לאשר את מחיקת האילוץ, לוחצים על מחיקה.
gcloud
כדי למחוק אילוץ בהתאמה אישית, משתמשים בפקודה org-policies delete-custom-constraint ב-CLI של gcloud:
gcloud org-policies delete-custom-constraint custom.CONSTRAINT_NAME \
--organization=ORGANIZATION_ID
מחליפים את מה שכתוב בשדות הבאים:
ORGANIZATION_ID: מזהה הארגון, למשל123456789.
CONSTRAINT_NAME: השם של האילוץ בהתאמה אישית. לדוגמה,custom.disableGkeAutoUpgrade.
הפלט אמור להיראות כך:
Deleted custom constraint [organizations/123456789/customConstraints/custom.disableGkeAutoUpgrade]
אם מוחקים אילוץ בהתאמה אישית, כל כללי המדיניות שנוצרו באמצעות האילוץ הזה נמחקים. השם של האילוץ המותאם אישית שנמחק יהיה זמין לשימוש תוך כמה דקות.
בדיקה וניתוח של שינויים במדיניות הארגון
מומלץ לבדוק ולהריץ הרצה (dry-run) של כל השינויים במדיניות הארגון כדי להבין איך השינויים משפיעים על הסביבה.
סימולטור המדיניות של מדיניות הארגון עוזר לכם להבין את ההשפעה של אילוץ ושל מדיניות הארגון על הסביבה הנוכחית שלכם. בעזרת הכלי הזה אתם יכולים לבדוק את כל הגדרות המשאבים כדי לראות איפה מתרחשות הפרות, לפני שהמדיניות נאכפת בסביבת הייצור. הוראות מפורטות מופיעות במאמר בדיקת שינויים במדיניות הארגון באמצעות סימולטור המדיניות.
אחרי שתבינו את ההשפעה הנוכחית, תוכלו ליצור מדיניות ארגונית במצב פרימטר לבדיקות כדי להבין את ההשפעה ואת ההפרות הפוטנציאליות של המדיניות ב-30 הימים הבאים. מדיניות ארגונית במצב פרימטר לבדיקות היא סוג של מדיניות ארגונית שבה הפרות של המדיניות נרשמות ביומן הביקורת, אבל הפעולות שמפירות את המדיניות לא נדחות. אפשר ליצור מדיניות ארגונית במצב פרימטר לבדיקות מאילוץ בהתאמה אישית באמצעות מסוף Google Cloud או Google Cloud CLI. הוראות מפורטות מופיעות במאמר בדיקת כללי מדיניות של הארגון.
אכיפה של מדיניות ארגונית בהתאמה אישית
אחרי שמגדירים אילוץ בהתאמה אישית, הוא פועל באופן זהה לאילוצים בוליאניים מוגדרים מראש. Google Cloud בודק קודם את האילוצים בהתאמה אישית כשהוא מעריך אם בקשת משתמש מותרת. אם אחת ממדיניות הארגון בהתאמה אישית דוחה את הבקשה, הבקשה נדחית. לאחר מכן, Google Cloudבודק אם יש כללי מדיניות מוגדרים מראש של הארגון שנאכפים על המשאב הזה.
כדי לאכוף אילוץ, אתם יכולים ליצור מדיניות ארגון שמפנה אליו, ואז להחיל את מדיניות הארגון על משאב ב- Google Cloud .המסוף
- במסוף Google Cloud , נכנסים לדף מדיניות הארגון.
- בכלי לבחירת פרויקטים, בוחרים את הפרויקט שרוצים להגדיר לו את מדיניות הארגון.
- ברשימה שבדף מדיניות הארגון, בוחרים את האילוץ כדי להציג את הדף Policy details של אותו אילוץ.
- כדי להגדיר את מדיניות הארגון למשאב הזה, לוחצים על ניהול המדיניות.
- בדף עריכת המדיניות, בוחרים באפשרות במקום המדיניות של המשאב הראשי.
- לוחצים על Add a rule.
- בקטע Enforcement, בוחרים אם לאכוף את מדיניות הארגון הזו או לא.
- אופציונלי: כדי להוסיף תנאי למדיניות הארגון על סמך תג, לוחצים על Add condition. שימו לב: אם מוסיפים כלל מותנה למדיניות הארגון, צריך להוסיף לפחות כלל אחד לא מותנה, אחרת אי אפשר לשמור את המדיניות. מידע נוסף מופיע במאמר הגדרת ההיקף של מדיניות הארגון באמצעות תגים.
- לוחצים על בדיקת השינויים כדי לדמות את ההשפעה של מדיניות הארגון. למידע נוסף, קראו את המאמר בדיקת שינויים במדיניות הארגון באמצעות סימולטור המדיניות.
- כדי לאכוף את מדיניות הארגון במצב פרימטר לבדיקות, לוחצים על הגדרת המדיניות להרצת בדיקה. למידע נוסף, קראו את המאמר בדיקת כללי מדיניות של הארגון.
- אחרי שמוודאים שמדיניות הארגון במצב פרימטר לבדיקות פועלת כמו שצריך, לוחצים על Set policy כדי להגדיר את המדיניות הפעילה.
gcloud
- כדי ליצור מדיניות ארגונית עם כללים בוליאניים, יוצרים קובץ YAML של מדיניות שמפנה לאילוץ:
-
PROJECT_ID: הפרויקט שבו רוצים לאכוף את האילוץ. -
CONSTRAINT_NAME: השם שהגדרתם לאילוץ המותאם אישית. לדוגמה,custom.disableGkeAutoUpgrade. -
כדי לאכוף את מדיניות הארגון במצב פרימטר לבדיקות, מריצים את הפקודה הבאה עם הדגל
dryRunSpec: -
אחרי שמוודאים שמדיניות הארגון במצב פרימטר לבדיקות פועלת כמצופה, מגדירים את המדיניות הפעילה באמצעות הפקודה
org-policies set-policyוהדגלspec:
name: projects/PROJECT_ID/policies/CONSTRAINT_NAME spec: rules: - enforce: true dryRunSpec: rules: - enforce: true
מחליפים את מה שכתוב בשדות הבאים:
gcloud org-policies set-policy POLICY_PATH --update-mask=dryRunSpec
מחליפים את POLICY_PATH בנתיב המלא לקובץ ה-YAML של מדיניות הארגון. המדיניות תיכנס לתוקף תוך 15 דקות לכל היותר.
gcloud org-policies set-policy POLICY_PATH --update-mask=spec
מחליפים את POLICY_PATH בנתיב המלא לקובץ ה-YAML של מדיניות הארגון. המדיניות תיכנס לתוקף תוך 15 דקות לכל היותר.
אילוץ לדוגמה
אתם יכולים להגדיר אילוצים בהתאמה אישית, בדומה לאילוצים המוגדרים מראש ש-Google מספקת. קובץ YAML טיפוסי של אילוץ בהתאמה אישית נראה בערך כך:
name: organizations/1234567890123/customConstraints/custom.disableGkeAutoUpgrade
resourceTypes: container.googleapis.com/NodePool
methodTypes:
- CREATE
- UPDATE
condition: "resource.management.autoUpgrade == false"
actionType: ALLOW
displayName: Disable GKE auto upgrade
description: Only allow GKE NodePool resource to be created or updated if
AutoUpgrade is not enabled where this custom constraint is enforced.
Common Expression Language
שירות מדיניות הארגון משתמש ב-Common Expression Language (CEL) כדי להעריך תנאים באילוצים בהתאמה אישית. CEL היא שפה בקוד פתוח שאינה שלמה לפי טיורינג, שמטמיעה סמנטיקה נפוצה להערכת ביטויים.
כל שירות שתומך באילוצים בהתאמה אישית מאפשר להשתמש בקבוצה מסוימת של משאבים ובשדות של המשאבים האלה. השדות הזמינים הם בעלי טיפוסים מוגדרים, ואפשר להפנות אליהם ישירות באמצעות אילוצים בהתאמה אישית.
אתם יכולים ליצור תנאי CEL שמתייחסים לשדות של משאבי שירות, בהתאם לסוג השדה. שירות מדיניות הארגון תומך בקבוצת משנה של סוגי נתונים, ביטויים ופקודות מאקרו של CEL. בקטעים הבאים מפורטים סוגי הנתונים הזמינים, וביטויים ופקודות מאקרו נפוצים שפועלים איתם.
במאמר שירותים שנתמכים באילוצים בהתאמה אישית מפורט אילו ביטויים ופקודות מאקרו זמינים לכל שירות.
בדוגמה הבאה ב-JSON מוצגים כל סוגי השדות האפשריים שאפשר להפנות אליהם באמצעות אילוצים בהתאמה אישית:
{
"integerValue": 1,
"stringValue": "A text string",
"booleanValue": true,
"nestedValue": {
"nestedStringValue": "Another text string"
},
"listValue": ["foo", "bar"],
"mapValue": {
"costCenter": "123"
}
}
בכל ביטוי CEL, האילוץ המותאם אישית נאכף כשהתנאי מקבל את הערך true. אפשר לשלב ביטויים עם and (&&) ו-or (||) כדי ליצור שאילתה מורכבת. כשיוצרים את קובץ ה-YAML או ה-JSON לאילוץ בהתאמה אישית, צריך להקיף את השאילתה המלאה במירכאות כפולות (").
מספר שלם
שדות של מספרים שלמים, כמו integerValue בדוגמה הקודמת, מאפשרים להשתמש באופרטורים של השוואה בתנאים. לדוגמה:
resource.integerValue == 1
resource.integerValue > 5
resource.integerValue < 10
String
אפשר להעריך שדות מחרוזת, כמו stringValue בדוגמה הקודמת, באמצעות מחרוזת מילולית, ביטוי רגולרי או ביטוי CEL. לדוגמה:
resource.stringValue == "abc"
// stringValue is exactly "abc".
resource.stringValue.matches("dev$")
// stringValue matches a regular expression, which specifies the string ends
// with the word "dev".
resource.stringValue.startsWith("startValue")
// stringValue starts with "startValue".
resource.stringValue.endsWith("endValue")
// stringValue ends with "endValue".
resource.stringValue.contains("fooBar")
// stringValue contains "fooBar".
שדות בתצוגת עץ, כמו nestedStringValue בדוגמה הקודמת, חייבים להפנות לנתיב המלא. לדוגמה:
resource.nestedValue.nestedStringValue == "foo"
// nestedValue contains the object nestedStringValue, which has a value of "foo".
בוליאני
שדות בוליאניים, כמו booleanValue בדוגמה הקודמת, מכילים ערך בוליאני, שהוא true או false.
רשימה
אפשר להעריך שדות של רשימות, כמו listValue בדוגמה הקודמת, לפי גודל הרשימה, התוכן של הרשימה והשאלה אם רכיב מסוים קיים במקום כלשהו ברשימה.
לדוגמה:
resource.listValue.size() >= 1 && resource.listValue[0] == "bar"
// listValue has size greater than or equal to one, and the first element is "bar".
resource.listValue.exists(value, value == "foo")
// listValue has at least one element that is exactly "foo".
resource.listValue.all(value, value.contains("foo"))
// listValue is a list of values that are all exactly "foo".
מפה
שדות מפה, כמו mapValue בדוגמה הקודמת, הם צמדי מפתח/ערך שאפשר להעריך על סמך הקיום והערך של רכיבים מסוימים.
לדוגמה:
has(resource.mapValue.foo) && resource.mapValue.foo == "bar"
// mapValue contains the key "foo", and that key has the value "bar".
פתרון בעיות באילוצים בהתאמה אישית
בקטעים הבאים מתוארות בעיות נפוצות שקשורות ליצירת אילוצים בהתאמה אישית, ומוצגים פתרונות עקיפים לבעיות האלה.
שגיאות שקשורות לסוג השיטה
אילוצים בהתאמה אישית נוצרים עם רשימה של שיטות לאכיפה, בדרך כלל CREATE או גם CREATE וגם UPDATE. אם תציינו סוג של שיטה שלא נתמך על ידי משאב, כמו השיטה UPDATE למשאבי תמונות של Compute Engine, לא תוכלו לשמור את האילוץ המותאם אישית.
התגים לא הוערכו
אפשר להשתמש בתגים של משאבים ברמת הארגון, התיקייה או הפרויקט באילוצים בהתאמה אישית. למידע נוסף על השירותים שתומכים בתגים, קראו את המסמכים הספציפיים לשירות.
הגבלות בין שירותים שונים
בחלק מהשירותים, כמו Compute Engine, יש מספר גדול של משאבים קשורים. הודעת השגיאה על הפרת מדיניות ארגונית בהתאמה אישית מוצגת כשההפרה מתרחשת, גם אם האילוץ בהתאמה אישית הוא לשירות אחר.
לדוגמה, יכול להיות שאילוץ בהתאמה אישית על משאבים של Compute Engine יחסום פעולה של Managed Service for Apache Spark.
פתרון בעיות שקשורות לשגיאות ב-CEL
שירות מדיניות הארגון מקמפל ומאמת את התנאים שאתם יוצרים, ומחזיר שגיאה אם התנאי לא נכון מבחינה תחבירית. אם אתם לא מצליחים ליצור או לשמור אילוץ בהתאמה אישית, כנראה שיש שגיאה בתחביר ה-CEL שצריך לתקן.
במסוף Google Cloud , שגיאות תחביר CEL לא חוקיות יסומנו בסמל Error. אם מדגישים את הסמל הזה, מוצג הסבר קצר עם מידע נוסף על שגיאת התחביר.
יכול להיות שתנאים מסוימים יעברו הידור אבל יגרמו לשגיאה כש- Google Cloudינסה לאכוף את האילוצים. לדוגמה, אם מגדירים אילוץ עם תנאי שמנסה לגשת לאינדקס רשימה או למפתח מפה שלא קיימים, האילוץ נכשל ומחזיר שגיאה בזמן האכיפה, וחוסם כל ניסיון ליצור את המשאב.
בקטעים הבאים מתוארות שגיאות נפוצות ב-CEL ודרכים אפשריות לעקיפת הבעיה.
ביטוי לא חוקי או חוסר התאמה בין סוגים
אם תנסו להגדיר אילוץ בהתאמה אישית עם תנאי שנוצר עם ביטויים לא חוקיים או אי-התאמות בסוג, תופיע הודעת שגיאה. לדוגמה, נניח שיש לכם את האילוץ הלא תקין הבא בהתאמה אישית, שמשווה בין מחרוזת למספר שלם:
name: organizations/1234567890123/customConstraints/custom.badConfig
resourceTypes: dataproc.googleapis.com/Cluster
methodTypes:
- CREATE
- UPDATE
condition: "resource.config.masterConfig.numInstances == 'mismatch'"
actionType: ALLOW
displayName: Number of instances is a string
description: Demonstrate that type mismatches cause an error.
אם תנסו להגדיר את האילוץ הזה באמצעות Google Cloud CLI, תופיע הודעת שגיאה:
ERROR: (gcloud.org-policies.set-custom-constraint) INVALID_ARGUMENT: Custom constraint condition [resource.config.masterConfig.numInstances == "mismatch"] is invalid. Error: ERROR: <input>:1:15: found no matching overload for '_==_' applied to '(int, string)' (candidates: (%A0, %A0))
| resource.config.masterConfig.numInstances == "mismatch"
| ..........................................^.
במסוף Google Cloud , שגיאות תחביר CEL לא חוקיות יסומנו בסמל Error. אם מדגישים את הסמל הזה, מוצג הסבר קצר עם מידע נוסף על שגיאת התחביר.
שירות מדיניות הארגון אוסף ומאמת את התנאים שאתם יוצרים, ומחזיר שגיאה אם התנאי לא נכון מבחינה תחבירית. עם זאת, יכול להיות שתנאים מסוימים יעברו הידור אבל יחזירו שגיאה כש- Google Cloud ינסה לאכוף את האילוצים. לדוגמה, אם מגדירים אילוץ עם תנאי שמנסה לגשת לאינדקס רשימה או למפתח מפה שלא קיימים, האילוץ נכשל ומחזיר שגיאה בזמן האכיפה, וחוסם כל ניסיון ליצור את המשאב.
כשיוצרים תנאים שתלויים ברכיבים של רשימה או מפה, מומלץ להתחיל את התנאי בבדיקה שמוודאת שהתנאי תקין בכל המקרים. לדוגמה, בודקים את list.size() לפני שמתייחסים לרכיב מסוים ברשימה, או משתמשים ב-has() לפני שמתייחסים לרכיב במפה.
שירותים נתמכים
כל שירות מגדיר את קבוצת השדות של האילוצים המותאמים אישית, שבהם אפשר להשתמש כדי לאכוף את מדיניות הארגון על משאבי השירות. ברשימה הזו מפורטים השירותים שתומכים באילוצים בהתאמה אישית.
למידע נוסף על הגדרת סורק מדיניות הארגון, ראו ממצאי פגיעויות במדיניות הארגון.
אכיפת תגי חובה במשאבים
אפשר לאכוף תגי חובה על משאבים באמצעות מדיניות ארגונית בהתאמה אישית. כשאתם אוכפים תגי חובה, אתם יכולים ליצור רק משאבים שתואמים למדיניות התיוג של הארגון. כלומר, המשאבים מקושרים לערכי התגים של מפתחות תגי החובה שצוינו במדיניות. מידע נוסף זמין במאמר הגדרת אילוץ בהתאמה אישית לאכיפת תגים.
המאמרים הבאים
- מידע מעמיק על אילוצים
- מידע על אפשרויות נוספות להתאמה אישית של כללי המדיניות
- איך מגדירים את מדיניות הארגון על סמך תגים
- לעיון בספריית מדיניות הארגון בהתאמה אישית ב-GitHub
- איך מאמתים ומנטרים את מדיניות הארגון באמצעות Config Validator