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

בעזרת Cloud Build אפשר להגדיר מדיניות ארגון (constraints/cloudbuild.allowedIntegrations) כדי לקבוע אילו שירותים חיצוניים יכולים להפעיל טריגרים של build. לדוגמה, אם הטריגר מאזין לשינויים במאגר GitHub, ו-GitHub נדחה במדיניות הארגון, הטריגר לא יפעל. אתם יכולים לציין כל מספר של ערכים מותרים או אסורים לארגון או לפרויקט.

בדף הזה מוסבר איך להגדיר את מדיניות הארגון (constraints/cloudbuild.allowedIntegrations) לשילובים באמצעות מסוף Google Cloud וכלי שורת הפקודה gcloud.

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

• מפעילים את Cloud Build API ואת Organization Policy API.

  תפקידים שנדרשים להפעלת ממשקי API

  כדי להפעיל ממשקי API, נדרשת ההרשאה serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד 'בעלים' (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד 'אדמין בממשק 'שימוש בשירות'' (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידים

  הפעלת ממשקי ה-API

• כדי להשתמש בדוגמאות של שורת הפקודה במדריך הזה, צריך להתקין ולהגדיר את Google Cloud SDK.

  הערה: אם התקנתם בעבר את Google Cloud SDK, צריך לוודא שפועלת אצלכם הגרסה העדכנית ביותר של gcloud components update.

• כדי להגדיר, לשנות או למחוק מדיניות ארגונית, צריך להיות לכם התפקיד 'אדמין מדיניות ארגונית' (roles/orgpolicy.policyAdmin). כאן אפשר לקרוא איך מוסיפים את התפקיד לחשבון.

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

בקטע הזה מוסבר איך להגדיר את מדיניות הארגון (constraints/cloudbuild.allowedIntegrations) כדי להגדיר גרסאות build לשילובים מותרים.

המסוף

1. פותחים את הדף מדיניות הארגון במסוף Google Cloud .

   פתיחת הדף מדיניות הארגון

2. לוחצים על השורה שמכילה את המדיניות Allowed Integrations (Cloud Build) (שילובים מותרים (Cloud Build)).

   יוצג הדף פרטי המדיניות.

3. כדי לערוך את המדיניות, לוחצים על עריכה.

   יוצג הדף עריכת מדיניות.

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

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

6. בקטע כללים, לוחצים על הוספת כלל כדי להוסיף כלל חדש למדיניות.

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

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

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

   2. בקטע Custom values (ערכים בהתאמה אישית), מזינים את כתובת ה-URL של המארח של המופע או המאגר שרוצים לאפשר או לחסום את הבנייה שלהם. לדוגמה, כדי לאפשר או לדחות גרסאות build מ-GitHub, מזינים את כתובת ה-URL כ-github.com או כ-www.github.com.

      אפשר גם להזין כמה כתובות URL ולהפריד ביניהן באמצעות רווח. לדוגמה, github.com ghe.staging-test.com.

      בהתאם לאירוע, כתובת ה-URL של המארח שאתם מציינים היא אחת מהאפשרויות הבאות:

      • אירוע RepoSync: המארח הוא source.developers.google.com.
      • אירוע באפליקציית GitHub: המארח נגזר מהשדה repository.html_url במטען הייעודי (payload) של JSON, שתמיד יהיה github.com.
      • אירוע GitHub Enterprise: המארח נגזר מהשדה repository.html_url במטען הייעודי (payload) של JSON. לדוגמה, ghe.staging-test.com.
      • אירוע Pub/Sub: המארח נגזר מהמקור שצוין בטריגר. אם לא צוין מקור בטריגר, לא תתבצע בדיקה של מדיניות הארגון.
      • אירוע Webhook: המארח נגזר מהמקור שצוין בטריגר. אם לא צוין מקור בטריגר, לא תתבצע בדיקה של מדיניות הארגון.
      הערה: בקטע ערכים מותאמים אישית אפשר להזין כל תו, חוץ מנקודתיים (:) ולוכסנים (/).

8. כדי לשמור את הכלל, לוחצים על סיום.

9. כדי להוסיף עוד כלל, לוחצים על הוספת כלל. אחרת, לוחצים על שמירה כדי לשמור את המדיניות.

gcloud

1. פותחים חלון טרמינל.

2. כדי לאשר או לדחות בנייה מכל השירותים, יוצרים קובץ YAML עם התוכן הבא:

   name: projects/PROJECT_NUMBER/policies/cloudbuild.allowedIntegrations
   spec:
     inheritFromParent: INHERIT
     rules:
       - ALLOW_OR_DENY: true
   

   כאשר:

   • ‫PROJECT_NUMBER הוא מספר הפרויקט.
   • ‫INHERIT הוא true אם רוצים שהכללים של המדיניות יועברו בירושה ממשאב ההורה. אחרת, false.
   • ‫ALLOW_OR_DENY הוא allowAll אם רוצים לאפשר בנייה מכל כתובות ה-URL של המארחים. אחרת, denyAll.
   • ‫HOST_URL היא כתובת ה-URL של המארח. לדוגמה, github.com. אפשר גם לציין כתובות URL נוספות בשורות הבאות.

   כדי לאשר או לדחות build משירותים נבחרים, יוצרים קובץ YAML עם התוכן הבא:

   name: projects/PROJECT_NUMBER/policies/cloudbuild.allowedIntegrations
   spec:
     inheritFromParent: INHERIT
     rules:
       - values:
           ALLOW_OR_DENY:
             HOST_URL
             ...
   

   כאשר:

   • ‫PROJECT_NUMBER הוא מספר הפרויקט.
   • ‫INHERIT הוא true אם רוצים שהכללים של המדיניות יועברו בירושה ממשאב ההורה. אחרת, false.
   • ‫ALLOW_OR_DENY היא allowedValues אם רוצים לציין כתובות URL של מארחים שמהם מותר לבצע בנייה. אחרת, deniedValues.
   • ‫HOST_URL היא כתובת ה-URL של המארח. לדוגמה, github.com. אפשר גם לציין כתובות URL נוספות בשורות הבאות.
   הערה: אפשר להשתמש בכל התווים כשמציינים את כתובת ה-URL של המארח, חוץ מנקודתיים (:) ולוכסנים (/).

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

    gcloud org-policies set-policy FILE_NAME
   

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

    gcloud org-policies describe cloudbuild.allowedIntegrations --effective --project PROJECT_ID
   

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

בקטע הזה מוסבר איך אפשר לבדוק את מדיניות הארגון (constraints/cloudbuild.allowedIntegrations) באמצעות טריגרים של בנייה.

1. אם עדיין לא עשיתם זאת, יוצרים טריגר לבנייה.

2. שולחים שינוי למקור.

3. אם המדיניות שלכם מוגדרת כך שניתן ליצור גרסאות build מהמקור, תוכלו לראות את ההרצות של ה-build מהטריגר בדף Build history. אחרת, הבנייה לא תתבצע. כדי לראות את ההיסטוריה של בניית תמונות שמוגבלות על ידי הגדרת המדיניות, אפשר לעיין בדף Logs Explorer כדי לראות את הסיבה למטען ה-JSON ואת הסיבה לדחייה.

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

• איך יוצרים ומנהלים טריגרים לבנייה
• איך מגבילים את הגישה לבנייה עד לאישור
• מידע נוסף על ההרשאות שנדרשות כדי לראות את יומני הבנייה
• מידע על יומני ביקורת שנוצרו על ידי Cloud Build