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

Linux

תצוגה מקדימה

השימוש במוצר או בתכונה כפוף לתנאי השימוש במוצרים בגרסת טרום-GA, בחלק "תנאים כלליים לשירות" של התנאים הספציפיים לשירות. השימוש בתכונות ובמוצרים בגרסת טרום-GA הוא "כפי שהם" (As is), ויכול להיות שהתמיכה בהם תהיה מוגבלת. מידע נוסף זמין בקטע תיאור שלבי ההשקה.

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

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

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

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

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

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

  המסוף

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

  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 Viewer (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 ואת פריטי המידע שנוצר בתהליך הפיתוח (Artifact) של הפלט דרך היסטוריית ה-Build ב-Cloud Build:

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

   כניסה ל-Cloud Build

2. לוחצים על היסטוריה ובוחרים את מזהה ה-Build של ההרצה של צינור עיבוד התמונות. בדף פרטי הגרסה מוצגים יומנים של שלושת שלבי התהליך (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, פרטים על מאגר המתכונים, קובצי אימג' של קונטיינר שנעשה בהם שימוש, גיבובי בנייה ומאפיינים של תמונת הבסיס.