שימוש ב-VPC Service Controls

‫VPC Service Controls הוא תכונה שמאפשרת להגדיר מתחם אבטחה היקפית כדי להגן מפני זליגת נתונים. Google Cloud בדף הזה מוסבר איך להשתמש ב-VPC Service Controls עם מאגרי עובדים פרטיים של Cloud Build כדי להוסיף אבטחה נוספת לתהליכי הבנייה.

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

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

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

• הגדרת חיבור פרטי בין רשת הענן הווירטואלי הפרטי (VPC) לבין רשת ה-VPC שבה נמצאים המאגרים הפרטיים. הוראות מפורטות זמינות במאמר בנושא הגדרת הסביבה ליצירת מאגרי כתובות פרטיים.

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

  • כדי לאחסן את יומני הבנייה ב-Cloud Logging, מגדירים את loggingMode ל-CLOUD_LOGGING_ONLY.
  • בפרויקט הפרטי, יוצרים קטגוריה של יומנים ב-Cloud Storage כדי לאחסן את יומני הבנייה. מידע נוסף זמין במאמר בנושא אחסון יומני בנייה בדלי שנוצר על ידי משתמש.
  • כדי להשבית את יומני הבנייה, מגדירים את loggingMode ל-NONE.

• אם תהליכי ה-build שלכם דוחפים תמונות וארטיפקטים ל-Artifact Registry או ל-Cloud Storage בפרויקט אחר Google Cloud , צריך להוסיף את הפרויקט הזה לאותו גבול גזרה לשירות כמו הפרויקט שממנו נובעים תהליכי ה-build.

• אופציונלי: כדאי לעיין בהגדרות של סוגי המכונות ובזמינות האזורית. מידע נוסף זמין במאמר בנושא workerconfig בסכימת קובץ ההגדרות של מאגר פרטי.

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

• צפייה בארגון (roles/resourcemanager.organizationViewer)
• עריכה ב-Access Context Manager (roles/accesscontextmanager.policyEditor)

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

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

הגדרת מאגר פרטי בהיקף האבטחה של VPC Service Controls

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

יצירה של service perimeter ב-VPC Service Controls

פועלים לפי המדריך לתחילת העבודה עם VPC Service Controls כדי:

1. יוצרים גבולות גזרה לשירות.

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

   הערה: אם אתם משתמשים ב-VPC משותף, הקפידו להוסיף את הפרויקט המארח ואת פרויקטי השירות לאותם גבולות גזרה.

3. מגבילים את Cloud Build API.

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

מתן גישה לחשבון השירות למערך של VPC Service Controls

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

במקרים הבאים, צריך לתת לחשבון השירות מדור קודם של Cloud Build או Compute Engine גישה לגבולות הגזרה של VPC Service Controls כדי שה-Build יוכל לגשת למשאבים בתוך גבולות הגזרה:

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

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

אם אתם משתמשים בחשבונות שירות שהוגדרו על ידי המשתמש כדי להתחיל בנייה באמצעות Cloud Build API או שורת הפקודה, אתם לא צריכים להעניק לחשבון השירות מדור קודם של Cloud Build או Compute Engine גישה להיקף של VPC Service Controls.

כדי לתת לחשבון השירות מדור קודם של Cloud Build או Compute Engine גישה לגבולות הגזרה של VPC Service Controls, מבצעים את השלבים הבאים:

1. רושמים את כתובת האימייל של חשבון השירות מדור קודם:

   1. פותחים את דף IAM:

      פתיחת הדף IAM

   2. בוחרים את הפרויקט שהוספתם לגבולות גזרה לשירות.

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

2. מעדכנים את מדיניות הכניסה של גבולות גזרה לשירות כדי לאפשר לחשבון השירות לקרוא ל-Cloud Build APIs. כלל הכניסה הזה מאפשר לחשבון השירות לבצע את קריאה ל-API‏ CreateBuild. מידע נוסף על הגדרת מדיניות של VPC Service Controls לתעבורת נתונים נכנסת זמין במאמרים הגדרת מדיניות לתעבורת נתונים נכנסת ויוצאת וכללים לתעבורת נתונים נכנסת ויוצאת.

   - ingressFrom:
       identities:
       - serviceAccount:SERVICE_ACCOUNT_EMAIL
       sources:
       - accessLevel: '*'
     ingressTo:
       operations:
       - serviceName: 'cloudbuild.googleapis.com'
         methodSelectors:
         - method: '*'
       resources:
       - 'projects/PROJECT_NUMBER'
   

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

   gcloud beta access-context-manager perimeters update PERIMETER_NAME \
       --set-ingress-policies=INGRESS-FILENAME \
       --policy=POLICY_ID
   

כאשר:

• ‫SERVICE_ACCOUNT_EMAIL: כתובת האימייל של חשבון השירות.
• ‫PROJECT_NUMBER: מספר הפרויקט שלGoogle Cloud הפרויקט שהוספתם להיקף של VPC Service Controls.
• ‫PERIMETER_NAME: השם של היקף האבטחה של VPC Service Controls.
• ‫INGRESS-FILENAME: השם של קובץ מדיניות הכניסה.
• ‫POLICY_ID: המזהה של מדיניות הגישה.

אופציונלי: הפעלת גישה היקפית למכונות פיתוח

בגלל שבדיקות של VPC Service Controls נאכפות ב-Cloud Build API, קריאות ל-Cloud Build API נכשלות אלא אם הן מגיעות מתוך גבולות גזרה לשירות. לכן, כדי לנהל את תהליכי הבנייה באמצעות Cloud Build API, ממשק המשתמש של Cloud Build במסוף Google Cloud או Google Cloud CLI, צריך לבחור אחת מהאפשרויות הבאות:

• משתמשים במכונה בתוך גבולות הגזרה של VPC Service Controls. לדוגמה, אתם יכולים להשתמש במכונה וירטואלית של Compute Engine או במכונה מקומית שמחוברת לרשת ה-VPC שלכם באמצעות VPN.

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

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

כדי לוודא שהבדיקות של VPC Service Controls נאכפות בצורה נכונה ושאתם מגבילים את הבנייה בארגון Google Cloud כך שניתן יהיה להשתמש רק במאגרי ה-IP הפרטיים שצוינו, צריך להגדיר את constraints/cloudbuild.allowedWorkerPools אילוץ מדיניות הארגון. אפשר להחיל את מדיניות הארגון על כל הארגון, או על פרויקט או תיקייה בארגון. לדוגמה, במדיניות הארגון אפשר לציין את הדברים הבאים:

• כל הבנייה בארגון משתמשת במאגרי ה-IP הפרטיים שצוינו.
• כל הבנייה בתיקייה משתמשת במאגרי המשאבים הפרטיים שצוינו.
• כל הבנייה בפרויקט משתמשת במאגרים הפרטיים שצוינו.

הרשאות IAM: כדי לנהל את מדיניות הארגון, צריך את התפקיד Organization Policy Administrator (אדמין של מדיניות הארגון) (roles/orgpolicy.policyAdmin). הוראות להקצאת תפקיד מופיעות במאמר הגדרת גישה למשאבי Cloud Build.

הפקודה gcloud resource-manager org-policies allow מגדירה מדיניות ארגונית שדורשת שה-build בארגון ישתמש רק במאגר הפרטי שצוין:

 gcloud resource-manager org-policies allow \
     cloudbuild.allowedWorkerPools \
     projects/PRIVATEPOOL_PROJECT_ID/locations/LOCATION/workerPools/PRIVATEPOOL_ID \
     --organization ORGANIZATION_ID

כאשר:

• ‫PRIVATEPOOL_ID: המזהה של המאגר הפרטי להרצת בנייה.

• ‫PRIVATEPOOL_PROJECT_ID: המזהה של Google Cloud הפרויקט שמכיל את המאגר הפרטי.

• ‫LOCATION: האזור שמכיל את המאגר הפרטי.

• ‫ORGANIZATION_ID: המזהה של הארגון שבו מריצים את הבנייה.

הפקודה תומכת בקידומות under: ו-is.

כדי להגדיר מדיניות ארגונית שדורשת שכל ה-build בארגון ישתמשו בכל מאגר פרטי בארגון:

 gcloud resource-manager org-policies allow \
     cloudbuild.allowedWorkerPools under:organizations/ORGANIZATION_ID \
     --organization ORGANIZATION_ID

כאשר ORGANIZATION_ID הוא המזהה של הארגון שמכיל את המאגרים הפרטיים.

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

 gcloud resource-manager org-policies allow \
     cloudbuild.allowedWorkerPools under:projects/PROJECT_ID \
     --folder FOLDER_ID

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

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

 gcloud resource-manager org-policies allow \
     cloudbuild.allowedWorkerPools under:projects/PRIVATEPOOL_PROJECT_ID \
     --project BUILD_PROJECT_ID

כאשר PRIVATEPOOL_PROJECT_ID הוא מזהה הפרויקט שמכיל את המאגרים הפרטיים, ו-BUILD_PROJECT_ID הוא מזהה הפרויקט שבו מריצים את הבנייה.

כשמפעילים את האילוץ constraints/cloudbuild.allowedWorkerPools של מדיניות הארגון, חשוב לקחת בחשבון את הנקודות הבאות:

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

• אם הארגון שלכם מכיל שירותים כמו App Engine או פונקציות Cloud Run שמשתמשים ב-Cloud Build באופן מרומז, אכיפה של האילוץ הזה במדיניות הארגון עלולה לגרום לכך שהשירותים האלה לא יפעלו כמצופה. Google Cloud

יצירת מאגר פרטי בתוך גבולות גזרה לשירות

מסוף Google Cloud

1. פותחים את הדף Worker Pool במסוף Google Cloud :

   פתיחת הדף של מאגר העובדים של Cloud Build

2. לוחצים על יצירת מאגר פרטי.

   מוצג הדף Create private pool.

   מזינים את הפרטים הבאים כדי ליצור מאגר פרטי:

3. שם: מזינים שם למאגר הפרטי. הערך הזה יכול להכיל רק תווים אלפאנומריים /[a-z][0-9]/ או מקפים -. שם המאגר הפרטי צריך לכלול בין 1 ל-63 תווים.

4. אזור: בוחרים את האזור שבו רוצים ליצור את המאגר הפרטי.

5. Machine configuration: מגדירים את האפשרויות הבאות:

   1. סדרה: בוחרים סדרת מכונות.

   2. Machine type: ההגדרה הזו מציגה את סוגי המכונות, על סמך סדרת המכונות שבחרתם, שמאגר העובדים יכול להשתמש בהם. סוגי המכונות הזמינים משתנים בהתאם לאזור.

   3. גודל הדיסק: מזינים את גודל הדיסק של המאגר הפרטי. מציינים ערך שגדול מ-100 או שווה לו, וקטן מ-4,000 או שווה לו. אם לא מציינים ערך, Cloud Build משתמש בגודל דיסק של 100.

   4. וירטואליזציה מקוננת: אם בחרתם במכונה מסדרת C3, תוכלו להפעיל וירטואליזציה מקוננת. התכונה הזו מאפשרת להריץ מופעים של מכונות וירטואליות (VM) בתוך מכונות וירטואליות אחרות, כדי ליצור סביבות וירטואליזציה משלכם.

6. בקטע Network type (סוג הרשת), בוחרים באפשרות Private network (רשת פרטית) ואז בוחרים באפשרויות הבאות:

   1. Project: בוחרים את מזהה הפרויקט ב- Google Cloud .

   2. רשת: בוחרים את הרשת מהתפריט הנפתח. אם לא יצרתם רשת, במאמר יצירה וניהול של רשתות VPC מוסבר איך ליצור רשת.

   3. טווח כתובות IP: מזינים את טווח כתובות ה-IP הפנימיות שרשת היצרן של Cloud Build יכולה להקצות למכונות וירטואליות שמנהלות חיבור למאגרים פרטיים.

      אפשר לציין את הטווח באמצעות סימון ניתוב Classless Inter-Domain Routing‏ (CIDR) בפורמט STARTING_IP_ADDRESS/SUBNET_PREFIX_SIZE. לדוגמה, ל-192.0.2.0/24 יש אורך קידומת של 24. ‫24 הביטים הראשונים של טווח כתובות ה-IP משמשים כמסכה של רשת משנה (192.0.2.0), וטווח כתובות המארחים האפשריות הוא מ-192.0.2.0 עד 192.0.2.255.

      הערך של אורך הקידומת לא יכול להיות גדול מ-/29. אם לא מציינים ערך לטווח, מוקצה אוטומטית ערך ברירת מחדל של /24. אם לא מציינים ערך לאורך הקידומת, כתובות ה-IP מוקצות באופן אוטומטי ברשת ה-VPC המקושרת. אם לא מציינים ערך לכתובת ה-IP, המערכת מקצה לכתובת ה-IP באופן אוטומטי טווח ברשת ה-VPC המקושרת.

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

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

7. לוחצים על יצירה כדי ליצור את המאגר הפרטי.

gcloud

1. יוצרים קובץ הגדרות של מאגר פרטי בפורמט YAML או JSON, ומגדירים את הדגל egressOption לערך NO_PUBLIC_EGRESS:

   privatePoolV1Config:
     networkConfig:
       egressOption: NO_PUBLIC_EGRESS
       peeredNetwork: PEERED_NETWORK
     workerConfig:
       diskSizeGb: 'PRIVATE_POOL_DISK_SIZE'
       machineType: PRIVATE_POOL_MACHINE_TYPE
   

   כאשר:

   • ‫PEERED_NETWORK היא כתובת ה-URL של משאב הרשת של הרשת שמקושרת לרשת של ספק השירות. הפורמט של PEERED_NETWORK הוא projects/NETWORK_PROJECT_ID/global/networks/NETWORK_NAME, כאשר NETWORK_PROJECT_ID הוא מזהה הפרויקט של פרויקט Google Cloud שמכיל את רשת ה-VPC, ו-NETWORK_NAME הוא השם של רשת ה-VPC.
   • ‫PRIVATE_POOL_MACHINE_TYPE הוא סוג המכונה של Compute Engine למופע של מאגר פרטי. לרשימת סוגי המכונות הנתמכים, אפשר לעיין במאמר סכימת קובץ ההגדרות של מאגר פרטי.
   • ‫PRIVATE_POOL_DISK_SIZE הוא גודל הדיסק של מופע מאגר פרטי ב-GB. מציינים ערך שגדול מ-100 או שווה לו, וקטן מ-1,000 או שווה לו. אם מציינים 0, ‏ Cloud Build משתמש בערך ברירת המחדל 100.
   • ‫egressOption הוא הדגל להפעלת גבולות גזרה של VPC Service Controls למאגר הפרטי שלכם. מגדירים את הערך הזה ל-NO_PUBLIC_EGRESS כדי ליצור את המאגר הפרטי בתוך ההיקף של אמצעי הבקרה של שירות ה-VPC.

2. מריצים את הפקודה הבאה gcloud, כאשר PRIVATEPOOL_ID הוא מזהה ייחודי של המאגר הפרטי, PRIVATEPOOL_CONFIG_FILE הוא שם קובץ ההגדרות של המאגר הפרטי ו-REGION הוא האזור שבו רוצים ליצור את המאגר הפרטי:

   gcloud builds worker-pools create PRIVATEPOOL_ID --config-from-file PRIVATEPOOL_CONFIG_FILE --region REGION
   

אופציונלי: הפעלת שיחות טלפון באינטרנט ברשת ה-VPC

כדי לאפשר לרשת ה-VPC שלכם קישוריות לרשת שבה מאוחסן המאגר (למשל github.com), צריך להגדיר את שני ההגדרות הבאות:

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

• מבצעים אחת מהפעולות הבאות:

  • מגדירים את השדה egressOption בקובץ ההגדרות של המאגר הפרטי לערך PUBLIC_EGRESS.

  • הגדרה של מאגרי כתובות IP פרטיות לשימוש בכתובת IP חיצונית סטטית.

מגבלות

• ההגנה של VPC Service Controls זמינה רק לבנייה שמופעלת במאגרי משאבים פרטיים. אי אפשר להשתמש ב-VPC Service Controls עם בנייה שמופעלת במאגרי משאבים שמוגדרים כברירת מחדל.

• טריגרים של Cloud Build Pub/Sub לא נתמכים כשמשתמשים ב-VPC Service Controls.

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

• איך מריצים בנייה במאגרי משאבים פרטיים
• איך מגדירים תרחישי שימוש נפוצים ברשת