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

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

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

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

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

מידע על חשבון השירות של Compute Engine שמוגדר כברירת מחדל

יכול להיות שהמדיניות של הארגון שלכם מגדירה את חשבון השירות שמוגדר כברירת מחדל ב-Cloud Build כחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine. כתובת האימייל של חשבון השירות הזה היא
[e-mail].

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

מידע על חשבון השירות בגרסה הקודמת של Cloud Build

יכול להיות שהמדיניות של הארגון מגדירה את חשבון השירות שמוגדר כברירת מחדל ב-Cloud Build כחשבון השירות מדור קודם. כתובת האימייל של חשבון השירות ב-Cloud Build מדור קודם היא
[e-mail]

בקטע הזה מוסברות כל ההרשאות שחשבון השירות מדור קודם של Cloud Build מקבל כברירת מחדל.

הרשאות ברירת המחדל של חשבון השירות בגרסה הקודמת של Cloud Build

אם ההגדרות של הפרויקט מאפשרות שימוש בחשבון השירות מדור קודם של Cloud Build, חשבון השירות מדור קודם מקבל את התפקיד חשבון השירות של Cloud Build (roles/cloudbuild.builds.builder) למשאבים בפרויקט. התפקיד הזה כולל מספר הרשאות, כמו האפשרות לעדכן גרסאות build או לכתוב יומנים. חשבון השירות משתמש בהרשאות האלה רק לפי הצורך כדי לבצע פעולות במהלך ההרצה של הבנייה. לדוגמה, חשבון השירות משתמש בהרשאה artifactregistry.dockerimages.get כדי לקבל תמונת docker מ-Artifact Registry, אם הגדרתם את הבנייה כך.

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

הערה: חשבון השירות מדור קודם של Cloud Build הוא בבעלות Google ולא בניהול המשתמש. לכן, אי אפשר להוסיף לו קישור למדיניות IAM, וכתוצאה מכך אי אפשר לאפשר לחשבון משתמש אחר (לדוגמה, חשבון שירות אחר) ליצור אסימוני גישה, אסימוני מזהה או אסימוני JWT לחשבון השירות מדור קודם של Cloud Build.

בטבלה הבאה מפורטות ההרשאות שכלולות בתפקיד Cloud Build Service Account (roles/cloudbuild.builds.builder) והמטרה שלשמה חשבון השירות מדור קודם של Cloud Build משתמש בהרשאות האלה.

הרשאה	תיאור	מטרת ההרשאה
cloudbuild.builds.create	יכולים ליצור גרסאות build וטריגרים	חובה: משתמשים בטריגרים של בנייה. יצירה, הצגה, קבלת מידע או ביטול של בנייה.
cloudbuild.builds.update	יכולים לעדכן את הגרסאות ואת הטריגרים
cloudbuild.builds.list	יכולים לראות את רשימת הבנייה והטריגרים
cloudbuild.builds.get	יכולים לקבל build וטריגר
cloudbuild.workerpools.use	אפשר להשתמש בבריכה פרטית	נדרש להפעלת בנייה במאגר פרטי.
logging.logEntries.create	יכולת לכתוב יומנים	נדרש כדי ליצור יומני build ולפרט אותם ב-Cloud Logging.
logging.logEntries.list	אפשר להציג רשימה של יומנים
logging.views.access	אפשרות לצפייה ביומנים
pubsub.topics.create	יכולים ליצור נושאים ב-Pub/Sub	חובה כדי לדחוף עדכוני build ל-Pub/Sub.
pubsub.topics.publish	אפשר לפרסם ב-Pub/Sub
remotebuildexecution.blobs.get	יכול לקבל גישה לאישור או לדחייה של גרסאות build.	rowspan=3>נדרש כדי לאשר או לדחות גרסאות build בהמתנה
resourcemanager.projects.get	אפשר לקבל את פרטי הפרויקט
resourcemanager.projects.list	מותר להציג רשימת פרויקטים
source.repos.get	יכול לקרוא קוד מקור ממאגרים ב-Cloud Source Repositories	חובה: שימוש בטריגרים של Bitbucket ו-Cloud Source Repositories. שליפת קוד מקור מ-Cloud Source Repositories.
source.repos.list	יכול להציג רשימה של מאגרי מידע ב-Cloud Source Repositories
storage.buckets.create	אפשר ליצור קטגוריות ב-Cloud Storage	חובה: אחסון וקבלת ארטיפקטים ב-Cloud Storage. שליחת גרסאות build באופן ידני באמצעות gcloud builds submit. אחסון יומני בנייה בדלי יומנים שנוצר על ידי המשתמש.
storage.buckets.get	יכול לגשת לקטגוריות של Cloud Storage
storage.buckets.list	יכול להציג רשימה של קטגוריות של Cloud Storage
storage.objects.list	יכולה להציג רשימה של אובייקטים ב-Cloud Storage
storage.objects.update	יכול לעדכן אובייקטים ב-Cloud Storage
storage.objects.create	יכול לכתוב אובייקטים ב-Cloud Storage
storage.objects.delete	אפשר למחוק אובייקטים ב-Cloud Storage
storage.objects.get	יכול לקרוא אובייקטים ב-Cloud Storage
artifactregistry.repositories.uploadArtifacts	יכולים להעלות פריטי מידע שנוצרו בתהליך פיתוח (Artifact) למאגרים ב-Artifact Registry	נדרשת כדי לנהל ארטיפקטים ב-Artifact Registry.
artifactregistry.repositories.downloadArtifacts	יכולים להוריד ארטיפקטים ממאגר ב-Artifact Registry
artifactregistry.aptartifacts.create	אפשר להעלות פריטי מידע שנוצרו בתהליך פיתוח (Artifact) מסוג Apt אל Artifact Registry
artifactregistry.dockerimages.get	אפשר לקבל קובצי אימג' של Docker מ-Artifact Registry
artifactregistry.dockerimages.list	יכול לרשום תמונות Docker שמאוחסנות ב-Artifact Registry
artifactregistry.kfpartifacts.create	אפשר להעלות ארטיפקט של KFP אל Artifact Registry
artifactregistry.locations.get	יכול לקבל מידע על מיקום של משאב ב-Artifact Registry
artifactregistry.locations.list	יכול לפרט את המיקומים הנתמכים ב-Artifact Registry
artifactregistry.mavenartifacts.get	אפשר לקבל חבילות Maven מ-Artifact Registry
artifactregistry.mavenartifacts.list	אפשר להציג רשימה של חבילות Maven מ-Artifact Registry
artifactregistry.npmpackages.get	אפשר לקבל חבילות npm מ-Artifact Registry
artifactregistry.npmpackages.list	אפשר להציג רשימה של חבילות npm מ-Artifact Registry
artifactregistry.projectsettings.get	אפשר לקבל את הגדרות הפרויקט מ-Artifact Registry
artifactregistry.pythonpackages.get	אפשר לקבל חבילות Python מ-Artifact Registry
artifactregistry.pythonpackages.list	יכול להציג רשימה של חבילות Python מ-Artifact Registry
artifactregistry.yumartifacts.create	יכול להעלות ארטיפקטים של Yum ל-Artifact Registry
artifactregistry.repositories.createOnPush	אפשר ליצור מאגר gcr.io ב-Artifact Registry בפעם הראשונה שדוחפים תמונה למארח gcr.io בפרויקט.
artifactregistry.repositories.get	אפשר לקבל מאגר מ-Artifact Registry
artifactregistry.repositories.list	יכול לראות רשימה של מאגרים ב-Artifact Registry
artifactregistry.repositories.listEffectiveTags	יכול לראות רשימה של תגים של פריטי מידע שנוצרו בתהליך פיתוח (Artifact) ב-Artifact Registry	נדרשת הרשאה לניהול תגים של ארטיפקטים ב-Artifact Registry.
artifactregistry.repositories.listTagBindings	אפשרות לראות רשימה של פרטי קישור בין תגים לפריטי מידע שנוצרו בתהליך פיתוח (Artifact) ב-Artifact Registry
artifactregistry.tags.create	יכולים ליצור תגים ב-Artifact Registry
artifactregistry.tags.get	אפשר לקבל תגים מ-Artifact Registry
artifactregistry.tags.list	יכול לראות רשימה של תגים ב-Artifact Registry
artifactregistry.tags.update	אפשר לעדכן תגים ב-Artifact Registry
artifactregistry.versions.list	אפשר להציג רשימה של גרסאות ב-Artifact Registry
artifactregistry.versions.get	אפשר לקבל גרסאות ב-Artifact Registry
containeranalysis.occurrences.create	יכולים ליצור מופע של ניתוח ארטיפקטים	חשבון השירות של Cloud Build לא משתמש בהרשאות האלה, אבל הן כלולות לצורך תאימות לאחור.
containeranalysis.occurrences.delete	אפשר למחוק מופע של ניתוח פריט מידע שנוצר בתהליך פיתוח (Artifact)
containeranalysis.occurrences.get	יכול לקבל מופע של Artifact Analysis
containeranalysis.occurrences.list	יכולים לראות את המקרים של Artifact Analysis
containeranalysis.occurrences.update	אפשר לעדכן מקרים של Artifact Analysis

טריגרים לפיתוח גרסת Build

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

גישת משתמשים לטריגרים

הגישה של המשתמשים לטריגרים תלויה בסוג חשבון השירות שהוגדר לטריגר:

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

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

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

  הערה: אם אתם משתמשים באותו חשבון שירות כדי להפעיל ולבצע בנייה, לחשבון השירות הזה עדיין צריכה להיות ההרשאה iam.serviceAccount.actAs.

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

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

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

• אם אתם משתמשים בטריגרים של בקשות משיכה ב-GitHub, כל משתמש עם גישת קריאה למאגר יכול לשלוח בקשת משיכה, שעשויה להפעיל בנייה שכוללת שינויים בקוד בבקשת המשיכה. כדי להשבית את ההתנהגות הזו, בוחרים באפשרות Comment control כשיוצרים טריגר של בקשת משיכה ב-GitHub. אם בוחרים באפשרות הזו, הגרסה תתחיל רק אם הבעלים של המאגר או שותף עריכה יכתוב תגובה עם הסמל /gcbrun. מידע על שימוש בComment control עם GitHub triggers זמין במאמר יצירת GitHub triggers.

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

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

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

  הוראות מפורטות מופיעות במאמר בנושא הרשאת גישה משירות לשירות.

• אי אפשר להוסיף קישור למדיניות IAM בחשבון שירות מדור קודם. לדוגמה, אי אפשר ליצור קישור למדיניות IAM שמעניק לחשבון שירות אחר את התפקיד roles/iam.serviceAccountTokenCreator ב חשבון השירות מדור קודם.

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

• מידע נוסף על חשבונות שירות שמוגדרים על ידי המשתמש
• מידע נוסף על הגדרת גישה לחשבון השירות שמוגדר כברירת מחדל ב-Cloud Build
• מידע נוסף על הגדרת גישה למשאבי Cloud Build
• מידע על ההרשאות שנדרשות כדי לראות את יומני הבנייה