יצירת אישורים באמצעות OpenSSF Scorecard

במדריך הזה נדגים איך להשתמש ב-OpenSSF Scorecard כדי לבדוק אם קובצי אימג' של קונטיינרים עומדים בשיטות המומלצות לאבטחת שרשרת האספקה. הכלי Scorecard Attestor פועל כחלק מצינור Cloud Build כדי ליצור אישור שאפשר לאמת באמצעות Binary Authorization לפני הפריסה. שלב האימות הזה מונע פריסה של ארטיפקטים של קונטיינרים שנפרצו בסביבת ייצור, וכך מונע כמה סוגים של פגיעויות בשרשרת האספקה.

סקירה כללית

הקרן לאבטחת קוד פתוח (OpenSSF) היא ארגון שמספק כלים, שירותים ותשתית ליוזמות אבטחה של קוד פתוח. כרטיס הניקוד הוא כלי שמתוחזק על ידי OpenSSF, שסורק מאגרים של ניהול קוד מקור (SCM) כדי למצוא שיטות מומלצות לאבטחת שרשרת האספקה.

הכלי Scorecard Attestor מובנה בכרטיס הניקוד ומאפשר ליצור אישורים של Binary Authorization על סמך מדיניות שאתם מגדירים. הכלי Scorecard Attestor מריץ את Scorecard מול מאגר ה-SCM של קובץ אימג' של קונטיינר, יוצר תוצאות, מעריך את התוצאות בהתאם למדיניות ויוצר אימות (attestation) אם המדיניות מתקיימת.

במדריך הזה יוצרים מאגר לדוגמה ואז משתמשים ב-Scorecard Attestor. כל צינור לדוגמה מכיל את שלבי הבנייה הבאים:

1. ‫build: יצירת קובץ אימג' לדוגמה של קונטיינר.
2. ‫push: שליחת התמונה אל Container Registry.
3. ‫attest: בדיקה וחתימה של התמונה באמצעות Scorecard Attestor כדי ליצור אישור על סמך המדיניות.

בשלב attest של כל פייפליין, גורם מאמת של כרטיס להערכת איכות מבצע את הפעולות הבאות:

1. מאחזר נתונים על מאגר SCM עבור קובץ אימג' של קונטיינר חדש שנבנה.
2. מריץ את כרטיס הניקוד על הנתונים הגולמיים ומעריך את מאגר ה-SCM בהתאם למדיניות שצוינה על ידי המשתמש.
   1. אם כל כללי המדיניות מתקיימים, כלי האימות של כרטיס המידע יוצר את האישור.
   2. אם לא מתקיימים התנאים של אף אחת מהמדיניות, הכלי Scorecard Attestor לא יוצר את האישור.

בזמן הפריסה, Binary Authorization מחפש הצהרה שניתן לאמת. אם לא תהיה כזו, המערכת לא תאפשר להציג את התמונה.

עלויות

במדריך הזה נעשה שימוש במוצרים הבאים Google Cloud .

• Container Registry
• Artifact Analysis
• Cloud Build
• Cloud Key Management Service

אפשר להשתמש במחשבון עלויות כדי ליצור הערכת עלויות בהתאם לשימוש החזוי.

מטרות

במדריך הזה תלמדו:

1. מגדירים את Scorecard Attestor ככלי בנייה בהתאמה אישית ב-Cloud Build.
2. צפייה במדיניות של Scorecard Attestor והגדרתה.
3. מריצים את הכלי Scorecard Attestor במאגר לדוגמה כדי ליצור אימות על סמך מדיניות.
4. מריצים את הכלי Scorecard Attestor במאגר לדוגמה במצב אימות בלבד, בלי ליצור אישור. ## לפני שמתחילים

בקטע הזה, מבצעים הגדרה חד-פעמית של המערכת.

מגדירים את הסביבה

1. מאחסנים את Google Cloud הפרויקט במשתנה סביבה.

   הערה: נשתמש בפרויקט Google Cloud לאורך המדריך הזה.

   export PROJECT_ID=PROJECT_ID
   

   מחליפים את PROJECT_ID בפרויקט ב- Google Cloud .

2. מגדירים את מזהה פרויקט ברירת המחדל לפרויקט שלכם ב- Google Cloud :

   gcloud config set project $PROJECT_ID
   

3. מאחסנים את מספר הפרויקט במשתנה סביבה לשלבים הבאים:

   export PROJECT_NUMBER=$(gcloud projects list --filter="${PROJECT_ID}" \
    --format="value(PROJECT_NUMBER)")
   

4. הפעלת ממשקי API:

   כדי לוודא שהשירותים שנדרשים במדריך הזה מופעלים, מריצים את הפקודה הבאה:

   gcloud services enable \
     cloudbuild.googleapis.com \
     containerregistry.googleapis.com \
     containerscanning.googleapis.com \
     cloudkms.googleapis.com
   

הגדרת תפקידים ב-IAM

מריצים את הפקודות הבאות כדי להגדיר את חשבון השירות של Cloud Build עם התפקידים הבאים:

• ‫containeranalysis.notes.editor: מוסיף את התפקיד Artifact Analysis Notes Editor כדי לנהל את גורם המאמת (attestor).
• ‫containeranalysis.notes.occurrences.viewer: מוסיף את התפקיד Artifact Analysis Occurrences for Notes כדי לנהל את המקרים של נקודות חולשה ואימות (attestation).
• ‫roles/containeranalysis.occurrences.editor: מוסיף את התפקיד Artifact Analysis Occurrences Editor כדי ליצור אירועי אימות ב-Artifact Analysis.

• ‫cloudkms.signer: מוסיף את התפקיד Cloud KMS CryptoKey Signer שמאפשר לחשבון השירות לגשת לשירות החתימה של Cloud KMS.

  gcloud projects add-iam-policy-binding $PROJECT_ID --member serviceAccount:$[e-mail] --role roles/containeranalysis.notes.editor
  gcloud projects add-iam-policy-binding $PROJECT_ID --member serviceAccount:$[e-mail] --role roles/containeranalysis.notes.occurrences.viewer
  gcloud projects add-iam-policy-binding $PROJECT_ID --member serviceAccount:$[e-mail] --role roles/containeranalysis.occurrences.editor
  gcloud projects add-iam-policy-binding $PROJECT_ID --member serviceAccount:$[e-mail] --role roles/cloudkms.signer
  

יצירת מפתח חתימה ב-Cloud KMS

המפתחות של Cloud Key Management Service משמשים ליצירת האישור.

1. יוצרים אוסף מפתחות חדש של Cloud KMS בשם scorecard-attestor-key-ring:

   gcloud kms keyrings create scorecard-attestor-key-ring \
       --location global
   

2. יוצרים מפתח Cloud KMS חדש בשם scorecard-attestor-key באוסף המפתחות:

   gcloud kms keys create scorecard-attestor-key \
       --keyring scorecard-attestor-key-ring \
       --location global \
       --purpose "asymmetric-signing" \
       --default-algorithm "rsa-sign-pkcs1-2048-sha256"
   

3. מאחסנים את אלגוריתם הגיבוב ואת Cloud KMS במשתנה סביבה כדי להשתמש בהם בשלבים הבאים:

   export KMS_DIGEST_ALG=SHA256
   export KMS_KEY_NAME=projects/$PROJECT_ID/locations/global/keyRings/scorecard-attestor-key-ring/cryptoKeys/scorecard-attestor-key/cryptoKeyVersions/1
   

4. יוצרים את גורם מאמת (attestor) של Binary Authorization. בהמשך, Scorecard Attestor יוצר הערה שמשויכת למאשר הזה.

   gcloud container binauthz attestors create scorecard-attestor \
       --attestation-authority-note=scorecard-attestation \
       --attestation-authority-note-project=$PROJECT_ID \
       --description="Attest that ossf/scorecard policy checks pass"
   

5. משייכים את מאמת Binary Authorization למפתח ה-KMS:

   gcloud container binauthz attestors public-keys add \
       --attestor=scorecard-attestor \
       --keyversion=1 \
       --keyversion-key=scorecard-attestor-key \
       --keyversion-keyring=scorecard-attestor-key-ring \
       --keyversion-location=global \
       --keyversion-project=$PROJECT_ID
   

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

יצירת אישורים באמצעות Scorecard Attestor בצינור עיבוד נתונים של Cloud Build

שליחת דוגמה של בנייה במקרה של כשל

בקטע הזה תבנו קובץ אימג' של קונטיינר ותבדקו את שיטות האבטחה של שרשרת האספקה באמצעות OpenSSF Scorecard. התמונה נוצרת בהצלחה, אבל לא נוצר אישור. מאגר הבסיס מכיל כמה שיטות לא מומלצות לאבטחת שרשרת האספקה, כמו תלות לא מוצמדת ב-Debian 10 ב-Dockerfile, וארטיפקט בינארי שעבר קומפילציה ונבדק במאגר המקור. הפרות כאלה נחשבות להפרות של מדיניות האימות במאגר.

1. משכפלים את מאגר הבדיקות: scorecard-binauthz-test-bad.

2. צפייה בקובץ מדיניות האישור במקרה של כשל.

   cat policy-binauthz.yaml
   

3. (אופציונלי) אפשר להציג את קובץ ההגדרות של ה-build במקרה של כשל.

   cat samples/signer/cloudbuild.yaml
   

   הערה: קובץ התצורה של ה-build הזה מכיל גם החלפות שהוגדרו על ידי המשתמש. ההחלפות הן משתנים שמשמשים בצינור ה-build, ומועברים באמצעות הפקודה gcloud builds submit עם הפרמטר --substitutions.

4. שולחים את ה-build:

   gcloud builds submit \
       --substitutions=_KMS_KEY_NAME=$KMS_KEY_NAME,_KMS_DIGEST_ALG=$KMS_DIGEST_ALG \
       --config=cloudbuild.yaml
   

הפלט אמור להיראות כך:

time="2022-12-20T22:30:14Z" level=info msg="image failed scorecard attestation policy check"

1. שומרים את מזהה ה-build מה-build האחרון:

   export BUILD_ID=$(gcloud builds list --limit=1 --format="value('ID')")
   

2. מאמתים את התוצאה:

   gcloud storage cat gs://${PROJECT_NUMBER}.cloudbuild-logs.googleusercontent.com/log-${BUILD_ID}.txt | grep "failed scorecard attestation policy check"
   

שליחת דוגמה לבנייה של תרחיש הצלחה

בקטע הזה יוצרים קובץ אימג' של קונטיינר שעומד במדיניות האימות של Scorecard. במקרה כזה, כלי האימות של כרטיס המידע יוצר אימות.

כדי לשלוח את ה-build לדוגמה של תרחיש מוצלח ל-Cloud Build:

1. משכפלים את מאגר הבדיקה: scorecard-binauthz-test-good.

2. מעיינים בקובץ מדיניות האישור במקרה של כשל. sh cat policy-binauthz.yaml

3. (אופציונלי) אפשר להציג את קובץ ההגדרות של ה-build במקרה של כשל.

   cat samples/signer/cloudbuild.yaml
   

   הערה: קובץ תצורת ה-build הזה מכיל גם החלפות שהוגדרו על ידי המשתמש. ההחלפות הן משתנים שמשמשים בצינור ה-build, ומועברים באמצעות הפקודה gcloud builds submit עם הפרמטר --substitutions.

4. שולחים את ה-build:

   gcloud builds submit \
       --substitutions=_KMS_KEY_NAME=$KMS_KEY_NAME,_KMS_DIGEST_ALG=$KMS_DIGEST_ALG \
       --config=cloudbuild.yaml
   

5. מאמתים את התוצאה:

   gcloud storage cat gs://${PROJECT_NUMBER}.cloudbuild-logs.googleusercontent.com/log-${BUILD_ID}.txt | grep "passed scorecard attestation policy check"
   

6. קבלת כתובת ה-URL של קובץ אימג' של קונטיינר שנבנה ונבדק על ידי כרטיס הניקוד

   export IMAGE_URI=$(gcloud storage cat gs://${PROJECT_NUMBER}.cloudbuild-logs.googleusercontent.com/log-${BUILD_ID}.txt | grep -o "Attestation for image .* is successfully uploaded" txt | cut -d' ' -f4 | tr -d '"')
   

7. מוודאים שנוצרה אימות עבור קובץ אימג' של קונטיינר. הכלי Scorecard Attestor משתמש במזהה ההערה ossf-scorecard-attestation ובשם ההערה projects/${PROJECT_ID}/notes/ossf-scorecard-attestation.

   gcloud container binauthz attestations list \
       --attestor="projects/${PROJECT_ID}/attestors/ossf-scorecard-attestor" \
       --filter="resourceUri='https://${IMAGE_URI}'"
   

הסרת המשאבים

כדי לנקות את המשאבים שבהם השתמשתם במסמך הזה, אתם יכולים למחוק את הפרויקט:

gcloud projects delete $PROJECT_ID

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

• לעיון במאמרי העזרה בנושא Scorecard Attestor
• מידע נוסף על כרטיס המידע
• מידע נוסף על Binary Authorization
• יצירת מאמתים דרך מסוףGoogle Cloud או כלי שורת הפקודה