הגבלת עומסי עבודה עם הרשאות ב-GKE בארגונים

אתם יכולים להשתמש במדיניות כדי לקבוע אילו עומסי עבודה עם הרשאות יכולים לפעול באשכולות Google Kubernetes Engine ‏ (GKE) בארגון שלכם. Google Cloud במאמר הזה מוסבר איך להשתמש במדיניות כדי להגדיר מקורות מאושרים של עומסי עבודה ולאכוף שיטות מומלצות לשיפור מצב האבטחה.

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

איך פועל בקרת הכניסה של עומסי עבודה עם הרשאות מיוחדות בארגונים

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

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

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

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

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

  1. נכנסים לחשבון Google Cloud . אם אתם משתמשים חדשים ב- Google Cloud, צרו חשבון כדי שתוכלו להעריך את הביצועים של המוצרים שלנו בתרחישים מהעולם האמיתי. לקוחות חדשים מקבלים בחינם גם קרדיט בשווי 300$ להרצה, לבדיקה ולפריסה של עומסי העבודה.
  2. Enable the Resource Manager API.

    Roles required to enable APIs

    To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

    Enable the API

  3. Enable the Resource Manager API.

    Roles required to enable APIs

    To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

    Enable the API

  4. אם לצוותים שלכם יש רשימות היתרים לעומסי עבודה עם הרשאות שהם הבעלים שלהם, בקשו מהם לתת לכם את הנתיבים לרשימות ההיתרים האלה ב-Cloud Storage.

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

כדי לקבל את ההרשאות שדרושות לניהול מדיניות הארגון, צריך לבקש מהאדמין להקצות לכם את תפקיד ה-IAM‏ Organization policy administrator (roles/orgpolicy.policyAdmin) בארגון, בתיקייה או בפרויקט. כדי לקרוא הסבר על מתן תפקידים, ראו איך מנהלים את הגישה ברמת הפרויקט, התיקייה והארגון.

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

הגדרת מדיניות ארגונית לרשימות היתרים

כדי לקבוע מהם המקורות המאושרים של רשימות ההיתרים בארגון, בתיקייה או בפרויקט, אפשר ליצור או לעדכן מדיניות ארגון שמבוססת על המגבלה המנוהלת constraints/container.managed.autopilotPrivilegedAdmission. כשמפעילים את מדיניות הארגון הזו, אדמינים של אשכולות יכולים להתקין רשימות היתרים רק מהמקורות שמוגדרים במדיניות.

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

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

המסוף

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

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

  2. בטבלת האילוצים, מחפשים את האילוץ המנוהל container.managed.autopilotPrivilegedAdmission.

  3. לוחצים על פעולות > עריכת המדיניות. ייפתח הדף עריכת מדיניות.

  4. בקטע Policy source, בוחרים באפשרות Override parent's policy.

  5. בקטע Rules, לוחצים על Add a rule.

  6. בקטע Enforcement, בוחרים באפשרות On. יופיע הקטע Parameters (פרמטרים).

  7. כדי לקבוע אם אפשר להתקין רשימות היתרים שאושרו על ידי GKE, פועלים לפי השלבים הבאים:

    1. בפרמטר allowAnyGKEPath, לוחצים על Edit. ייפתח החלונית עריכת ערכי פרמטרים.
    2. בקטע סוג הערך, בוחרים באפשרות בהגדרת המשתמש.
    3. בקטע ערכים שהוגדרו על ידי המשתמש, בוחרים באחת מהאפשרויות הבאות:

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

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

    1. בפרמטר allowPaths, לוחצים על עריכה. ייפתח החלונית עריכת ערכי פרמטרים.
    2. בקטע סוג הערך, בוחרים באפשרות בהגדרת המשתמש.
    3. בקטע ערכים בהגדרת המשתמש, מציינים נתיב אחד או יותר למקורות ברשימת ההיתרים. מידע נוסף על מה שאפשר לציין זמין במאמר בנושא נתיבים ברשימת ההיתרים.
    4. לוחצים על Save. החלונית עריכת ערכי פרמטרים נסגרת.
    5. בקטע עריכת הכלל, לוחצים על סיום.
  9. אופציונלי: כדי לבדוק את ההשפעה של אכיפת מדיניות הארגון, לוחצים על בדיקת שינויים. מידע נוסף זמין במאמר בנושא בדיקת שינויים במדיניות הארגון באמצעות סימולטור המדיניות.

  10. כדי לאכוף את המדיניות במצב הרצת בדיקה, לוחצים על הגדרת המדיניות להרצת בדיקה.

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

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

gcloud

  1. יוצרים קובץ YAML שמגדיר את מדיניות הארגון:

    name: RESOURCE_TYPE/RESOURCE_ID/policies/container.managed.autopilotPrivilegedAdmission
    spec:
      rules:
      - enforce: true
        parameters:
          allowAnyGKEPath: ALLOW_GKE_PATHS
          allowPaths:
          - ALLOWLIST1_PATH
          - ALLOWLIST2_PATH
    

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

    • RESOURCE_TYPE: סוג המשאבGoogle Cloud . הערך צריך להיות אחד מהערכים הבאים:

      • organizations
      • folders
      • projects
    • RESOURCE_ID: מזהה הארגון, מזהה התיקייה או מזהה הפרויקט.

    • ALLOW_GKE_PATHS: האם לאפשר רשימות היתרים שאושרו על ידי GKE. מציינים אחד מהערכים הבאים:

      • True: מאפשרת הגדרת אשכול עם כל עומס עבודה של שותף GKE או עומסי עבודה מאומתים בקוד פתוח. זה ערך ברירת המחדל.
      • False: מאפשר הגדרת אשכול רק עם הנתיבים בשדה allowPaths.

    • ALLOWLIST1_PATH,ALLOWLIST2_PATH: הנתיב לרשימות ההיתרים. מידע נוסף על מה שאפשר לציין זמין במאמר נתיבים ברשימת ההיתרים.

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

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

    gcloud org-policies set-policy POLICY_FILEPATH \
        --update-mask=dryRunSpec
    

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

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

    gcloud policy-intelligence simulate org-policy \
        --organization=ORGANIZATION_ID \
        --policy-path=POLICY_FILEPATH
    

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

  4. אחרי שמוודאים שמדיניות הארגון פועלת כמו שרוצים במצב הרצה יבשה, מגדירים את המדיניות הפעילה על ידי ציון הערך spec לדגל --update-mask בפקודה gcloud org-policies set-policy:

    gcloud org-policies set-policy POLICY_FILEPATH \
        --update-mask=spec
    

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

הגדרת מדיניות ארגונית כדי לאפשר רק אשכולות Autopilot

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

כדי להגדיר את המדיניות הזו, בוחרים באחת מהאפשרויות הבאות:

המסוף

  1. יצירת אילוץ בהתאמה אישית שמאפשר רק יצירה של אשכול Autopilot:

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

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

    2. לוחצים על Custom constraint (הגבלה מותאמת אישית). ייפתח הדף Create custom constraint.

    3. מציינים שם לתצוגה ומזהה ייחודי לאילוץ.

    4. בקטע Enforcement (אכיפה), פועלים לפי השלבים הבאים:

      1. ברשימה Resource type בוחרים באפשרות container.googleapis.com/Cluster.
      2. ברשימה Enforcement method בוחרים באפשרות Enforcement on create.
      3. בקטע Condition לוחצים על Edit Condition. נפתחת החלונית Add condition.
      4. מציינים את הביטוי הבא:

        resource.autopilot.enabled == true
        
      5. לוחצים על Save. החלונית הוספת תנאי נסגרת.

      6. בקטע פעולה, בוחרים באפשרות אישור.

    5. לוחצים על יצירת אילוץ.

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

    1. בטבלת האילוצים, מחפשים את האילוץ המותאם אישית שיצרתם בשלב הקודם.
    2. לוחצים על פעולות > עריכת המדיניות. ייפתח הדף עריכת מדיניות.
    3. בקטע Policy source, בוחרים באפשרות Override parent's policy.
    4. לוחצים על Add a rule.
    5. בקטע Enforcement, בוחרים באפשרות On.
    6. כדי לבדוק את ההשפעה של אכיפת מדיניות הארגון, לוחצים על בדיקת שינויים. מידע נוסף זמין במאמר בנושא בדיקת שינויים במדיניות הארגון באמצעות סימולטור המדיניות.
    7. כדי לאכוף את המדיניות במצב הרצת בדיקה, לוחצים על הגדרת המדיניות להרצת בדיקה.
    8. אחרי שמוודאים שמדיניות הארגון פועלת כמו שרוצים במצב הרצה יבשה, מגדירים את המדיניות הפעילה על ידי לחיצה על הגדרת מדיניות.

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

gcloud

  1. יצירת אילוץ בהתאמה אישית שמאפשר רק יצירה של אשכול Autopilot:

    1. יוצרים קובץ YAML שמגדיר את האילוץ בהתאמה אישית:

      name: organizations/ORGANIZATION_ID/customConstraints/CONSTRAINT_NAME
      resourceTypes: container.googleapis.com/Cluster
      methodTypes:
      - CREATE
      condition: resource.autopilot.enabled == true
      actionType: ALLOW
      displayName: "Allow only Autopilot clusters"
      

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

      • ORGANIZATION_ID: מזהה הארגון.
      • CONSTRAINT_NAME: שם לאילוץ החדש.
    2. מגדירים את האילוץ המותאם אישית:

      gcloud org-policies set-custom-constraint CONSTRAINT_FILEPATH
      

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

    אפשר להשתמש באילוץ בהתאמה אישית במדיניות הארגון.

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

    1. יוצרים קובץ YAML שמגדיר את מדיניות הארגון:

      name: RESOURCE_TYPE/RESOURCE_ID/policies/custom.CONSTRAINT_NAME
      spec:
        rules:
        - enforce: true
      

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

      • RESOURCE_TYPE: סוג המשאבGoogle Cloud . הערך צריך להיות אחד מהערכים הבאים:

        • organizations
        • folders
        • projects
      • RESOURCE_ID: המזהה של הארגון, התיקייה או הפרויקט.

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

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

      gcloud org-policies set-policy POLICY_FILEPATH \
          --update-mask=dryRunSpec
      

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

    3. כדי לבדוק את ההשפעה של אכיפת מדיניות הארגון הזו, משתמשים בפקודה gcloud policy-intelligence simulate org-policy:

      gcloud policy-intelligence simulate org-policy \
          --organization=ORGANIZATION_ID \
          --policy-path=POLICY_FILEPATH
      

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

    4. אחרי שמוודאים שמדיניות הארגון פועלת כמו שרוצים במצב הרצה יבשה, מגדירים את המדיניות הפעילה על ידי ציון הערך spec לדגל --update-mask בפקודה gcloud org-policies set-policy:

      gcloud org-policies set-policy POLICY_FILEPATH \
          --update-mask=spec
      

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

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