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

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

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

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

  • משלימים את השלבים להגדרת הסביבה במאמר הכנת הסביבה.
  • אם עדיין לא עשיתם את זה, תצטרכו להגדיר אימות. אימות הוא תהליך שבו מאמתים את הזהות שלכם כדי לקבל גישה לממשקי 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 .

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

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

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

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

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

כדי ליצור את אישור המקור של 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}'

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

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

המסוף (Cloud Build)

כדי לראות את אישור המקור של Build ואת פריטי המידע שנוצר בתהליך הפיתוח (Artifact) של הפלט דרך היסטוריית הבנייה של Cloud Build:

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

    כניסה ל-Cloud Build

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

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

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

המסוף (Artifact Registry)

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

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

    מעבר אל 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, פרטים על מאגר המתכונים, קובצי אימג' של קונטיינר שנעשה בהם שימוש, גיבובי בנייה ומאפיינים של תמונת הבסיס.