אימות המקור של התמונה

Linux

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

אתם יכולים לאמת הצהרות על אישור המקור של Build של SLSA (רמות של שרשרת אספקה לארטיפקטים של תוכנה) עבור תמונות מערכת הפעלה מותאמות אישית, כדי לוודא את שלמות שרשרת האספקה של התוכנה.

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

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

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

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

  המסוף

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

  gcloud

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

     gcloud init

     אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.

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

REST

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

התקינו את ה-CLI של Google Cloud.

אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.

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

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

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

• קריאה ב-Artifact Registry (roles/artifactregistry.reader)
• צפייה ב-Cloud Build (roles/cloudbuild.builds.viewer)

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

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

הגדרת יצירת אישור המקור

כדי ליצור אישור המקור של Build, צריך להגדיר את הבלוקים substitutions,‏ options,‏ results ו-artifacts בקובץ cloudbuild.yaml כמו בדוגמה הבאה:

substitutions:
  # 1. Specify your output path and target Artifact Registry resource URI
  _IMAGE_OUTPUT_PATH: 'image-builder/binaryOut'
  _ARTIFACT_REGISTRY_RESOURCE_URI: 'projects/PROJECT_ID/locations/REGION/repositories/REPOSITORY_NAME/packages/PACKAGE_NAME/versions/v${BUILD_ID}'

steps:
  # 2. Configure step results and base image attestations
  - name: 'REGION-docker.pkg.dev/image-builder-official/release/builder:stable'
    script: |
      #!/usr/bin/env bash
      /build
    id: 'imagebuilder-customize'
    results:
      - name: image_builder_telemetry_metrics
      - name: base_image
        attestationType: "https://cloudbuild.googleapis.com/attestations/build_content_restrictions"
        attestationContent: base_image

options:
  # 3. Enable Cloud Logging and cryptographic provenance generation
  logging: CLOUD_LOGGING_ONLY
  requestedVerifyOption: VERIFIED

artifacts:
  # 4. Upload generic image artifacts and provenance to Artifact Registry
  generic_artifacts:
    - folder: '${_IMAGE_OUTPUT_PATH}'
      registry_path: '${_ARTIFACT_REGISTRY_RESOURCE_URI}'

אימות נתוני המקור

אפשר לראות ולאמת את נתוני המקור של הבנייה ואת ארטיפקטי הביצוע באמצעות מסוף Google Cloud או Google Cloud CLI:

המסוף (Cloud Build)

כדי לראות את אישור המקור של Build ואת ארטיפקטי הפלט דרך היסטוריית ה-Build ב-Cloud Build:

1. במסוף Google Cloud , נכנסים לדף Cloud Build.

   כניסה ל-Cloud Build

2. לוחצים על היסטוריה ובוחרים את מזהה הבנייה של הפעלת צינור עיבוד התמונות. בדף פרטי הגרסה מוצגים יומנים של שלושת שלבי התהליך (imagebuilder-customize, imagebuilder-validate ו-imagebuilder-publish).

3. לוחצים על הכרטיסייה Build Artifacts (יצירת ארטיפקטים) כדי לראות את תמונת מערכת ההפעלה המדויקת שנוצרה במהלך ההפעלה.

   הערה: הכרטיסייה Build Artifacts (יצירת ארטיפקטים) מופיעה רק אם מגדירים מאגר Artifact Registry. לוחצים על הקישור לפריט המידע כדי לפתוח את החבילה במאגר הכללי ב-Artifact Registry.

4. לוחצים על הכרטיסייה קבצים מצורפים כדי לראות את קובצי האישור ואת קובצי התוצאות של מקוריות ה-SLSA החתומים. בקובץ התוצאות מתועדת תמונת הבסיס מהמקור ששימשה במהלך ההרצה.

המסוף (Artifact Registry)

כדי לראות את אישור המקור של Build ישירות ב-Artifact Registry:

1. נכנסים לדף Artifact Registry במסוף Google Cloud .

   מעבר אל Artifact Registry

2. ברשימת המאגרים, לוחצים על השם של המאגר הכללי.

3. ברשימת החבילות, לוחצים על שם חבילת תמונת מערכת ההפעלה.

4. ברשימת היסטוריית הגרסאות, לוחצים על מזהה הגרסה (v${BUILD_ID}) של הפעלת צינור עיבוד הנתונים.

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

gcloud

ב-Artifact Registry, רשומות המקור נשמרות כקבצים מצורפים לצד קובצי tarball של תמונות גנריות.

האישור מפורמט כ-Dead Simple Signing Envelope‏ (DSSE), ולכן המטען הייעודי (payload) של הצהרת המקור בפועל בתוך ה-JSON מקודד ב-base64. כדי לקרוא את הפרטים, מבצעים את השלבים הבאים באמצעות CLI של gcloud וכלי השירות jq:

1. מריצים את הפקודה gcloud artifacts versions list כדי לראות את רשימת הגרסאות של החבילה ולאתר את גרסת ה-build הספציפית שרוצים לאמת:

   gcloud artifacts versions list \
       --package=PACKAGE_NAME \
       --repository=REPOSITORY_NAME \
       --location=REPOSITORY_LOCATION \
       --project=PROJECT_ID
   

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

   • ‫PACKAGE_NAME: שם החבילה במאגר שלכם ב-Artifact Registry, לדוגמה, my-custom-image.
   • ‫REPOSITORY_NAME: השם של מאגר Artifact Registry כללי, לדוגמה, custom-os-images.
   • ‫REPOSITORY_LOCATION: האזור של המאגר, לדוגמה, us-central1.
   • PROJECT_ID: מזהה הפרויקט.

2. כדי לשלוח שאילתה למטא-נתונים של הקבצים המצורפים שתואמים לגרסת חבילת היעד, מריצים את הפקודה gcloud artifacts attachments list:

   gcloud artifacts attachments list \
       --target=projects/PROJECT_ID/locations/REPOSITORY_LOCATION/repositories/REPOSITORY_NAME/packages/PACKAGE_NAME/versions/vBUILD_ID \
       --repository=REPOSITORY_NAME \
       --location=REPOSITORY_LOCATION \
       --project=PROJECT_ID
   

   מחליפים את BUILD_ID במזהה הגרסה שהוחזר בשלב 1, לדוגמה, 12345.

   בפלט פקודה, מאתרים את רשומת הקובץ המצורף שהשדה name שלה מכיל את הערך build-result (עם type: application/vnd.in-toto+json), ומעתיקים את הנתיב שמופיע בקטע files:, לדוגמה:

   projects/PROJECT_ID/locations/REPOSITORY_LOCATION/repositories/REPOSITORY_NAME/files/sha256:SHA256_HASH

3. מורידים את המטען הייעודי (payload) של קובץ ה-JSON עם המטא-נתונים מהמאגר על ידי הפעלת הפקודה gcloud artifacts files download:

   gcloud artifacts files download ATTACHMENT_FILE_ID \
       --repository=REPOSITORY_NAME \
       --location=REPOSITORY_LOCATION \
       --project=PROJECT_ID \
       --destination=./provenance.json
   

   מחליפים את ATTACHMENT_FILE_ID בfiles:נתיב הקובץ המצורף שאוחזר בשלב הקודם.

4. מריצים את הפקודה הבאה כדי לבודד את תוכן מטען ה-JSON, לבצע פענוח base64 ולעצב אותו:

   cat ./provenance.json | jq -r '.payload' | base64 --decode | jq
   

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