‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

שימוש בבדיקת החתימה של Sigstore

בדף הזה מוסבר איך להשתמש בבדיקת החתימה של Sigstore בתיקוף הרציף (CV) של Binary Authorization. במסגרת הבדיקה מאומתים החתימות שנוצרו על ידי Sigstore של קובצי אימג' של קונטיינרים שמשויכים ל-Pods שפועלים באשכולות GKE שבהם מופעלת התכונה CV. ההבדל העיקרי בין הבדיקה הזו לבין בדיקת אימות חתימה פשוטה הוא שבתהליך העבודה של חתימה ב-Sigstore לא נעשה שימוש בהערות של ניתוח ארטיפקטים כדי לקשר חתימות לתמונות. כל החתימות מאוחסנות לצד התמונה שהן חותמות עליה.

הבדיקה הזו תומכת רק במאגרי Artifact Registry.

עלויות

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

Binary Authorization, אבל CV זמין בחינם במהלך שלב התצוגה המקדימה
GKE
Cloud Key Management Service
Artifact Registry

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

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

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

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

איך נכנסים ל-CLI של gcloud באמצעות הזהות המאוחדת?
כדי לאתחל את ה-CLI של gcloud, הריצו את הפקודה הבאה:
```
gcloud init
```
יוצרים או בוחרים Google Cloud פרויקט.
תפקידים שנדרשים כדי לבחור או ליצור פרויקט
- Select a project: כדי לבחור פרויקט לא צריך תפקיד IAM ספציפי – אפשר לבחור כל פרויקט שקיבלתם בו תפקיד.
- יצירת פרויקט: כדי ליצור פרויקט, צריך את התפקיד Project Creator (roles/resourcemanager.projectCreator), שכולל את ההרשאה resourcemanager.projects.create. איך מקצים תפקידים?
הערה: אם אתם לא מתכננים לשמור את המשאבים שתיצרו בתהליך הזה, תוכלו ליצור פרויקט חדש במקום לבחור באחד מהפרויקטים הקיימים. בסיום התהליך תוכלו למחוק את הפרויקט ולהסיר את כל המשאבים שמשויכים אליו.
- יוצרים Google Cloud פרויקט:
```
gcloud projects create PROJECT_ID
```
  מחליפים את PROJECT_ID בשם של פרויקט Google Cloud שיוצרים.
- בוחרים את הפרויקט שיצרתם: Google Cloud
```
gcloud config set project PROJECT_ID
```
  מחליפים את PROJECT_ID בשם הפרויקט ב- Google Cloud .
מוודאים שהחיוב מופעל בפרויקט Google Cloud .
מפעילים את ממשקי ה-API של Binary Authorization,‏ Cloud Key Management Service,‏ Google Kubernetes Engine ו-Artifact Registry, אם הם עדיין לא מופעלים:
תפקידים שנדרשים להפעלת ממשקי API
כדי להפעיל ממשקי API, צריך את ההרשאה serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד "בעלים" (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד "אדמין בממשק 'שימוש בשירות'" (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידים
```
gcloud services enable binaryauthorization.googleapis.com cloudkms.googleapis.com container.googleapis.com artifactregistry.googleapis.com
```

מוודאים ש-CLI של gcloud מעודכן לגרסה האחרונה.
מתקינים את כלי שורת הפקודה kubectl.
אם כללי המדיניות של Binary Authorization ואשכולות GKE נמצאים בפרויקטים שונים, ודאו ש-Binary Authorization מופעל בשני הפרויקטים.
מתקינים את כלי שורת הפקודה cosign.

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

בקטע הזה מוסבר איך להגדיר תפקידים לבדיקה הזו.

סקירה כללית

אם אתם מריצים את כל המוצרים שמוזכרים במדריך הזה באותו פרויקט, אתם לא צריכים להגדיר הרשאות. כשמפעילים את Binary Authorization, התפקידים מוגדרים בצורה נכונה. אם אתם מריצים את המוצרים בפרויקטים שונים, אתם צריכים להגדיר את התפקידים כמו שמתואר בקטע הזה.

כדי לוודא שלסוכן השירות של Binary Authorization בכל פרויקט יש את ההרשאות הנדרשות להערכת בדיקת החתימה של CV Sigstore, צריך לבקש מהאדמין להקצות את תפקידי ה-IAM הבאים לסוכן השירות של Binary Authorization בכל פרויקט:

אם פרויקט האשכול שונה מפרויקט המדיניות: מעריך המדיניות של Binary Authorization (roles/binaryauthorization.policyEvaluator) בסוכן השירות של Binary Authorization בפרויקט האשכול
אם הפרויקט של מאגר התמונות שונה מהפרויקט של המדיניות: קורא Artifact Registry ‏ (roles/artifactregistry.reader) בסוכן השירות של Binary Authorization בפרויקט של המדיניות

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

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

הקצאת תפקידים באמצעות ה-CLI של gcloud

כדי לוודא שלסוכן השירות של Binary Authorization בכל פרויקט יש את ההרשאות הנדרשות להערכת בדיקת החתימה של CV Sigstore, צריך להקצות לסוכן השירות של Binary Authorization בכל פרויקט את תפקידי ה-IAM הבאים:

נותנים הרשאה לסוכן השירות של Binary Authorization בפרויקט האשכול לגשת למדיניות בפרויקט המדיניות.
1. אחזור של סוכן השירות של Binary Authorization בפרויקט האשכול:
```
PROJECT_NUMBER=$(gcloud projects list --filter="projectId:CLUSTER_PROJECT_ID" \
  --format="value(PROJECT_NUMBER)")
CLUSTER_SERVICE_ACCOUNT="service-$PROJECT_NUMBER@gcp-sa-binaryauthorization."
```
  מחליפים את CLUSTER_PROJECT_ID במזהה הפרויקט של האשכול.
2. מתן הרשאה ל-CV להעריך את המדיניות במקבץ:
```
gcloud projects add-iam-policy-binding POLICY_PROJECT_ID \
    --member="serviceAccount:$CLUSTER_SERVICE_ACCOUNT" \
    --role='roles/binaryauthorization.policyEvaluator'
```
  מחליפים את POLICY_PROJECT_ID במזהה הפרויקט שמכיל את המדיניות.
מאפשרים לסוכן השירות של Binary Authorization בפרויקט המדיניות לגשת לחתימות במאגר:
1. משיגים את סוכן השירות של Binary Authorization בפרויקט המדיניות:
```
PROJECT_NUMBER=$(gcloud projects list \
  --filter="projectId:POLICY_PROJECT_ID" \
  --format="value(PROJECT_NUMBER)")
SERVICE_ACCOUNT="service-$PROJECT_NUMBER@gcp-sa-binaryauthorization."
```
  מחליפים את POLICY_PROJECT_ID במזהה הפרויקט שמכיל את המדיניות.
2. הקצאת התפקיד:
```
gcloud projects add-iam-policy-binding REPOSITORY_PROJECT_ID \
    --member="serviceAccount:$SERVICE_ACCOUNT" \
    --role='roles/artifactregistry.reader'
```
  מחליפים את REPOSITORY_PROJECT_ID במזהה הפרויקט שמכיל את המאגר.

יצירת זוג מפתחות

בקטע הזה יוצרים זוג מפתחות אסימטריים של אלגוריתם חתימה דיגיטלית של עקומה אליפטית (ECDSA).

משתמשים במפתח הפרטי כדי לחתום על התמונה, וכך נוצרת האימות. צריך לכלול את המפתח הציבורי במדיניות הפלטפורמה. כש-CV בודק את האישור, הוא משתמש במפתח הציבורי כדי לאמת את האישור.

אפשר להשתמש בCloud Key Management Service ‏ (Cloud KMS) או במפתחות מקומיים, אבל מומלץ להשתמש במפתחות Cloud KMS בסביבת ייצור.

PKIX Cloud KMS Cosign

מגדירים את משתני הסביבה שנדרשים ליצירת זוג המפתחות. כדי לעשות זאת, מומלץ למלא את ה-placeholders בפקודה הבאה ואז להריץ את הפקודה.
```
KMS_KEY_PROJECT_ID=KMS_KEY_PROJECT_ID
KMS_KEYRING_NAME=KMS_KEYRING_NAME
KMS_KEY_NAME=KMS_KEY_NAME
KMS_KEY_LOCATION=global
KMS_KEY_PURPOSE=asymmetric-signing
KMS_KEY_ALGORITHM=ec-sign-p256-sha256
KMS_PROTECTION_LEVEL=software
KMS_KEY_VERSION=1
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫KMS_KEY_PROJECT_ID: מזהה הפרויקט
- ‫KMS_KEYRING_NAME: שם לאוסף המפתחות ב-Cloud KMS
- ‫KMS_KEY_NAME: שם למפתח Cloud KMS
יוצרים את המפתח באמצעות Cosign CLI:
```
cosign generate-key-pair \
  --kms gcpkms://projects/${KMS_KEY_PROJECT_ID}/locations/${KMS_KEY_LOCATION}/keyRings/${KMS_KEYRING_NAME}/cryptoKeys/${KMS_KEY_NAME}
```
הערה: יכול להיות שתצטרכו להריץ את הפקודה gcloud auth application-default login כדי להגדיר את פרטי הכניסה בצורה נכונה.
רושמים את המיקום של המפתח הציבורי:

‫Cosign שומר באופן אוטומטי את המפתח הציבורי שנוצר כ-cosign.pub בספרייה שבה הופעלה הפקודה generate-key-pair. שומרים את המיקום של הקובץ במשתנה לפקודות עתידיות.
```
PUBLIC_KEY_FILE="$(pwd)/cosign.pub"
```

PKIX Cloud KMS gcloud

כדי ליצור את זוג המפתחות ב-Cloud KMS:

מגדירים את משתני הסביבה שנדרשים כדי ליצור את זוג המפתחות. כדי לעשות זאת, מומלץ למלא את הפלייסהולדרים בפקודה הבאה ואז להריץ את הפקודה.
```
KMS_KEY_PROJECT_ID=KMS_KEY_PROJECT_ID
KMS_KEYRING_NAME=KMS_KEYRING_NAME
KMS_KEY_NAME=KMS_KEY_NAME
KMS_KEY_LOCATION=global
KMS_KEY_PURPOSE=asymmetric-signing
KMS_KEY_ALGORITHM=ec-sign-p256-sha256
KMS_PROTECTION_LEVEL=software
KMS_KEY_VERSION=1
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫KMS_KEY_PROJECT_ID: מזהה הפרויקט
- ‫KMS_KEYRING_NAME: שם לאוסף המפתחות ב-Cloud KMS
- ‫KMS_KEY_NAME: שם למפתח Cloud KMS

יוצרים את אוסף המפתחות:

gcloud kms keyrings create ${KMS_KEYRING_NAME} \
    --location=${KMS_KEY_LOCATION} \
    --project=${KMS_KEY_PROJECT_ID}

יוצרים את המפתח:

gcloud kms keys create ${KMS_KEY_NAME} \
    --location=${KMS_KEY_LOCATION} \
    --keyring=${KMS_KEYRING_NAME}  \
    --purpose=${KMS_KEY_PURPOSE} \
    --default-algorithm=${KMS_KEY_ALGORITHM} \
    --protection-level=${KMS_PROTECTION_LEVEL} \
    --project=${KMS_KEY_PROJECT_ID}

מייצאים את חומר המפתח הציבורי לקובץ:

PUBLIC_KEY_FILE="$(pwd)/cosign.pub"
gcloud kms keys versions get-public-key 1 \
    --key=${KMS_KEY_NAME} \
    --keyring=${KMS_KEYRING_NAME} \
    --location=${KMS_KEY_LOCATION} \
    --output-file=${PUBLIC_KEY_FILE} \
    --project=${KMS_KEY_PROJECT_ID}

מפתח מקומי

כדי ליצור את זוג המפתחות באופן מקומי:

  cosign generate-key-pair
  PUBLIC_KEY_FILE="$(pwd)/cosign.pub"
  PRIVATE_KEY_FILE="$(pwd)/cosign.key"

יצירת מדיניות הפלטפורמה

כדי ליצור את מדיניות פלטפורמת ה-CV עם בדיקת חתימה של Sigstore:

יוצרים את קובץ מדיניות הפלטפורמה לבדיקת החתימה של Sigstore:

cat > POLICY_PATH <<EOF
gkePolicy:
  checkSets:
  - checks:
    - displayName: sigstore-signature-check
      sigstoreSignatureCheck:
        sigstoreAuthorities:
        - displayName: sigstore-authority
          publicKeySet:
            publicKeys:
              publicKeyPem: |
$(awk '{printf "                %s\n", $0}' ${PUBLIC_KEY_FILE})
EOF

מחליפים את הערך ב-POLICY_PATH בנתיב לקובץ המדיניות.

יוצרים את מדיניות הפלטפורמה:

לפני השימוש בנתוני הפקודה הבאים, צריך להחליף את הנתונים הבאים:
- ‫POLICY_ID: מזהה מדיניות פלטפורמה לבחירתכם. אם המדיניות נמצאת בפרויקט אחר, אפשר להשתמש בשם המלא של המשאב: projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID.
- ‫POLICY_PATH: נתיב לקובץ המדיניות.
- ‫POLICY_PROJECT_ID: מזהה פרויקט המדיניות.
מריצים את הפקודה הבאה:
‫Linux,‏ macOS או Cloud Shell

הערה: חשוב לוודא שהפעלתם את Google Cloud CLI עם אימות ופרויקט, על ידי הרצת הפקודה gcloud init או gcloud auth login ו- gcloud config set project.
```
gcloud beta container binauthz policy create POLICY_ID \
    --platform=gke \
    --policy-file=POLICY_PATH \
    --project=POLICY_PROJECT_ID
```
‏Windows (PowerShell)

הערה: חשוב לוודא שהפעלתם את Google Cloud CLI עם אימות ופרויקט באמצעות אחת מהפקודות הבאות: gcloud init; או gcloud auth login ו- gcloud config set project.
```
gcloud beta container binauthz policy create POLICY_ID `
    --platform=gke `
    --policy-file=POLICY_PATH `
    --project=POLICY_PROJECT_ID
```
Windows‏ (cmd.exe)

הערה: חשוב לוודא שהפעלתם את Google Cloud CLI עם אימות ופרויקט באמצעות אחת מהפקודות הבאות: gcloud init; או gcloud auth login ו- gcloud config set project.
```
gcloud beta container binauthz policy create POLICY_ID ^
    --platform=gke ^
    --policy-file=POLICY_PATH ^
    --project=POLICY_PROJECT_ID
```

הפעלת CV

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

יצירת אשכול שמשתמש במעקב אחרי גרסאות קונטיינרים

בקטע הזה יוצרים אשכול שמשתמש רק בניטור CV עם מדיניות פלטפורמה מבוססת-בדיקה.

לפני השימוש בנתוני הפקודה הבאים, צריך להחליף את הנתונים הבאים:

‫CLUSTER_NAME: שם האשכול.
‫LOCATION: המיקום – לדוגמה, us-central1 או asia-south1.
‫POLICY_PROJECT_ID: מזהה הפרויקט שבו מאוחסנת המדיניות.
POLICY_ID: מזהה המדיניות.
‫CLUSTER_PROJECT_ID: מזהה הפרויקט של האשכול.

מריצים את הפקודה הבאה:

‫Linux,‏ macOS או Cloud Shell

gcloud beta container clusters create CLUSTER_NAME \
    --location=LOCATION \
    --binauthz-evaluation-mode=POLICY_BINDINGS \
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID \
    --project=CLUSTER_PROJECT_ID

‏Windows (PowerShell)

gcloud beta container clusters create CLUSTER_NAME `
    --location=LOCATION `
    --binauthz-evaluation-mode=POLICY_BINDINGS `
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID `
    --project=CLUSTER_PROJECT_ID

Windows‏ (cmd.exe)

gcloud beta container clusters create CLUSTER_NAME ^
    --location=LOCATION ^
    --binauthz-evaluation-mode=POLICY_BINDINGS ^
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID ^
    --project=CLUSTER_PROJECT_ID

יצירת אשכול שמשתמש באכיפה ובמעקב אחרי CV

בקטע הזה תלמדו איך ליצור אשכול שמשתמש גם באכיפת מדיניות project-singleton וגם במעקב אחר CV עם מדיניות פלטפורמה מבוססת-בדיקות:

לפני השימוש בנתוני הפקודה הבאים, צריך להחליף את הנתונים הבאים:

‫CLUSTER_NAME: שם האשכול.
‫LOCATION: המיקום – לדוגמה, us-central1 או asia-south1.
‫POLICY_PROJECT_ID: מזהה הפרויקט שבו מאוחסנת המדיניות.
POLICY_ID: מזהה המדיניות.
‫CLUSTER_PROJECT_ID: מזהה הפרויקט של האשכול.

מריצים את הפקודה הבאה:

‫Linux,‏ macOS או Cloud Shell

gcloud beta container clusters create CLUSTER_NAME \
    --location=LOCATION \
    --binauthz-evaluation-mode=POLICY_BINDINGS_AND_PROJECT_SINGLETON_POLICY_ENFORCE \
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID \
    --project=CLUSTER_PROJECT_ID

‏Windows (PowerShell)

gcloud beta container clusters create CLUSTER_NAME `
    --location=LOCATION `
    --binauthz-evaluation-mode=POLICY_BINDINGS_AND_PROJECT_SINGLETON_POLICY_ENFORCE `
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID `
    --project=CLUSTER_PROJECT_ID

Windows‏ (cmd.exe)

gcloud beta container clusters create CLUSTER_NAME ^
    --location=LOCATION ^
    --binauthz-evaluation-mode=POLICY_BINDINGS_AND_PROJECT_SINGLETON_POLICY_ENFORCE ^
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID ^
    --project=CLUSTER_PROJECT_ID

עדכון אשכול לשימוש במעקב אחרי CV

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

לפני השימוש בנתוני הפקודה הבאים, צריך להחליף את הנתונים הבאים:

‫CLUSTER_NAME: שם האשכול
‫LOCATION: המיקום. לדוגמה: us-central1 או asia-south1
‫POLICY_PROJECT_ID: מזהה הפרויקט שבו המדיניות מאוחסנת
‫POLICY_ID: מזהה המדיניות
‫CLUSTER_PROJECT_ID: מזהה הפרויקט של האשכול

מריצים את הפקודה הבאה:

‫Linux,‏ macOS או Cloud Shell

gcloud beta container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --binauthz-evaluation-mode=POLICY_BINDINGS \
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID \
    --project=CLUSTER_PROJECT_ID

‏Windows (PowerShell)

gcloud beta container clusters update CLUSTER_NAME `
    --location=LOCATION `
    --binauthz-evaluation-mode=POLICY_BINDINGS `
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID `
    --project=CLUSTER_PROJECT_ID

Windows‏ (cmd.exe)

gcloud beta container clusters update CLUSTER_NAME ^
    --location=LOCATION ^
    --binauthz-evaluation-mode=POLICY_BINDINGS ^
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID ^
    --project=CLUSTER_PROJECT_ID

עדכון אשכול לשימוש באכיפה ובמעקב אחרי CV

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

לפני השימוש בנתוני הפקודה הבאים, צריך להחליף את הנתונים הבאים:

‫CLUSTER_NAME: שם האשכול
‫LOCATION: המיקום. לדוגמה: us-central1 או asia-south1
‫POLICY_PROJECT_ID: מזהה הפרויקט שבו המדיניות מאוחסנת
‫POLICY_ID: מזהה המדיניות
‫CLUSTER_PROJECT_ID: מזהה הפרויקט של האשכול

מריצים את הפקודה הבאה:

‫Linux,‏ macOS או Cloud Shell

gcloud beta container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --binauthz-evaluation-mode=POLICY_BINDINGS_AND_PROJECT_SINGLETON_POLICY_ENFORCE \
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID \
    --project=CLUSTER_PROJECT_ID

‏Windows (PowerShell)

gcloud beta container clusters update CLUSTER_NAME `
    --location=LOCATION `
    --binauthz-evaluation-mode=POLICY_BINDINGS_AND_PROJECT_SINGLETON_POLICY_ENFORCE `
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID `
    --project=CLUSTER_PROJECT_ID

Windows‏ (cmd.exe)

gcloud beta container clusters update CLUSTER_NAME ^
    --location=LOCATION ^
    --binauthz-evaluation-mode=POLICY_BINDINGS_AND_PROJECT_SINGLETON_POLICY_ENFORCE ^
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID ^
    --project=CLUSTER_PROJECT_ID

בדיקת קורות חיים

בקטע הזה תבדקו את CV על ידי פריסת תמונה חתומה. במקרה כזה, בדיקת החתימה של CV Sigstore מאמתת את החתימה ולא יוצרת רשומה ביומן.

לאחר מכן אתם מנסים לפרוס קובץ אימג' אחר שלא חתום. במקרה כזה, בדיקת ה-CV לא מוצאת חתימה תקינה ומתעדת את ההפרה ב-Cloud Logging.

חתימה על תמונה

כדי לעבור את הבדיקה, התמונה צריכה לכלול חתימה תקינה. כדי ליצור את החתימה:

יוצרים את המשתנים שמשמשים לחתימה על התמונה:
```
IMAGE_PATH=IMAGE_PATH
IMAGE_DIGEST=sha256:IMAGE_DIGEST_SHA
IMAGE_TO_SIGN="${IMAGE_PATH}@${IMAGE_DIGEST}"
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫IMAGE_PATH: הנתיב לתמונה
- ‫IMAGE_DIGEST_SHA: גיבוב SHA של התקציר של התמונה
חותמים על התמונה ומעבירים את החתימה ל-Artifact Registry:
PKIX Cloud KMS
חותמים על קובץ האימג' באמצעות מפתח שמתארח ב-Cloud KMS ומעבירים את החתימה בדחיפה ל-Artifact Registry:
cosign sign \ --key gcpkms://projects/${KMS_KEY_PROJECT_ID}/locations/${KMS_KEY_LOCATION}/keyRings/${KMS_KEYRING_NAME}/cryptoKeys/${KMS_KEY_NAME} \ ${IMAGE_TO_SIGN}
מפתח מקומי
חותמים על קובץ האימג' באמצעות מפתח פרטי מקומי ומעבירים את החתימה בדחיפה ל-Artifact Registry.
cosign sign --key ${PRIVATE_KEY_FILE} ${IMAGE_TO_SIGN}
מגיבים להנחיה של Cosign:

אחרי שמריצים את הפקודה cosign sign, ‏Cosign שואל אם רוצים להעלות את החתימה ליומן השקיפות Rekor. עונים על ההנחיות y או n. מידע נוסף על Rekor זמין במסמכי התיעוד של Rekor.

אימות החתימה באופן ידני

כדי לאמת את החתימה באופן ידני:

מוודאים שהחתימה קיימת ב-Artifact Registry:
מסוף Google Cloud
1. עוברים לדף Artifact Registry במסוף Google Cloud .
  
  כניסה ל-Artifact Registry
2. ברשימת המאגרים, לוחצים על שם המאגר שמכיל את קובץ האימג'.
3. לוחצים על שם התמונה שחתמתם עליה.
4. מאתרים את הפריט שמכיל את החתימה. התג של הפריט הזה הוא: sha256-[image digest].sig. צריך להיות רק פריט אחד עם התג.
5. לוחצים על מניפסט.
6. אמור להופיע קובץ בפורמט JSON עם שדות שונים. כל חתימה נמצאת ברכיב אחד ברשימה layers, במפה annotations. החתימות נמצאות במפתח dev.cosignproject.cosign/signature.
  
  דוגמה למניפסט:
{ "schemaVersion": 2, "mediaType": "application/vnd.oci.image.manifest.v1+json", "config": { "mediaType": "application/vnd.oci.image.config.v1+json", "size": SIZE_OF_LAYERS, "digest": "DIGEST_OF_LAYERS" }, "layers": [ { "mediaType": "application/vnd.dev.cosign.simplesigning.v1+json", "size": SIZE_OF_ANNOTATIONS, "digest": "DIGEST_OF_ANNOTATIONS", "annotations": { "dev.cosignproject.cosign/signature": "BASE64_SIGNATURE", "dev.sigstore.cosign/bundle": "BUNDLE" } } ] }
קובץ המניפסט לדוגמה כולל את הפרטים הבאים:
- ‫SIZE_OF_LAYERS: גודל המערך layers בבייטים
- ‫DIGEST_OF_LAYERS: הגיבוב של המערך layers
- ‫SIZE_OF_ANNOTATIONS: גודל המילון annotations בבייטים
- ‫DIGEST_OF_ANNOTATIONS: תקציר של המילון annotations
- ‫BASE64_SIGNATURE: החתימה הגולמית בפורמט Base64. זו החתימה שתשמש לאימות
- ‫BUNDLE: מטא-נתונים ספציפיים ל-Sigstore
מידע נוסף על פורמט המניפסט זמין במפרט החתימה של cosign של Sigstore.
שורת הפקודה
1. מאתרים את פריט המידע הנכון:
  
  רשימת הפריטים שמאוחסנים עם התמונה:
  
  gcloud artifacts docker tags list ${IMAGE_PATH}
  
  פלט לדוגמה:
  
  Listing items under project PROJECT_ID, location REPOSITORY_LOCATION, repository REPOSITORY_NAME. TAG IMAGE DIGEST latest us-east1-docker.pkg.dev/my-project/my-repo/my-image sha256:abc123 sha256-abc123.sig us-east1-docker.pkg.dev/my-project/my-repo/my-image sha256:def456
  
  בפלט, הארטיפקט עם התג sha256-abc123.sig מכיל את החתימה במניפסט שלו.
2. קבלת המניפסט
  
  כדי לקבל את המניפסט של פריט המידע שנוצר בתהליך הפיתוח (Artifact) עם התג sha256-IMAGE_DIGEST_SHA.sig, מריצים את הפקודה הבאה:
  
  curl -X GET -H "Content-Type: application/json" \ -H "Authorization: Bearer $(gcloud auth print-access-token)" \ -H "X-Goog-User-Project: REPOSITORY_PROJECT_ID" \ "https://REPOSITORY_LOCATION-docker.pkg.dev/v2/REPOSITORY_PROJECT_ID/REPOSITORY_NAME/IMAGE_NAME/manifests/sha256-IMAGE_DIGEST_SHA.sig"
  
  מחליפים את מה שכתוב בשדות הבאים:
  
  ‫REPOSITORY_PROJECT_ID: מזהה הפרויקט שמכיל את המאגר
  
  ‫REPOSITORY_LOCATION: המיקום של המאגר
  
  ‫REPOSITORY_NAME: שם המאגר
  
  ‫IMAGE_NAME: שם התמונה
  
  אמור להופיע קובץ בפורמט JSON עם שדות שונים. כל חתימה נמצאת ברכיב אחד ברשימה layers, במפה annotations. החתימות נמצאות במפתח dev.cosignproject.cosign/signature.
  
  דוגמה לקובץ מניפסט:
  
  { "schemaVersion": 2, "mediaType": "application/vnd.oci.image.manifest.v1+json", "config": { "mediaType": "application/vnd.oci.image.config.v1+json", "size": SIZE_OF_LAYERS, "digest": "DIGEST_OF_LAYERS" }, "layers": [ { "mediaType": "application/vnd.dev.cosign.simplesigning.v1+json", "size": SIZE_OF_ANNOTATIONS, "digest": "DIGEST_OF_ANNOTATIONS", "annotations": { "dev.cosignproject.cosign/signature": "BASE64_SIGNATURE", "dev.sigstore.cosign/bundle": "BUNDLE" } } ] }
קובץ המניפסט לדוגמה כולל את הפרטים הבאים:
- ‫SIZE_OF_LAYERS: גודל המערך layers בבייטים
- ‫DIGEST_OF_LAYERS: הגיבוב של המערך layers
- ‫SIZE_OF_ANNOTATIONS: גודל המילון annotations בבייטים
- ‫DIGEST_OF_ANNOTATIONS: תקציר של המילון annotations
- ‫BASE64_SIGNATURE: החתימה הגולמית בפורמט Base64. זו החתימה שתשמש לאימות
- ‫BUNDLE: מטא-נתונים ספציפיים ל-Sigstore
מידע נוסף על פורמט המניפסט זמין במפרט החתימה של cosign של Sigstore.
אימות ידני של החתימה:

כדי לאמת את החתימה שהועלתה, משתמשים ב-cosign verify:
PKIX Cloud KMS
cosign verify --key gcpkms://projects/${KMS_KEY_PROJECT_ID}/locations/${KMS_KEY_LOCATION}/keyRings/${KMS_KEYRING_NAME}/cryptoKeys/${KMS_KEY_NAME} \ ${IMAGE_PATH}@${IMAGE_DIGEST}
מפתח מקומי
cosign verify --key {PUBLIC_KEY_FILE} ${IMAGE_PATH}@${IMAGE_DIGEST}
הערה: בהתאם לשאלה אם העליתם את החתימה ליומן השקיפות הציבורי Rekor, יכול להיות שתצטרכו להוסיף את הגדרת ה-flag בשורת הפקודה --insecure-ignore-tlog כדי לאמת את החתימה.

אם האימות הצליח, פלט הפקודה יציין The signatures were verified against the specified public key.

פריסת קובץ האימג' החתום

כדי לפרוס תמונה חתומה:

הגדרה של kubectl:
```
gcloud container clusters get-credentials CLUSTER_NAME \
    --location=LOCATION \
    --project=CLUSTER_PROJECT_ID
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫CLUSTER_NAME: השם של האשכול
- ‫LOCATION: המיקום של האשכול
- ‫CLUSTER_PROJECT_ID: מזהה הפרויקט של האשכול
פורסים תמונה ובודקים את הפריסה מול מדיניות Binary Authorization:
```
kubectl run hello-app-signed --image=${IMAGE_PATH}@${IMAGE_DIGEST}
```
ה-Pod נפרס. מכיוון שהתמונה חתומה, CV לא יוצר רשומות ביומן שקשורות ל-Pod הזה.

הערה: אם נתקלים בשגיאות במהלך הפריסה, יכול להיות שצריך להעניק לסוכן השירות של Compute Engine הרשאה לגשת למאגר. קראו את המסמכים בנושא Google Cloud SDK.

פריסת קובץ אימג' לא חתום

בקטע הזה, פורסים תמונה לא חתומה.

בגלל שדרישות המדיניות דורשות חתימות ולתמונה הזו אין חתימה, CV מתעד באופן קבוע את ההפרה בזמן שהקונטיינר פועל.

כדי לפרוס את האימג', מריצים את הפקודה הבאה:

  kubectl run hello-app-unsigned \
      --image=UNSIGNED_IMAGE_PATH@UNSIGNED_IMAGE_DIGEST

ה-Pod נפרס. מכיוון שלתמונה אין אישור, ‏CV יוצר רשומות ביומן בזמן שה-Pod פועל.

צפייה ביומנים של רשומות קורות חיים

אפשר לחפש רשומות יומן ב-Cloud Logging כדי למצוא שגיאות בהגדרת CV והפרות של מדיניות הפלטפורמה של CV.

השגיאות וההפרות ב-CV נרשמות ב-Cloud Logging תוך 24 שעות. בדרך כלל אפשר לראות את הרשומות תוך כמה שעות.

צפייה ביומני שגיאות של הגדרות CV

כדי לראות את יומני השגיאות של הגדרת ה-CV, מריצים את הפקודה הבאה:

gcloud logging read \
     --order="desc" \
     --freshness=7d \
     --project=CLUSTER_PROJECT_ID \
    'logName:"binaryauthorization.googleapis.com%2Fcontinuous_validation" "configErrorEvent"'

בפלט הבא מוצגת שגיאת הגדרה שבה לא נמצאה מדיניות פלטפורמה של CV:

{
  "insertId": "141d4f10-72ea-4a43-b3ec-a03da623de42",
  "jsonPayload": {
    "@type": "type.googleapis.com/google.cloud.binaryauthorization.v1beta1.ContinuousValidationEvent",
    "configErrorEvent": {
      "description": "Cannot monitor cluster 'us-central1-c.my-cluster': Resource projects/123456789/platforms/gke/policies/my-policy does not exist."
    }
  },
  "resource": {
    "type": "k8s_cluster",
    "labels": {
      "cluster_name": "my-cluster",
      "location": "us-central1-c",
      "project_id": "my-project"
    }
  },
  "timestamp": "2024-05-28T15:31:03.999566Z",
  "severity": "WARNING",
  "logName": "projects/my-project/logs/binaryauthorization.googleapis.com%2Fcontinuous_validation",
  "receiveTimestamp": "2024-05-28T16:30:56.304108670Z"
}

הצגת הפרות של אימות המדיניות של פלטפורמת ה-CV

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

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

gcloud logging read \
     --order="desc" \
     --freshness=7d \
     --project=CLUSTER_PROJECT_ID \
    'logName:"binaryauthorization.googleapis.com%2Fcontinuous_validation" "policyName"'

מחליפים את CLUSTER_PROJECT_ID במזהה הפרויקט של האשכול.

סוגי הבדיקות

יומני CV כוללים מידע על הפרות של checkResults. ברשומה, הערך checkType מציין את הבדיקה. הערכים של כל בדיקה הם:

ImageFreshnessCheck
SigstoreSignatureCheck
SimpleSigningAttestationCheck
SlsaCheck
TrustedDirectoryCheck
VulnerabilityCheck

יומן לדוגמה

בדוגמה הבאה של רשומה ביומן של CV מתואר תמונה לא תואמת שמפירה בדיקה של ספרייה מהימנה:

{
  "insertId": "637c2de7-0000-2b64-b671-24058876bb74",
  "jsonPayload": {
    "podEvent": {
      "endTime": "2022-11-22T01:14:30.430151Z",
      "policyName": "projects/123456789/platforms/gke/policies/my-policy",
      "images": [
        {
          "result": "DENY",
          "checkResults": [
            {
              "explanation": "TrustedDirectoryCheck at index 0 with display name \"My trusted directory check\" has verdict NOT_CONFORMANT. Image is not in a trusted directory",
              "checkSetName": "My check set",
              "checkSetIndex": "0",
              "checkName": "My trusted directory check",
              "verdict": "NON_CONFORMANT",
              "checkType": "TrustedDirectoryCheck",
              "checkIndex": "0"
            }
          ],
          "image": "gcr.io/my-project/hello-app:latest"
        }
      ],
      "verdict": "VIOLATES_POLICY",
      "podNamespace": "default",
      "deployTime": "2022-11-22T01:06:53Z",
      "pod": "hello-app"
    },
    "@type": "type.googleapis.com/google.cloud.binaryauthorization.v1beta1.ContinuousValidationEvent"
  },
  "resource": {
    "type": "k8s_cluster",
    "labels": {
      "project_id": "my-project",
      "location": "us-central1-a",
      "cluster_name": "my-test-cluster"
    }
  },
  "timestamp": "2022-11-22T01:44:28.729881832Z",
  "severity": "WARNING",
  "logName": "projects/my-project/logs/binaryauthorization.googleapis.com%2Fcontinuous_validation",
  "receiveTimestamp": "2022-11-22T03:35:47.171905337Z"
}

הסרת המשאבים

בקטע הזה מוסבר איך לנקות את המעקב אחר CV שהגדרתם קודם במדריך הזה.

אפשר להשבית את המעקב אחר CV או את Binary Authorization ואת ה-CV באשכול.

השבתה של Binary Authorization באשכול

כדי להשבית את האכיפה של CV ו-Binary Authorization באשכול, מריצים את הפקודה הבאה:

gcloud beta container clusters update CLUSTER_NAME \
    --binauthz-evaluation-mode=DISABLED \
    --location=LOCATION \
    --project=CLUSTER_PROJECT_ID

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

‫CLUSTER_NAME: שם האשכול
‫LOCATION: המיקום של האשכול
‫CLUSTER_PROJECT_ID: מזהה הפרויקט של האשכול

השבתת מעקב אחרי מדיניות שמבוססת על בדיקות באשכול

כדי להשבית את CV באמצעות מדיניות מבוססת-בדיקות באשכול, ולהפעיל מחדש את האכיפה באמצעות מדיניות האכיפה של Binary Authorization, מריצים את הפקודה הבאה:

gcloud beta container clusters update CLUSTER_NAME  \
    --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE \
    --location=LOCATION \
    --project="CLUSTER_PROJECT_ID"

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

‫CLUSTER_NAME: שם האשכול
‫LOCATION: המיקום של האשכול
‫CLUSTER_PROJECT_ID: מזהה הפרויקט של האשכול

שימו לב: --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE שווה לדגל הישן יותר --enable-binauthz.

מחיקת המדיניות

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

gcloud beta container binauthz policy delete POLICY_ID \
    --platform=gke \
    --project="POLICY_PROJECT_ID"

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

‫POLICY_ID: מזהה המדיניות
‫POLICY_PROJECT_ID: מזהה הפרויקט של המדיניות

שימוש בבדיקת החתימה של Sigstore קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.

עלויות

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

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

סקירה כללית

הקצאת תפקידים באמצעות ה-CLI של gcloud

יצירת זוג מפתחות

PKIX Cloud KMS Cosign

PKIX Cloud KMS gcloud

מפתח מקומי

יצירת מדיניות הפלטפורמה

‫Linux,‏ macOS או Cloud Shell

‏Windows (PowerShell)

Windows‏ (cmd.exe)

הפעלת CV

יצירת אשכול שמשתמש במעקב אחרי גרסאות קונטיינרים

‫Linux,‏ macOS או Cloud Shell

‏Windows (PowerShell)

Windows‏ (cmd.exe)

יצירת אשכול שמשתמש באכיפה ובמעקב אחרי CV

‫Linux,‏ macOS או Cloud Shell

‏Windows (PowerShell)

Windows‏ (cmd.exe)

עדכון אשכול לשימוש במעקב אחרי CV

‫Linux,‏ macOS או Cloud Shell

‏Windows (PowerShell)

Windows‏ (cmd.exe)

עדכון אשכול לשימוש באכיפה ובמעקב אחרי CV

‫Linux,‏ macOS או Cloud Shell

‏Windows (PowerShell)

Windows‏ (cmd.exe)

בדיקת קורות חיים

חתימה על תמונה

PKIX Cloud KMS

מפתח מקומי

אימות החתימה באופן ידני

מסוף Google Cloud

שורת הפקודה

PKIX Cloud KMS

מפתח מקומי

פריסת קובץ האימג' החתום

פריסת קובץ אימג' לא חתום

צפייה ביומנים של רשומות קורות חיים

צפייה ביומני שגיאות של הגדרות CV

הצגת הפרות של אימות המדיניות של פלטפורמת ה-CV

סוגי הבדיקות

יומן לדוגמה

הסרת המשאבים

השבתה של Binary Authorization באשכול

השבתת מעקב אחרי מדיניות שמבוססת על בדיקות באשכול

מחיקת המדיניות

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

שימוש בבדיקת החתימה של Sigstore