ההרשאה הדרושה כדי לצרף חשבונות שירות למשאבים

כשיוצרים משאבים מסוימים Google Cloud , אפשר לצרף חשבון שירות. חשבון השירות המצורף משמש כזהות של המשימות שרצות על המשאב, ומאפשר להן לבצע אימות ל- Google Cloud APIs.

ברוב השירותים של Google Cloud , המשתמשים צריכים הרשאה כדי להתחזות לחשבון שירות ולצרף את חשבון השירות הזה למשאב. המשמעות היא שהמשתמשים זקוקים להרשאת iam.serviceAccounts.actAs בחשבון השירות.

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

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

שירות התנהגות קודמת
App Engine משתמשים היו יכולים לפרוס יישומי App Engine שהשתמשו בזהות של חשבון השירות שמשמש כברירת המחדל של App Engine, גם אם לא הייתה להם הרשאה להתחזות לחשבון השירות הזה.
Cloud Composer משתמשים היו יכולים לצרף כל חשבון שירות בפרויקט לסביבה של Cloud Composer, גם אם לא הייתה להם הרשאה להתחזות לאף אחד מחשבונות השירות של הפרויקט.
  • Cloud Data Fusion
  • Dataflow
  • Dataproc
 משתמשים היו יכולים לצרף את חשבון השירות שמשמש כברירת המחדל של Compute Engine למשאבים, גם אם לא הייתה להם הרשאה להתחזות לחשבון הזה.
Dataform משתמשים היו יכולים לצרף חשבון שירות למשאב Dataform וליצור הפעלה של תהליך עבודה שתתבצע בתור חשבון השירות הזה, גם אם לא הייתה להם הרשאה להתחזות לחשבון השירות.

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

  • ארגונים עם משתמשים שיש להם הרשאה לפרוס אפליקציות של App Engine, אבל אין להם הרשאה להתחזות לחשבון השירות שמשמש כברירת מחדל בשביל App Engine.
  • ארגונים עם משתמשים שיש להם הרשאה לפרוס סביבות של Cloud Composer, אבל אין להם הרשאה להתחזות לחשבונות שירות.
  • ארגונים שיש למשתמשים שלהם הרשאה לפרוס משאבים של Cloud Data Fusion,‏ Dataflow או Dataproc, אבל אין להם הרשאה להתחזות לחשבון השירות שמשמש כברירת מחדל ל-Compute Engine.
  • ארגונים עם משתמשים שיש להם הרשאה לצרף חשבון שירות למשאב Dataform וליצור הפעלה של תהליך עבודה, אבל אין להם הרשאה להתחזות לחשבון השירות.

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

אבטחת App Engine

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

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

    לחשבון השירות שמשמש כברירת המחדל של App Engine מוענק באופן אוטומטי התפקיד 'עורך' (roles/editor) הכולל הרשאות רבות. עם זאת, לא מומלץ להשתמש בתפקיד עם הרשאות רבות כל כך בהגדרת מערכות Production.

  2. צריך לוודא שלכל המשתמשים הפורסים אפליקציות יש את היכולת להתחזות לחשבון השירות שמשמש כברירת המחדל של App Engine.

    כדי לספק את היכולת הזו, מעניקים למשתמשים תפקיד הכולל את ההרשאה iam.serviceAccounts.actAs, כמו תפקיד משתמש 'חשבון שירות' (roles/iam.serviceAccountUser). אפשר להעניק את התפקיד הזה לפרויקט או לחשבון השירות שמשמש כברירת המחדל של App Engine. למידע נוסף, עיינו במאמר ניהול התחזות לחשבון שירות.

  3. הפעילו את אילוץ המדיניות של הארגון constraints/appengine.enforceServiceAccountActAsCheck כדי לאכוף בדיקות של ההרשאות של חשבון השירות בעת פריסת אפליקציות.

  4. אופציונלי: אפשר להשתמש באוכף הבוליאני של מדיניות הארגון כדי לוודא שאילוץ מדיניות הארגון נאכף בכל הפרויקטים.

אבטחת Cloud Composer

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

  1. זיהוי כל חשבונות השירות המקושרים לסביבות של Cloud Composer:

    1. במסוף Google Cloud , עוברים אל הדף Composer environments.

      מעבר לדף Composer environments

    2. לוחצים על שם של סביבה.

    3. בכרטיסייהEnvironment configuration, מוצאים את השדה Service account ורושמים את השם של חשבון השירות.

    4. חוזרים על השלבים הקודמים בשביל כל הסביבות של Cloud Composer בפרויקט.

  2. וידוא שחשבונות השירות האלו פועלים לפי העיקרון של הרשאות מינימליות:

  3. צריך לוודא שלכל המשתמשים שפורסים או מנהלים סביבות של Cloud Composer יש את היכולת להתחזות לחשבונות השירות שבהם הסביבות משתמשות.

    כדי לספק את היכולת הזו, מעניקים למשתמשים תפקיד הכולל את ההרשאה iam.serviceAccounts.actAs, כמו התפקיד 'משתמש בחשבון שירות' (roles/iam.serviceAccountUser). אפשר להעניק את התפקיד הזה לפרויקט או לחשבון שירות יחיד. למידע נוסף, עיינו במאמר ניהול התחזות לחשבון שירות.

  4. הפעילו את אילוץ מדיניות הארגון constraints/composer.enforceServiceAccountActAsCheck כדי לאכוף בדיקות של ההרשאות של חשבון השירות בעת צירוף חשבונות שירות לסביבות.

  5. אופציונלי: אפשר להשתמש באוכף הבוליאני של מדיניות הארגון כדי לוודא שאילוץ מדיניות הארגון נאכף בכל הפרויקטים.

אבטחת Dataproc‏, Dataflow ו-Cloud Data Fusion

כדי להשבית באופן ידני את ההתנהגות הקודמת של Dataproc,‏ Dataflow ו-Cloud Data Fusion, צריך לוודא שלמשתמשים יש הרשאה להתחזות לחשבונות השירות שהם מצרפים למשאבים החדשים. לאחר מכן מפעילים אילוצים של מדיניות הארגון כדי לאכוף בדיקות של ההרשאות של חשבון השירות בעת צירוף חשבונות שירות למשאבים.

ביצוע ההוראות בשביל סוג חשבון השירות שרוצים לצרף למשאבים החדשים:

  • אם רוצים להפסיק את צירוף חשבון השירות שמשמש כברירת המחדל של Compute Engine למשאבים חדשים, מבצעים את השלבים הבאים:

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

      כדי ללמוד על איזה תפקידים חשבון השירות צריך להריץ משימות ב-Dataproc,‏ Dataflow ו-Cloud Data Fusion, עיינו במקורות הבאים:

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

      כדי לספק את היכולת הזו, מעניקים למשתמשים תפקיד הכולל את ההרשאה iam.serviceAccounts.actAs, כמו התפקיד 'משתמש חשבון שירות' (roles/iam.serviceAccountUser). אפשר להעניק את התפקיד הזה לפרויקט או לחשבון השירות. למידע נוסף, עיינו במאמר ניהול התחזות לחשבון שירות.

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

      • constraints/dataflow.enforceComputeDefaultServiceAccountCheck
      • constraints/dataproc.enforceComputeDefaultServiceAccountCheck

      אילוץ מדיניות הארגון constraints/dataproc.enforceComputeDefaultServiceAccountCheck אוכף גם בדיקות של ההרשאות בשביל Cloud Data Fusion.

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

    5. כאשר פורסים משאבים חדשים, השתמשו בחשבון השירות החדש במקום בחשבון השירות שמוגדר כברירת מחדל של Compute Engine.

  • אם רוצים להמשיך בצירוף חשבון השירות שמוגדר כברירת המחדל של Compute Engine למשאבים חדשים, בצעו את השלבים הבאים:

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

      לחשבון השירות שמשמש כברירת המחדל של Compute Engine, מוענק באופן אוטומטי התפקיד 'עורך' (roles/editor) הכולל הרשאות רבות. עם זאת, לא מומלץ להשתמש בתפקיד עם הרשאות רבות כל כך בהגדרת מערכות Production.

    2. צריך לוודא שלכל המשתמשים הפורסים את המשאבים האלו יש את היכולת להתחזות לחשבון השירות שמשמש כברירת המחדל של Compute Engine.

      כדי לספק את היכולת הזו, העניקו למשתמשים תפקיד הכולל את ההרשאה iam.serviceAccounts.actAs, כמו התפקיד 'משתמש חשבון שירות' (roles/iam.serviceAccountUser). אפשר להעניק את התפקיד הזה לפרויקט או לחשבון השירות המשמש כברירת מחדל של Compute Engine. למידע נוסף, עיינו במאמר ניהול התחזות לחשבון שירות.

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

      • constraints/dataflow.enforceComputeDefaultServiceAccountCheck
      • constraints/dataproc.enforceComputeDefaultServiceAccountCheck

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

אבטחה של Dataform

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

  1. כדאי לבדוק אם יש בעיות בהרשאות כדי למנוע שיבושים בתהליכי העבודה. כדי לעשות את זה, אפשר לשלוח שאילתה ל-Cloud Logging לגבי רשומות ספציפיות ל-Dataform שמציינות שחסרה למשתמש או לחשבון שירות הרשאה נדרשת iam.serviceAccounts.actAs. כך תוכלו לזהות ולפתור מראש אי-התאמות בגישה. מידע נוסף זמין במאמר בדיקת בעיות בהרשאות ב-Cloud Logging.

  2. כדי שמשתמשים או חשבונות שירות יוכלו ליצור הפעלות של תהליכי עבודה, צריך להעניק להם הרשאה להתחזות לחשבון השירות שמשויך למאגר Dataform. כדי לתת את ההרשאה הזו, צריך להקצות את התפקיד 'משתמש בחשבון שירות' (roles/iam.serviceAccountUser) בחשבון השירות הספציפי. אפשר לקרוא מידע נוסף במאמר פתרון בעיות שקשורות להרשאות.

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

    • יצירת אסימונים בחשבון שירות (roles/iam.serviceAccountTokenCreator): נדרש לכל הפעולות במאגר באמצעות חשבון שירות בהתאמה אישית.
    • משתמש בחשבון שירות (roles/iam.serviceAccountUser): נדרש רק אם משתמשים בהגדרות של זרימת עבודה כדי לתזמן או לבצע אוטומציה של הרצות. התפקיד הזה מאפשר לסוכן השירות שמוגדר כברירת מחדל ב-Dataform להריץ משימות בתור חשבון השירות המותאם אישית.

  4. כדי לאכוף את בדיקת ההרשאה לפעול בשם מישהו אחר, מפעילים את המצב הקפדני של פעולה בשם מישהו אחר. התכונה הזו משפרת את האבטחה בכך שהיא מוודאת שלכל משתמש שיוצר הפעלה של תהליך עבודה יש את ההרשאה iam.serviceAccounts.actAs בחשבון השירות הרלוונטי.

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

    מידע נוסף זמין במאמר בנושא שימוש במצב 'פועל כ' מחמיר.

  5. חשוב לבצע ביקורת תקופתית על משאבי Dataform כדי לוודא שחשבונות השירות נמצאים בשימוש תקין ושההרשאות ניתנות בצורה נכונה. משתמשים במאגר משאבי ענן כדי להציג רשימה של כל המשאבים מהסוגים dataform.Repository ו-dataform.WorkflowConfig, ואז בודקים את השדה resource.data.serviceAccount כדי לראות באיזה חשבון שירות נעשה שימוש. אם משתמשים בחשבון שירות בהתאמה אישית, צריך לוודא שלסוכן השירות שמוגדר כברירת מחדל ב-Dataform יש את התפקידים Service Account User ‏(roles/iam.serviceAccountUser) ו-Service Account Token Creator ‏(roles/iam.serviceAccountTokenCreator) בחשבון השירות הזה בהתאמה אישית. מידע נוסף מופיע במאמר בנושא ביקורת על הגדרות של חשבונות שירות.