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

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

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

יתרונות

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

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

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

תמחור

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

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

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

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

    המסוף

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

    gcloud

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

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

    • REST

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

      התקינו את ה-CLI של Google Cloud ואז היכנסו ל-CLI של gcloud באמצעות הזהות המאוחדת שלכם.

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

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

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

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

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

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

מגבלה מפתח מטא-נתונים רמות בהיררכיית המטא-נתונים
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 במסוף Cloud de Confiance .

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

  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 דקות עד שהשינויים במדיניות יתעדכנו בכל המערכות שלCloud de Confiance by S3NS .

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

אחרי שמגדירים מדיניות, אפשר לוודא שהיא נאכפת באמצעות ה-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-11.
    • ‫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. מחיקת כללי מדיניות מדור קודם:
    • עוברים אל 'מלאי נכסים' ב Cloud de Confiance מסוף ומסננים לפי orgpolicy.Policy ושם האילוץ מדור קודם כדי לזהות את כל כללי המדיניות שמשתמשים באילוץ מדור קודם.
    • מוחקים את כל כללי המדיניות שמשתמשים באילוץ מהגרסה הקודמת. אם מוחקים מדיניות, היא חוזרת להתנהגות ברירת המחדל שמנוהלת על ידי Google עבור האילוץ הזה.

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