הכנת הסביבה

לפני שיוצרים צינור Image Builder, צריך קודם להכין את סביבת Cloud de Confiance . כדי להכין את הסביבה, צריך לבצע את המשימות הבאות:

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

  • אם עדיין לא עשיתם את זה, תצטרכו להגדיר אימות. אימות הוא תהליך שבו מאמתים את הזהות שלכם כדי לקבל גישה לממשקי API ולשירותים של Cloud de Confiance by S3NS . כדי להריץ קוד או דוגמאות מסביבת פיתוח מקומית, אפשר לבצע אימות ל-Compute Engine באחת מהדרכים הבאות:

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

    המסוף

    כשמשתמשים במסוף Cloud de Confiance כדי לגשת לשירותים Cloud de Confiance by S3NS ולממשקי ה-API, לא צריך להגדיר אימות.

    gcloud

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

      gcloud init
  • הגדרת אזור ותחום כברירת מחדל

    • REST

    כדי להשתמש בסביבת פיתוח מקומית בדוגמאות של API בארכיטקטורת REST שבדף הזה, צריך להשתמש בפרטי הכניסה שאתם נותנים ל-CLI של gcloud.

      התקינו את ה-CLI של Google Cloud ואז היכנסו ל-CLI של gcloud באמצעות הזהות המאוחדת שלכם.

    מידע נוסף מופיע במאמר אימות לשימוש ב-REST במסמכי האימות של Cloud de Confiance .

התפקידים הנדרשים

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

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

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

בקשה להצטרפות

‫Image Builder זמין לכלל המשתמשים עם רשימת היתרים. כדי להוסיף את Cloud de Confiance הפרויקט שלכם לצינור להתאמה אישית של תמונות, צריך לשלוח את טופס בקשת הגישה או לפנות לצוות Cloud de Confiance ניהול החשבון שלכם.

חשבונות שירות שכלולים ברשימת ההיתרים

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

  • חשבונות שירות בניהול המשתמשים שאתם יוצרים בפרויקט.
  • חשבונות שירות שמוגדרים כברירת מחדל ש- Cloud de Confiance יוצר בפרויקט, כמו חשבון השירות שמוגדר כברירת מחדל ב-Compute Engine‏ (PROJECT_NUMBER-compute@developer.s3ns-system.iam.gserviceaccount.com).

רשימת ההיתרים לא כוללת חשבונות שירות בבעלות Google, כיCloud de Confiance יוצרת את חשבונות השירות האלה בפרויקטים בבעלות Google ולא בפרויקט שלכם. חשבונות שירות בבעלות Google כוללים את הדברים הבאים:

  • סוכני שירות, כמו service-PROJECT_NUMBER@gcp-sa-SERVICE.s3ns-system.iam.gserviceaccount.com.
  • חשבון השירות מדור קודם של Cloud Build (PROJECT_NUMBER@cloudbuild.s3ns-system.iam.gserviceaccount.com), שנמצא בבעלות של Google ומנוהל על ידה.

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

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

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

כדי להשתמש ב-Image Builder, צריך להפעיל את ממשקי ה-API של Compute Engine, ‏ Cloud Build, ‏ Artifact Registry, ‏ Service Usage ומנהל המשאבים. כדי להפעיל את ממשקי ה-API באמצעות מסוף Cloud de Confiance או Google Cloud CLI, בוחרים באחת מהכרטיסיות הבאות:

המסוף

מפעילים את ממשקי ה-API של Compute Engine,‏ Cloud Build,‏ Artifact Registry,‏ Service Usage ו-Cloud Resource Manager, אם אחד מהם לא מופעל.

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

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

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

gcloud

מפעילים את ממשקי ה-API של Compute Engine,‏ Cloud Build,‏ Artifact Registry,‏ Service Usage ו-Cloud Resource Manager, אם הם עדיין לא הופעלו:

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

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

gcloud services enable compute.googleapis.com cloudbuild.googleapis.com artifactregistry.googleapis.com serviceusage.googleapis.com cloudresourcemanager.googleapis.com

הגדרת חשבון השירות של Image Builder

הכלי Image Builder Orchestrator פועל באמצעות חשבון שירות שמנוהל על ידי משתמש. כשמריצים צינור עיבוד נתונים ליצירת תמונה, Cloud Build מצרף את חשבון השירות הזה למכונות וירטואליות זמניות של עובדים ולמכונות וירטואליות לבדיקה כדי לבצע פעולות התאמה אישית ואימות. לחשבון השירות הזה צריך להקצות את התפקידים הבאים:

  • אדמין של Compute (roles/compute.admin): ניהול של מופעים של מכונות וירטואליות, דיסקים מתמידים ותמונות של מערכות הפעלה אורחות.
  • משתמש בחשבון שירות (roles/iam.serviceAccountUser): מאפשר ל-Cloud Build לצרף את חשבון השירות למכונות וירטואליות זמניות של עובדים ומכונות וירטואליות לבדיקה.
  • אדמין אחסון (roles/storage.admin): קורא וכותב ארטיפקטים ויומנים זמניים של בנייה בקטגוריית ההכנה workdir ב-Cloud Storage.
  • ‫Logging Log Writer (roles/logging.logWriter): כתיבת יומני ביצוע ל-Cloud Logging.
  • צפייה בשימוש בשירות (roles/serviceusage.serviceUsageViewer): בודק את מצבי השירות בפרויקט במהלך ההפעלה של צינור עיבוד הנתונים.
  • Cloud Build Editor (roles/cloudbuild.builds.editor): מפעיל ומריץ משימות של Cloud Build ומייצא תמונות.
  • (אופציונלי) אדמין של Artifact Registry (roles/artifactregistry.admin): העלאה של קובצי tar של תמונות מערכת הפעלה שנוצרו אל Artifact Registry.

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

כדי ליצור חשבון שירות ייעודי חדש ולהעניק את התפקידים הנדרשים באמצעות מסוף Cloud de Confiance או ה-CLI של gcloud, בוחרים באחת מהכרטיסיות הבאות:

המסוף

    מוודאים שיש לכם את תפקיד ה-IAM 'יצירת חשבונות שירות' (roles/iam.serviceAccountCreator) ואת התפקיד 'אדמין IAM בפרויקט' (roles/resourcemanager.projectIamAdmin). איך מקצים תפקידים

  1. במסוף Cloud de Confiance , נכנסים לדף יצירת חשבון שירות.

    כניסה לדף Create service account
  2. בוחרים את הפרויקט הרצוי.

  3. כותבים שם בשדה Service account name. המסוף Cloud de Confiance ממלא את השדה מזהה חשבון שירות בהתאם לשם הזה.

    כותבים תיאור בשדה Service account description. לדוגמה: Service account for quickstart.

  4. לוחצים על Create and continue.

  5. נותנים לחשבון השירות את התפקידים הבאים: Compute Engine > Compute Admin, Service Accounts > Service Account User, Cloud Storage > Storage Admin, Cloud Logging > Logs Writer, Service Usage > Service Usage Viewer, Cloud Build > Cloud Build Editor, Artifact Registry > Artifact Registry Admin.

    כדי להקצות תפקיד, בוחרים תפקיד מהרשימה Select a role.

    כדי להקצות עוד תפקידים, לוחצים על Add another role ומוסיפים את כולם.

  6. לוחצים על Continue.

  7. בשדה Service account users role, מזינים את המזהה של חשבון המשתמש שיצרף את חשבון השירות למשאבים אחרים, כמו מכונות של Compute Engine.

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

  8. לוחצים על Done כדי לסיים ליצור את חשבון השירות.

gcloud

  1. יוצרים חשבון שירות לצינור עיבוד הנתונים לבנייה:

    gcloud iam service-accounts create SERVICE_ACCOUNT_NAME \
    --display-name="Image Builder Service Account"

  2. מקצים את התפקידים הנדרשים (roles/compute.admin, ‏roles/iam.serviceAccountUser, ‏roles/storage.admin, ‏roles/logging.logWriter, ‏roles/serviceusage.serviceUsageViewer ו-roles/cloudbuild.builds.editor) לחשבון השירות:

    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:SERVICE_ACCOUNT_EMAIL" \
    --role="roles/compute.admin"

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:SERVICE_ACCOUNT_EMAIL" \
    --role="roles/iam.serviceAccountUser"

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:SERVICE_ACCOUNT_EMAIL" \
    --role="roles/storage.admin"

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:SERVICE_ACCOUNT_EMAIL" \
    --role="roles/logging.logWriter"

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:SERVICE_ACCOUNT_EMAIL" \
    --role="roles/serviceusage.serviceUsageViewer"

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:SERVICE_ACCOUNT_EMAIL" \
    --role="roles/cloudbuild.builds.editor"

  3. אופציונלי: מקצים את התפקיד האופציונלי (roles/artifactregistry.admin) לחשבון השירות:

    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:SERVICE_ACCOUNT_EMAIL" \
    --role="roles/artifactregistry.admin"

מחליפים את מה שכתוב בשדות הבאים:

  • ‫SERVICE_ACCOUNT_NAME: השם של חשבון השירות של ה-build שרוצים ליצור. לדוגמה, custom-builder-sa.
  • ‫PROJECT_ID: מזהה הפרויקט ב- Cloud de Confiance .
  • SERVICE_ACCOUNT_EMAIL: כתובת האימייל של חשבון השירות שלכם לבנייה.

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

מכיוון ש-Image Builder משתמש באופן פנימי בכלים סטנדרטיים לייבוא ולייצוא של תמונות מ-Compute Engine במהלך ביצוע הבנייה, במדיניות התמונות המהימנות של הפרויקט (compute.trustedImageProjects) צריך לאפשר באופן מפורש תמונות מהפרויקט הבא:

  • projects/compute-image-import

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

כדי לעדכן את מדיניות הארגון:

  1. במדיניות הארגון, באילוץ compute.trustedImageProjects, מוסיפים את projects/compute-image-import לרשימת המפיצים המורשים.
  2. הוראות מפורטות להגדרת אילוצים של מדיניות הארגון זמינות במאמרים הגדרת מדיניות של תמונות מהימנות וייצוא תמונה בהתאמה אישית ל-Cloud Storage.

הגדרת רשת VPC ודרישות גישה

במהלך שלבי הפיתוח והאימות, Image Builder מקצה מכונות וירטואליות זמניות של עובדים ובדיקות ב Cloud de Confiance פרויקט. כברירת מחדל, Image Builder מחבר מכונות לרשת ה-VPC ‏default ומקצה כתובות IP חיצוניות ארעיות.

אם מציינים network או subnetwork מותאמים אישית, או מגדירים externalIP: none בקובץ המתכון imagebuilder.yaml:

  • גישה פרטית ל-Google ו-Cloud NAT: אם מכונות וירטואליות של worker או של בדיקות מוגדרות עם externalIP: none (ללא כתובת IP חיצונית), צריך להפעיל גישה פרטית ל-Google ברשת המשנה של ה-VPC, כדי שהמכונות יוכלו לגשת ל-Google APIs ולשירותים של Google (כמו Cloud Storage ו-Artifact Registry). אם בשלבי ההתאמה האישית מורידים חבילות של מערכת הפעלה או תלויות ממאגרי מידע חיצוניים באינטרנט, צריך להגדיר גם Cloud NAT ברשת המשנה.
  • כללים של חומת האש: מוודאים שהכללים של חומת האש ב-VPC מאפשרים תעבורת נתונים יוצאת אל ממשקי Google API ומאגרי תוכנה נדרשים. אם אתם מתכננים להתחבר למכונות וירטואליות פעילות של Worker כדי לבצע ניפוי באגים אינטראקטיבי (debug: true), ודאו שכללי חומת האש מאפשרים תעבורת נתונים נכנסת (ingress) ביציאה 22 ב-TCP. אם למכונות וירטואליות אין כתובת IP חיצונית, צריך לאפשר תעבורת נתונים נכנסת מטווח כתובות ה-IP של שרת proxy לאימות זהויות (IAP) ‏35.235.240.0/20 לצורך העברת TCP.

הגדרת Artifact Registry

כדי לאחסן ולנהל את קובצי האימג' של מערכת ההפעלה בהתאמה אישית, מטא-נתונים של אבטחה ואישורי המקור של Build של SLSA, צריך להגדיר מאגר כללי ב-Artifact Registry. אחסון התמונות ב-Artifact Registry מאפשר לכם לשמור על רשומה מאובטחת ובלתי ניתנת לשינוי של תמונות שפורסמו.

כשמגדירים יעד ב-Artifact Registry,‏ Image Builder מבצע את הפעולות הבאות:

  • מייצאים את דיסק האתחול הסופי של ה-VM כקובץ tar רגיל (.tar.gz).
  • העלאת קובץ ה-tar למאגר הכללי ב-Artifact Registry.
  • יוצר וחותם על אישורי המקור של Build של SLSA עבור הארטיפקט, כדי לקשר אותו למטא-נתונים של המקור.
  • רושמים את תמונת Compute Engine שמוכנה לייצור ב-Compute Engine באמצעות ה-URI של קובץ ה-tar ב-Artifact Registry כמקור התבנית.

כדי להגדיר Artifact Registry גנרי, מבצעים את המשימות הבאות:

  1. מוודאים שלחשבון השירות שמשמש להרצת צינור הנתונים של Image Builder יש את התפקיד Artifact Registry Admin (roles/artifactregistry.admin) ברמת המאגר או הפרויקט. הוראות מפורטות זמינות במאמר הגדרת חשבון שירות של Image Builder.

  2. יוצרים מאגר של פורמט generic. כדי ליצור את המאגר, מריצים את הפקודה gcloud artifacts repositories create:

    gcloud artifacts repositories create REPOSITORY_NAME \
    --repository-format=generic \
    --location=REPOSITORY_LOCATION

    מחליפים את ה-placeholders הבאים:

    • ‫REPOSITORY_NAME: שם למאגר הכללי. לדוגמה, custom-os-images.
    • ‫REPOSITORY_LOCATION: אזור נתמך. לדוגמה, us-central1.

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