מה עושים כשמופיע withcond בכללי מדיניות ובקישורי תפקידים

כשמסתכלים על מדיניות הרשאה, עשויים לראות שמות של תפקידים שכוללים את המחרוזת withcond, ולאחר מכן ערך גיבוב (hash). לדוגמה, ייתכן שתראו שם של תפקיד כמו roles/iam.serviceAccountAdmin_withcond_2b17cc25d2cd9e2c54d8.

בדף הזה מוסבר מתי ולמה המחרוזת withcond עשויה להופיע במדיניות הרשאה. וגם מוצגות פעולות מומלצות לביצוע אם המחרוזת הזו מופיעה.

גרסאות מדיניות וקישורי תפקידים מותנים

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

במדיניות הרשאה בגרסה 1, חלק מקישורי התפקידים עשויים להכיל את המחרוזת withcond בשם התפקיד ואחריו ערך גיבוב (hash):

{
  "bindings": [
    {
      "members": [
        "user:dana@example.com"
      ],
      "role": "roles/iam.serviceAccountAdmin_withcond_2b17cc25d2cd9e2c54d8"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

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

גרסה 1 של מדיניות הרשאה לא מציגה את אותם תנאים. אם מופיעה המחרוזת withcond עם ערך גיבוב (hash), אז קישור התפקיד כולל תנאי שלא ניתן לראותו.

הפתרון: ציון גרסה 3 של המדיניות

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

עדכון הכלי של gcloud

אם משתמשים ב-Google Cloud CLI, מריצים את gcloud version כדי לבדוק את מספר הגרסה. הפלט כולל מחרוזת הדומה ל-Google Cloud CLI 279.0.0.

אם מספר הגרסה פחות מ-263.0.0, מריצים את הפקודה gcloud components update כדי לעדכן את ה-CLI של gcloud. בגרסה 263.0.0 ואילך, ב-CLI של gcloud מופיעה באופן אוטומטי גרסת מדיניות הרשאה שתומכת בתנאים.

עדכון ספריות לקוח

אם האפליקציה משתמשת בספריית לקוח, צריך לבצע את השלבים הבאים:

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

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

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

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

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

עדכון קריאות API ל-REST

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

עדכון כלי ניהול של מדיניות

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

  • כל הבקשות לקבלת מדיניות הרשאה או הגדרה שלה מציינות את הגרסה 3
  • כל הבקשות להגדרת מדיניות הרשאה כוללות את השדה etag בבקשה

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

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

  1. מעניקים את התפקיד 'יצירת חשבונות שירות' (roles/iam.serviceAccountCreator) למשתמש Mahan בתיקייה my-folder. מדיניות ההרשאה של התיקייה נראית דומה לדוגמה הזו:

    {
  "bindings": [
    {
      "members": [
        "user:mahan@example.com"
      ],
      "role": "roles/iam.serviceAccountCreator"
    }
  ],
  "etag": "BuFmmMhCsNY=",
  "version": 1
}

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

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

    {
  "bindings": [
    {
      "members": [
        "user:mahan@example.com"
      ],
      "role": "roles/iam.serviceAccountCreator",
      "condition": {
        "title": "work_week_only",
        "expression": "request.time.getDayOfWeek('Europe/Berlin') >= 1 && request.time.getDayOfWeek('Europe/Berlin') <= 5"
      }
    }
  ],
  "etag": "BwWcR/B3tNk=",
  "version": 3
}

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

    {
  "bindings": [
    {
      "members": [
        "user:mahan@example.com"
      ],
      "role": "roles/iam.serviceAccountCreator_withcond_a75dc089e6fa084bd379"
    }
  ],
  "etag": "BwWcR/B3tNk=",
  "version": 1
}

בשלב הזה, כלי הניהול עשוי להחליט שהקישור מ-Mahan לתפקיד roles/iam.serviceAccountCreator נעלם, ושצריך לשחזר את קישור התפקיד המקורי למדיניות ההרשאה:

יש להימנע מקישור תפקיד נוסף ללא תנאי

{
  "bindings": [
    {
      "members": [
        "user:mahan@example.com"
      ],
      "role": "roles/iam.serviceAccountCreator_withcond_a75dc089e6fa084bd379"
    },
    {
      "members": [
        "user:mahan@example.com"
      ],
      "role": "roles/iam.serviceAccountCreator"
    }
  ],
  "etag": "BwWd3HjhKxE=",
  "version": 1
}

השינוי הזה שגוי. הוא מעניק את התפקיד roles/iam.serviceAccountCreator למאהן, ללא קשר ליום בשבוע. כתוצאה מכך, התנאי בקישור התפקיד הראשון לא משפיע.

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

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