Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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

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

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

עלויות

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

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

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

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

נכנסים לחשבון Google Cloud . אם אתם משתמשים חדשים ב- Google Cloud, צרו חשבון כדי שתוכלו להעריך את הביצועים של המוצרים שלנו בתרחישים מהעולם האמיתי. לקוחות חדשים מקבלים בחינם גם קרדיט בשווי 300$ להרצה, לבדיקה ולפריסה של עומסי העבודה.

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

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

אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-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, צריך את תפקיד ה-IAM 'אדמין של Service Usage' (roles/serviceusage.serviceUsageAdmin), שכולל את ההרשאה serviceusage.services.enable. איך מקצים תפקידים

gcloud services enable binaryauthorization.googleapis.com cloudkms.googleapis.com container.googleapis.com artifactregistry.googleapis.com

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

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

אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-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

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, צריך לבקש מהאדמין להקצות לסוכן השירות של Binary Authorization בכל פרויקט את תפקידי ה-IAM הבאים:

אם פרויקט האשכול שונה מפרויקט המדיניות: Binary Authorization Policy Evaluator (roles/binaryauthorization.policyEvaluator) on the cluster project Binary Authorization Service Agent
אם פרויקט מאגר התמונות שונה מפרויקט המדיניות: Artifact Registry Reader (roles/artifactregistry.reader) on the policy project Binary Authorization Service Agent

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

יכול להיות שהאדמין גם יוכל לתת לסוכן השירות של 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.iam.gserviceaccount.com"
```
  מחליפים את 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.iam.gserviceaccount.com"
```
  מחליפים את 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, מבצעים את הפעולות הבאות:

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

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

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

בקטע הזה יוצרים אשכול שמשתמש רק בניטור 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

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

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

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

‫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. קבלת קובץ המניפסט
  
  כדי לקבל את המניפסט של הארטיפקט עם התג 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}
הערה: יכול להיות שתצטרכו להוסיף את התכונה הניסיונית בשורת הפקודה --insecure-ignore-tlog כדי לאמת את החתימה, בהתאם לשאלה אם העליתם את החתימה ליומן השקיפות הציבורי Rekor.

אם האימות הצליח, פלט הפקודה יציין 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.

השגיאות וההפרות נרשמות ביומנים של 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 או את 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

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

‫Linux,‏ macOS או Cloud Shell

‏Windows (PowerShell)

Windows‏ (cmd.exe)

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

‫Linux,‏ macOS או Cloud Shell

‏Windows (PowerShell)

Windows‏ (cmd.exe)

עדכון אשכול לשימוש בניטור של CV

‫Linux,‏ macOS או Cloud Shell

‏Windows (PowerShell)

Windows‏ (cmd.exe)

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

‫Linux,‏ macOS או Cloud Shell

‏Windows (PowerShell)

Windows‏ (cmd.exe)

בדיקת ערכי המרות

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

PKIX Cloud KMS

מפתח מקומי

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

מסוף Google Cloud

שורת הפקודה

PKIX Cloud KMS

מפתח מקומי

פריסת התמונה החתומה

פריסת תמונה לא חתומה

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

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

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

סוגי המחאות

יומן לדוגמה

הסרת המשאבים

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

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

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

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

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