שינוי בחשבון השירות שמוגדר כברירת מחדל ב-Cloud Build

מערכת Cloud Build בוחרת באופן אוטומטי את חשבון השירות של Cloud Build כדי להפעיל בשמכם את גרסאות ה-build, אלא אם אתם משנים את ההתנהגות הזו. יכול להיות שלחשבון השירות שמוגדר כברירת מחדל יש הרשאות רחבות מדי לתרחיש השימוש שלכם, כמו גישה לכל קטגוריה של Cloud Storage בפרויקט.

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

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

אחרי השינוי הזה, חשבון השירות שמוגדר כברירת מחדל ב-Cloud Build הוא חשבון השירות שמוגדר כברירת מחדל ב-Compute Engine.

ההשפעה על הפרויקטים תלויה בשאלה אם אתם חלק מארגון:

  • פרויקטים ללא ארגון. אם תפעילו את ה-build הראשון בפרויקט אחרי השינוי, הפרויקט ישתמש בחשבון השירות של Compute Engine כברירת מחדל עבור גרסאות build שנשלחות באמצעות Cloud Build API או Google Cloud CLI. בפרויקטים האלה לא תהיה אפשרות להשתמש בחשבון השירות מדור קודם של Cloud Build, אבל אפשר יהיה להשתמש בחשבון שירות שצוין על ידי המשתמש.

  • פרויקטים עם ארגון. אם מריצים את הבנייה הראשונה בפרויקט אחרי השינוי, הפרויקט ישתמש בחשבון השירות של Compute Engine כברירת מחדל לבנייות שנשלחות באמצעות Cloud Build API או Google Cloud CLI. אתם יכולים להשתמש בחשבון שירות שצוין על ידי המשתמש או לבטל את השינוי על ידי הפעלת חשבון השירות של Cloud Build בארגון.

  • פרויקטים קיימים בלי ארגון. אם הפעלתם את ה-build הראשון בפרויקט לפני השינוי, הפרויקט ימשיך לפעול לפי ההתנהגות הקודמת, וישתמש בחשבון השירות הקודם של Cloud Build כברירת מחדל לכל ה-builds. אתם יכולים להמשיך להשתמש בחשבון שירות שהוגדר על ידי המשתמש, על ידי בחירה בחשבון השירות של Compute Engine או יצירת חשבון משלכם.

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

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

  • השם של חשבון השירות ב-Cloud Build: חשבון השירות ב-Cloud Build יקרא מעכשיו חשבון השירות מדור קודם ב-Cloud Build.

מה צריך לעשות?

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

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

  • לא נאכף: constraints/cloudbuild.disableCreateDefaultServiceAccount
  • לא נאכף: constraints/cloudbuild.useComputeServiceAccount
  • נאכף: constraints/cloudbuild.useBuildServiceAccount

אם אתם לא יכולים או לא רוצים לשנות את מדיניות הארגון, ואתם מפעילים את Cloud Build API אחרי השינוי, אתם צריכים לוודא של-Compute Engine default service account או ל-your user-created service account יש מספיק הרשאות לגרסת ה-build שלכם. בפרט, למשתמש ששולח את ה-build צריכה להיות ההרשאה iam.serviceAccounts.actAs בחשבון השירות.

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

ב-Cloud Build הוספנו אילוצי בוליאני חדשים של מדיניות הארגון כדי להגדיר:

  • האפשרות להשתמש בחשבון השירות מדור קודם של Cloud Build.
  • חשבון השירות שמוגדר כברירת מחדל לכל הפרויקטים בארגון.

כדי לשנות מדיניות ארגונית, אפשר להשתמש במסוף Google Cloud או ב-Google Cloud CLI:

מידע נוסף על מדיניות הארגון זמין במאמר מבוא לשירות מדיניות הארגון.

הגדרת הזמינות של חשבון השירות מדור קודם ב-Cloud Build

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

  • לא נאכף: constraints/cloudbuild.disableCreateDefaultServiceAccount. מאפשרת שימוש בחשבון השירות מדור קודם של Cloud Build בפרויקטים חדשים.

  • נאכף: constraints/cloudbuild.disableCreateDefaultServiceAccount. ההגדרה הזו משביתה את השימוש בחשבון השירות מדור קודם של Cloud Build בפרויקטים חדשים. זהו ערך ברירת המחדל של האילוץ.

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

כמו בכל מדיניות ארגונית ואילוץ, אפשר להגדיר את המדיניות הזו ברמת הארגון או ברמת הפרויקט.

הגדרת חשבון השירות שמוגדר כברירת מחדל לארגון

כדי להגדיר את חשבון השירות שמשמש כברירת מחדל בארגון, אנחנו משיקים ב-Cloud Build שני אילוצים בוליאניים חדשים של מדיניות:

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

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

    • לא נאכף: constraints/cloudbuild.useBuildServiceAccount
    • לא נאכף: constraints/cloudbuild.useComputeServiceAccount

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

    • לא נאכף: constraints/cloudbuild.useBuildServiceAccount
    • נאכף: constraints/cloudbuild.useComputeServiceAccount

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

    • לא נאכף: constraints/cloudbuild.disableCreateDefaultServiceAccount
    • לא נאכף: constraints/cloudbuild.useComputeServiceAccount
    • נאכף: constraints/cloudbuild.useBuildServiceAccount

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

    • נאכף: constraints/cloudbuild.disableCreateDefaultServiceAccount
    • נאכף: constraints/cloudbuild.useComputeServiceAccount
    • נאכף: constraints/cloudbuild.useBuildServiceAccount

הנחיות לגבי תפקידי IAM

מדיניות הארגון iam.automaticIamGrantsForDefaultServiceAccounts מונעת מחשבונות שירות מסוימים שמוגדרים כברירת מחדל לקבל את התפקיד 'עריכה' (roles/editor) בזמן היצירה. המדיניות הזו מופעלת בארגונים החל מ-3 במאי 2024, והיא חלה על חשבונות שירות שמוגדרים כברירת מחדל ב-Compute Engine וב-App Engine, שנוצרו ב-3 במאי 2024 או אחריו. מומלץ להשאיר את המדיניות הזו מופעלת, כי התפקיד 'עריכה' הוא רחב מאוד ומעניק יותר הרשאות ממה שנדרש ברוב תרחישי השימוש.

מדיניות הארגון הזו לא חלה על חשבון השירות מדור קודם של Cloud Build, כי לחשבון השירות הזה לא מוקצה התפקיד'עריכה' כברירת מחדל. עם זאת, לחשבון השירות הקודם של Cloud Build מוקצה כברירת מחדל התפקיד 'חשבון שירות של Cloud Build' (roles/cloudbuild.builds.builder), שכולל גם הוא מגוון רחב של הרשאות. אם אתם משתמשים בחשבון שירות מדור קודם של Cloud Build, מומלץ לבדוק אם התפקיד של חשבון השירות של Cloud Build נחוץ לתרחיש השימוש שלכם, או אם אפשר להחליף אותו בתפקיד עם פחות הרשאות.

מידע נוסף זמין במאמרים הגבלת השימוש בחשבונות שירות של IAM ושימוש מאובטח ב-IAM.

קבלת חשבון השירות הנוכחי שמוגדר כברירת מחדל בפרויקט

כדי לדעת באיזה חשבון שירות Cloud Build משתמש כברירת מחדל בפרויקט, אפשר להשתמש ב-Google Cloud CLI או ב-Cloud Build API:

‫CLI של gcloud

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

gcloud builds get-default-service-account

Cloud Build API

משתמשים ב-cURL כדי לשלוח קריאה ל-Cloud Build API:

curl -X GET -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     https://cloudbuild.googleapis.com/v1/projects/PROJECT_ID/locations/REGION/defaultServiceAccount

מחליפים את הערכים של ה-placeholder בערכים הבאים: