לפני שיוצרים צינור Image Builder, צריך קודם להכין את סביבת Cloud de Confiance . כדי להכין את הסביבה, צריך לבצע את המשימות הבאות:
- שליחת בקשה להצטרפות
- הפעלת ממשקי Cloud API נדרשים
- הגדרת חשבון השירות של Image Builder
- הגדרה של מדיניות הארגון בנושא קובצי אימג' מהימנים
- הגדרת רשת VPC ודרישות גישה
- הגדרת Artifact Registry
לפני שמתחילים
-
אם עדיין לא עשיתם את זה, תצטרכו להגדיר אימות.
אימות הוא תהליך שבו מאמתים את הזהות שלכם כדי לקבל גישה לממשקי API ולשירותים של Cloud de Confiance by S3NS . כדי להריץ קוד או דוגמאות מסביבת פיתוח מקומית, אפשר לבצע אימות ל-Compute Engine באחת מהדרכים הבאות:
צריך לבחור את הכרטיסייה הרלוונטית לאופן שבו תכננתם להשתמש בדוגמאות בדף הזה:
המסוף
כשמשתמשים במסוף Cloud de Confiance כדי לגשת לשירותים Cloud de Confiance by S3NS ולממשקי ה-API, לא צריך להגדיר אימות.
gcloud
-
התקינו את ה-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 הבאים בפרויקט:
- אדמין Service Usage (
roles/serviceusage.serviceUsageAdmin) - אדמין IAM של פרויקט (
roles/resourcemanager.projectIamAdmin) או אדמין בחשבון שירות (roles/iam.serviceAccountAdmin) - אדמין של Artifact Registry (
roles/artifactregistry.admin)
להסבר על מתן תפקידים, ראו איך מנהלים את הגישה ברמת הפרויקט, התיקייה והארגון.
יכול להיות שאפשר לקבל את ההרשאות הנדרשות גם באמצעות תפקידים בהתאמה אישית או תפקידים מוגדרים מראש.
בקשה להצטרפות
Image Builder זמין לכלל המשתמשים עם רשימת היתרים. כדי להוסיף את Cloud de Confiance הפרויקט שלכם לצינור להתאמה אישית של תמונות, צריך לשלוח את טופס בקשת הגישה או לפנות לצוות Cloud de Confiance ניהול החשבון שלכם.
הפעלת ממשקי ה-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). איך מקצים תפקידים
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.comcloudbuild.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 Cloud de Confiance או ה-CLI של gcloud, בוחרים באחת מהכרטיסיות הבאות:
המסוף
-
מוודאים שיש לכם את תפקיד ה-IAM 'יצירת חשבונות שירות'
(
-
במסוף Cloud de Confiance , נכנסים לדף יצירת חשבון שירות.
כניסה לדף Create service account - בוחרים את הפרויקט הרצוי.
-
כותבים שם בשדה Service account name. המסוף Cloud de Confiance ממלא את השדה מזהה חשבון שירות בהתאם לשם הזה.
כותבים תיאור בשדה Service account description. לדוגמה:
Service account for quickstart. - לוחצים על Create and continue.
-
נותנים לחשבון השירות את התפקידים הבאים: 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 ומוסיפים את כולם.
- לוחצים על Continue.
-
בשדה Service account users role, מזינים את המזהה של חשבון המשתמש שיצרף את חשבון השירות למשאבים אחרים, כמו מכונות של Compute Engine.
בדרך כלל זה המזהה של משתמש במאגר זהויות של כוח עבודה. לפרטים נוספים, קראו את המאמר ייצוג המשתמשים במאגרי כוח עבודה בכללי מדיניות IAM.
-
לוחצים על Done כדי לסיים ליצור את חשבון השירות.
roles/iam.serviceAccountCreator) ואת התפקיד 'אדמין IAM בפרויקט'
(roles/resourcemanager.projectIamAdmin). איך מקצים תפקידים
gcloud
יוצרים חשבון שירות לצינור עיבוד הנתונים לבנייה:
gcloud iam service-accounts create SERVICE_ACCOUNT_NAME \ --display-name="Image Builder Service Account"מקצים את התפקידים הנדרשים (
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"אופציונלי: מקצים את התפקיד האופציונלי (
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
אם מדיניות הארגון מגבילה את הפרויקט הזה, שלב ייצוא התמונה ייכשל.
כדי לעדכן את מדיניות הארגון:
- במדיניות הארגון, באילוץ
compute.trustedImageProjects, מוסיפים אתprojects/compute-image-importלרשימת המפיצים המורשים. - הוראות מפורטות להגדרת אילוצים של מדיניות הארגון זמינות במאמרים הגדרת מדיניות של תמונות מהימנות וייצוא תמונה בהתאמה אישית ל-Cloud Storage.
הגדרת רשת VPC ודרישות גישה
במהלך שלבי ה-build והאימות, 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 ומאגרי תוכנה נדרשים. אם אתם מתכננים להתחבר למכונות וירטואליות פעילות של עובדים כדי לבצע ניפוי באגים אינטראקטיבי (
debug: true), ודאו שכללי חומת האש מאפשרים תעבורת נתונים נכנסת (ingress) ביציאת TCP 22. אם למכונות וירטואליות אין כתובת 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 גנרי, מבצעים את המשימות הבאות:
מוודאים שלחשבון השירות שמשמש להרצת צינור הנתונים של Image Builder יש את התפקיד Artifact Registry Admin (
roles/artifactregistry.admin) ברמת המאגר או הפרויקט. הוראות מפורטות זמינות במאמר הגדרת חשבון שירות של Image Builder.יוצרים מאגר של פורמט
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.
-
המאמרים הבאים
- יצירה וניהול של צינורות באמצעות מסוף Cloud de Confiance
- יצירה וניהול של צינורות באופן פרוגרמטי.
- כאן מוסבר איך מגדירים מתכונים להתאמה אישית.
- בודקים את המבנה של קובץ תצורת build (
cloudbuild.yaml).