אילוצים מנוהלים

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

אפשר לזהות אילוצים מנוהלים לפי הקידומת compute.managed.*, והם מחליפים באופן ישיר את האילוצים הקודמים compute.*.

יתרונות

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

העברת מדיניות בירושה

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

תמחור

שירות מדיניות הארגון, כולל מדיניות ארגון מוגדרת מראש (מהדור הקודם), מנוהלת ומותאמת אישית, מוצע ללא תשלום.

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

  • אם עדיין לא עשיתם את זה, תצטרכו להגדיר אימות. אימות הוא תהליך שבו מאמתים את הזהות שלכם כדי לקבל גישה לממשקי API ולשירותים של Google Cloud . כדי להריץ קוד או דוגמאות מסביבת פיתוח מקומית, אפשר לבצע אימות ל-Compute Engine באחת מהדרכים הבאות:

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

    המסוף

    כשמשתמשים במסוף Google Cloud כדי לגשת לשירותים Google Cloud ולממשקי ה-API, לא צריך להגדיר אימות.

    gcloud

    1. התקינו את ה-CLI של Google Cloud. אחר כך, אתחלו את ה-CLI של Google Cloud באמצעות הפקודה הבאה: 

      gcloud init

      אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.

  • הגדרת אזור ותחום כברירת מחדל

    • REST

    כדי להשתמש בסביבת פיתוח מקומית בדוגמאות של API בארכיטקטורת REST שבדף הזה, צריך להשתמש בפרטי הכניסה שאתם נותנים ל-CLI של gcloud.

      התקינו את ה-CLI של Google Cloud.

      אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.

    מידע נוסף מופיע במאמר אימות לשימוש ב-REST במסמכי האימות של Google Cloud .

  • חשוב לוודא שאתם יודעים מהו מזהה הארגון שלכם.
  • אם עוד לא עשיתם זאת, מתקינים את ה-CLI של gcloud ומאתחלים אותו באמצעות הפקודה gcloud init.
  • מגדירים פרויקט ברירת מחדל לבדיקה.

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

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

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

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

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

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

  • orgpolicy.constraints.list
  • orgpolicy.policies.create
  • orgpolicy.policies.delete
  • orgpolicy.policies.list
  • orgpolicy.policies.update
  • orgpolicy.policy.get
  • orgpolicy.policy.set
  • כדי לבדוק את האילוצים:
    • ‫compute.instances.create בפרויקט
    • כדי להשתמש באימג' בהתאמה אישית ליצירת המכונה הווירטואלית (VM): compute.images.useReadOnly בקובץ אימג'
    • כדי להשתמש ב-snapshot ליצירת המכונה הווירטואלית: compute.snapshots.useReadOnly בקובץ ה-snapshot
    • כדי להשתמש בתבנית של הגדרות מכונה ליצירת המכונה הווירטואלית: compute.instanceTemplates.useReadOnly בתבנית של הגדרות המכונה
    • כדי להקצות רשת מדור קודם למכונה הווירטואלית: compute.networks.use בפרויקט
    • כדי לציין כתובת IP סטטית למכונה הווירטואלית: compute.addresses.use בפרויקט
    • כדי להקצות כתובת IP חיצונית למכונה הווירטואלית כשמשתמשים ברשת מדור קודם: compute.networks.useExternalIp בפרויקט
    • כדי לציין רשת משנה למכונה הווירטואלית: compute.subnetworks.use בפרויקט או ברשת המשנה שנבחרה
    • כדי להקצות כתובת IP חיצונית למכונה הווירטואלית כשמשתמשים ברשת VPC: compute.subnetworks.useExternalIp בפרויקט או ברשת המשנה שנבחרה
    • כדי להגדיר מטא-נתונים של המכונה הווירטואלית למכונה הווירטואלית: compute.instances.setMetadata בפרויקט
    • כדי להגדיר תגים למכונה הווירטואלית: compute.instances.setTags במכונה הווירטואלית
    • כדי להגדיר תוויות למכונה הווירטואלית: compute.instances.setLabels במכונה הווירטואלית
    • כדי להגדיר חשבון שירות לשימוש של המכונה הווירטואלית: compute.instances.setServiceAccount במכונה הווירטואלית
    • כדי ליצור דיסק חדש למכונה הווירטואלית: compute.disks.create בפרויקט
    • כדי לצרף דיסק קיים במצב קריאה-בלבד או במצב קריאה וכתיבה: compute.disks.use בדיסק
    • כדי לצרף דיסק קיים במצב קריאה-בלבד: compute.disks.useReadOnly בדיסק

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

אילוצים מנוהלים זמינים

אילוצי מדיניות הארגון המנוהלים הבאים זמינים ב-Compute Engine:

מגבלה תיאור
הגדרות ההצפנה המותרות של צירוף ל-VLAN

האילוץ הזה מגדיר את הגדרות ההצפנה המותרות לצירופים חדשים ל-VLAN.
כברירת מחדל, ל-VLAN Attachments מותר להשתמש בכל הגדרות ההצפנה. ‫
מגדירים את הערך המותר כ-IPSEC כדי לאכוף יצירה של קבצים מצורפים של VLAN מוצפנים בלבד.

constraints/compute.managed.allowedVlanAttachmentEncryption
חסימה של תכונות בגרסת טרום-השקה (Preview) של Compute Engine

ההגבלה הזו חוסמת כברירת מחדל תכונות בגרסת טרום-השקה של Compute Engine. אתם יכולים לאשר באופן מפורש תכונות ספציפיות בגרסת טרום-השקה על ידי הוספתן לרשימה allowedPreviewFeatures. אפשרות אחרת היא להשבית את ההגבלה (להגדיר אותה כלא נאכפת) כדי לאפשר את כל תכונות התצוגה המקדימה. אחרי שמאשרים תכונת תצוגה מקדימה (באמצעות רשימת ההיתרים או השבתת האילוץ), צריך גם להפעיל אותה בפרויקט כדי שאפשר יהיה להשתמש בה. אכיפה של ההגבלה בשלב מאוחר יותר לא משנה את הסטטוס של תכונות ספציפיות בגרסת טרום-השקה שכבר הוגדרו. המגבלה הזו חלה רק על תכונות של Compute Alpha API.

constraints/compute.managed.blockPreviewFeatures
חסימה של מפתחות SSH ברמת הפרויקט

תצוגה מקדימה: האילוץ הזה מונע את ההגדרה של מפתח המטא-נתונים block-project-ssh-keys לערך false ברמת הפרויקט, ברמת האזור של הפרויקט או ברמת המכונה הווירטואלית עבור מכונות וירטואליות ב-Compute Engine בארגון, בפרויקט או בתיקייה שבהם האילוץ הזה נאכף. כברירת מחדל, מותר להשתמש במפתחות SSH ברמת הפרויקט, ואפשר להשבית אותם ברמת הפרויקט, ברמת האזור או ברמת המכונה באמצעות מפתח המטא-נתונים הזה. כדי לאפשר מפתחות SSH ברמת הפרויקט למכונות וירטואליות ספציפיות, אפשר להחריג אותן מהמדיניות הזו באמצעות תגים וכללים מותנים.
חשוב: אכיפת ההגבלה הזו לא משפיעה על מכונות וירטואליות קיימות שבהן ההגדרה block-project-ssh-keys כבר מוגדרת כ-false. הן ישמרו על הגישה אלא אם המטא-נתונים שלהן יעודכנו.

constraints/compute.managed.blockProjectSshKeys
השבתת מאפייני אורח במטא-נתונים של Compute Engine

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

constraints/compute.managed.disableGuestAttributesAccess
השבתת וירטואליזציה מקוננת של מכונה וירטואלית

האילוץ הבוליאני הזה משבית את הווירטואליזציה המקוננת עם האצת חומרה בכל המכונות הווירטואליות ב-Compute Engine ששייכות לארגון, לפרויקט או לתיקייה שבהם האילוץ הזה מוגדר ל-True.‫
כברירת מחדל, וירטואליזציה מקוננת עם האצת חומרה מותרת לכל המכונות הווירטואליות של Compute Engine שפועלות בפלטפורמות של מעבדי Intel Haswell או מעבדים חדשים יותר.

constraints/compute.managed.disableNestedVirtualization
השבתת סוגי מכונות שלא תואמים לתקן FIPS

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

constraints/compute.managed.disableNonFIPSMachineTypes
הגבלת ההפעלה של מטא-נתונים של גישה ליציאה טורית של מכונה וירטואלית

האילוץ הזה מונע את ההגדרה של מפתח המטא-נתונים serial-port-enable לערך true במכונות וירטואליות של Compute Engine בארגון, בפרויקט או בתיקייה שבהם האילוץ הזה נאכף. כברירת מחדל, אפשר להפעיל גישה ליציאה טורית לכל מכונה וירטואלית, לכל אזור או לכל פרויקט באמצעות מפתח המטא-נתונים הזה. כדי לאפשר גישה ליציאה טורית למכונות וירטואליות ספציפיות, אפשר להחריג אותן מהמדיניות הזו באמצעות תגים וכללים מותנים.
חשוב: אכיפת ההגבלה הזו לא משפיעה על מכונות וירטואליות קיימות שבהן ההגדרה serial-port-enable כבר מוגדרת כ-true. הן ישמרו על הגישה אלא אם המטא נתונים שלהן יעודכנו.

constraints/compute.managed.disableSerialPortAccess
השבתת רישום ביומן של יציאה טורית של מכונה וירטואלית ב-Stackdriver

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

constraints/compute.managed.disableSerialPortLogging
השבתת היצירה של מכונות ב-Compute Engine שמשתמשות בסוכן ההפעלה של קונטיינרים (konlet) שהוצא משימוש.

תצוגה מקדימה: האילוץ הבוליאני הזה מונע יצירה של מכונות Compute Engine שמשתמשות ב-konlet, סוכן הפעלת הקונטיינר שהוצא משימוש. כשהאילוץ הזה מופעל, אי אפשר ליצור מכונות וירטואליות עם מפתח המטא-נתונים gce-container-declaration.האילוץ הזה גם מונע יצירה של מכונות וירטואליות מתבניות של מכונות וירטואליות שמכילות את מפתח המטא-נתונים gce-container-declaration, וזה משפיע על קבוצות מנוהלות של מכונות וירטואליות (MIG) שמשתמשות בתבניות כאלה של מכונות וירטואליות.

constraints/compute.managed.disableVmsWithContainerStartupAgent
מגביל את השימוש ב-DNS פנימי גלובלי (gDNS) בפרויקטים עם הגדרת DNS של ZonalOnly.

האילוץ הזה, כשהוא נאכף, מגביל את השימוש ב-gDNS. ההגבלה הזו משביתה את היצירה של מכונות וירטואליות של gDNS ואת העדכון של מכונות וירטואליות לשימוש ב-gDNS. אפשר להחזיר פרויקט zDNS ל-gDNS, אבל זה יוביל לאכיפה של הפרת מדיניות במהלך הפעלות עתידיות של Instance API. הערה: כדי שהמדיניות הזו תפעל כמצופה, צריך להגדיר במפורש את המטא-נתונים vmDnsSetting=ZonalOnly ברמת הפרויקט או ברמת המופע, גם אם DNS אזורי כבר מוגדר כברירת מחדל בפרויקט.

constraints/compute.managed.disallowGlobalDns
נדרשת הגדרת מערכת הפעלה

כשהאילוץ הזה נאכף, צריך להפעיל את VM Manager (OS Config) בכל הפרויקטים החדשים. בפרויקטים חדשים וקיימים, המגבלה הזו מונעת עדכוני מטא-נתונים שמשביתים את VM Manager ברמת הפרויקט, ברמת האזור או ברמת המכונה. אתם יכולים לאפשר למכונות וירטואליות ספציפיות להשבית את VM Manager. קודם צריך להחיל תגים כדי לסמן את המקרים, ואז להשתמש בכללים מותנים שמבוססים על ערכי התגים כדי להחריג את המקרים האלה מהאכיפה.

constraints/compute.managed.requireOsConfig
דרישה לשימוש ב-OS Login

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

constraints/compute.managed.requireOsLogin
הגבלת Confidential Computing

גרסת טרום-השקה (Preview): נדרש ליצור את כל מכונות ה-VM החדשות עם Confidential Computing מופעל. כברירת מחדל, לא נדרש שימוש ב-Confidential Computing במכונות וירטואליות חדשות. אפשר להחיל את האילוץ הזה או להחריג אותו באמצעות תגים לסימון מכונות וירטואליות, ולאחר מכן לאכוף את האילוץ באמצעות כללים מותנים שמבוססים על התגים שהוחלו.

constraints/compute.managed.restrictNonConfidentialComputing
הגבלת השימוש בהעברת פרוטוקולים

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

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

constraints/compute.managed.restrictProtocolForwardingCreationForTypes
הגדרת פרויקטים של תמונות מהימנות לדיסקים של אתחול

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

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

constraints/compute.managed.trustedImageProjects
הגבלת העברת כתובות IP של מכונות וירטואליות

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

constraints/compute.managed.vmCanIpForward
הגבלת כתובות IP חיצוניות למכונות וירטואליות

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

constraints/compute.managed.vmExternalIpAccess

הערכה היררכית של מטא-נתונים

אילוצים מנוהלים שמסתמכים על מפתחות מטא-נתונים מוגדרים מראש, כמו OS Login או Serial Port Access, תומכים בהערכה היררכית. כש-Compute Engine מעריך את האילוצים האלה, הוא בודק את ערכי המטא-נתונים שהוגדרו ברמת המכונה הווירטואלית, הפרויקט או האזור.

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

אילוצים ורמות שמבוססים על מטא-נתונים

מגבלה מפתח מטא-נתונים רמות בהיררכיית המטא-נתונים
compute.managed.disableSerialPortAccess serial-port-enable פרויקט, אזור, מכונה
compute.managed.requireOsLogin enable-oslogin פרויקט, אזור, מכונה
compute.managed.disableGuestAttributesAccess enable-guest-attributes פרויקט, אזור, מכונה
compute.managed.requireOsConfig enable-osconfig פרויקט, אזור, מכונה
compute.managed.disallowGlobalDns VmDnsSetting פרויקט, מכונה

השקה בטוחה: מחזור החיים של המדיניות

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

ניתוח באמצעות סימולטור המדיניות

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

  1. נכנסים לדף Organization Policies במסוף Google Cloud .

    מעבר אל Organization Policies

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

  3. לוחצים על בדיקת שינויים כדי ליצור דוח סימולציה.

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

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

אימות באמצעות הרצה יבשה

במצב הרצה יבשה, ההפרות נרשמות ב-Cloud Logging, אבל ההגבלות לא נאכפות.

כדי לבדוק אילוץ, משתמשים בפקודה gcloud org-policies set-policy באופן הבא:

  1. יוצרים קובץ YAML של מדיניות (לדוגמה, dry-run-policy.yaml) עם dryRunSpec:

    name: projects/PROJECT_ID/policies/compute.managed.requireOsLogin
dryRunSpec:
  rules:
  - enforce: true

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

  2. החלת המדיניות:

    gcloud org-policies set-policy dry-run-policy.yaml

אכיפה מלאה

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

בדיקת האכיפה של אילוצים

אחרי שמגדירים מדיניות, אפשר לוודא שהיא נאכפת באמצעות ה-CLI של gcloud. לדוגמה, כדי לבדוק את האילוץ compute.managed.requireOsLogin, מבצעים את השלבים הבאים:

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

    gcloud org-policies list --project=PROJECT_ID

  2. החלת מדיניות האכיפה באמצעות קובץ YAML:

    gcloud org-policies set-policy enforce_managed_constraint.yaml

  3. כדי לוודא שהאכיפה פועלת, קוראים ל-API של מוטציה. ניסיון ליצור מכונה וירטואלית עם מטא-נתונים שלא עומדים בדרישות אמור להיכשל:

    gcloud compute instances create VM_NAME \
    --machine-type=MACHINE_TYPE \
    --image-family=IMAGE_FAMILY \
    --image-project=IMAGE_PROJECT \
    --metadata=enable-oslogin=false

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

    • ‫VM_NAME: השם של המופע החדש של המכונה הווירטואלית.
    • ‫MACHINE_TYPE: סוג מכונה תקין, לדוגמה, e2-micro.
    • ‫IMAGE_FAMILY: משפחת תמונות תקינה, לדוגמה, debian-13.
    • ‫IMAGE_PROJECT: הפרויקט של משפחת התמונות, לדוגמה, debian-cloud.

  4. בודקים את הודעת השגיאה. אמורה להופיע הודעת דחייה שמציינת את האילוץ הספציפי שהופר: ERROR: (gcloud.compute.instances.create) Could not fetch resource: - Operation denied by org policy: [constraints/compute.managed.requireOsLogin]

פטורים מותנים עם תגים

אתם יכולים להשתמש בתגים כדי להעניק חריגים למשאבים ספציפיים על סמך צרכים עסקיים. בדוגמה הזו, אנחנו משתמשים בתג בשם osLoginOptional כדי לזהות משאבים שפטורים מהדרישה של OS Login. כשמקשרים את התג הזה עם הערך true למשאב, מדיניות הארגון מאפשרת למשאב הספציפי הזה להתקיים בלי ש-OS Login מופעל, גם אם המדיניות ממשיכה להיות נאכפת באופן מחמיר בשאר הסביבה.

כדי להעניק חריגה באמצעות תגים:

  1. יוצרים תג: משתמשים ב-CLI של gcloud כדי ליצור מפתח תג וערך תג.

    1. יוצרים את מפתח התג:

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

    2. יוצרים את ערך התג:

      gcloud resource-manager tags values create true \
    --parent=organizations/ORGANIZATION_ID/tagKeys/osLoginOptional

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

  2. מקשרים את התג למשאב. כדי להחריג פרויקט מהאילוץ compute.managed.requireOsLogin, צריך לקשר את התג osLoginOptional=true לפרויקט באמצעות הפקודה gcloud resource-manager tags bindings create:

    gcloud resource-manager tags bindings create \
    --tag-value=ORGANIZATION_ID/osLoginOptional/true \
    --parent=//cloudresourcemanager.googleapis.com/projects/PROJECT_ID \
    --location=global

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

    במאמר קישור תג למשאב מוסבר איך לקשר תגים למשאבים אחרים.

  3. מעדכנים את המדיניות: יוצרים או מעדכנים את קובץ ה-YAML של המדיניות (לדוגמה, policy.yaml) כדי לכלול את הכלל המותנה.

    name: projects/PROJECT_ID/policies/compute.managed.requireOsLogin
spec:
  rules:
  - condition:
      expression: "resource.matchTag('ORGANIZATION_ID/osLoginOptional', 'true')"
    enforce: false
  - enforce: true

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

    • PROJECT_ID: מזהה הפרויקט.
    • ‫ORGANIZATION_ID: מזהה הארגון.

  4. מחילים את המדיניות: משתמשים בפקודה הבאה של ה-CLI של gcloud כדי להפעיל את ההגדרה:

    gcloud org-policies set-policy policy.yaml

העברה ממגבלות קודמות

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

כשעוברים מאילוץ מדור קודם compute.* לאילוץ מודרני compute.managed.* מקביל, צריך לפעול לפי השלבים הבאים כדי למנוע החמרה לא מכוונת של ההגבלות:

  1. גילוי: זיהוי החלופה החדשה למגבלה המנוהלת.
  2. ניתוח ואימות: משתמשים בסימולטור המדיניות ובניסיון הרצה כמו שמתואר למעלה.
  3. אכיפת אילוץ מנוהל: הפעלת האילוץ המנוהל החדש לצד האילוץ הקודם.
  4. מחיקת כללי מדיניות מדור קודם:
    • עוברים אל 'מלאי נכסים' ב- Google Cloud Console ומסננים לפי orgpolicy.Policy ושם האילוץ מדור קודם כדי לזהות את כל כללי המדיניות שמשתמשים באילוץ מדור קודם.
    • מוחקים את כל כללי המדיניות שמשתמשים באילוץ מהגרסה הקודמת. מחיקת מדיניות מאפסת את המדיניות להתנהגות ברירת המחדל שמנוהלת על ידי Google עבור האילוץ הזה.

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