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

שימוש בבדיקה פשוטה של אימות החתימה

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

עלויות

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

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

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

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

התקינו את ה-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:
תפקידים שנדרשים להפעלת ממשקי API
כדי להפעיל ממשקי API, צריך את ההרשאה serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד 'בעלים' (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד 'אדמין בממשק Service Usage' (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידים
```
gcloud services enable binaryauthorization.googleapis.com cloudkms.googleapis.com container.googleapis.com
```

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

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

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

סקירה כללית

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

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

אם פרויקט האשכול שונה מפרויקט המדיניות: מעריך המדיניות של Binary Authorization (roles/binaryauthorization.policyEvaluator) בסוכן השירות של Binary Authorization בפרויקט האשכול, כדי שתהיה לו גישה לפרויקט המדיניות
אם פרויקט האישור שונה מפרויקט המדיניות: Container Analysis Occurrences Viewer (roles/containeranalysis.occurrences.viewer) on the policy project Binary Authorization Service Agent, for it to access the attestation project

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

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

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

כדי לוודא שלסוכן השירות של Binary Authorization בכל פרויקט יש את ההרשאות הנדרשות לבדיקת אימות החתימה הפשוטה של CV, צריך להקצות לסוכן השירות של 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 ATTESTATION_PROJECT_ID \
    --member="serviceAccount:$SERVICE_ACCOUNT" \
    --role='roles/containeranalysis.occurrences.viewer'
```
  מחליפים את ATTESTATION_PROJECT_ID במזהה הפרויקט שמכיל את האישורים.

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

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

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

אתם יכולים להשתמש ב-Cloud Key Management Service או במפתחות מקומיים, אבל אנחנו ממליצים להשתמש במפתחות של Cloud KMS בסביבת הייצור.

PKIX Cloud KMS

כדי ליצור את זוג המפתחות ב-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
KEY_FILE=KEY_FILE
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫KMS_KEY_PROJECT_ID: מזהה הפרויקט
- ‫KMS_KEYRING_NAME: שם לאוסף המפתחות ב-Cloud KMS
- ‫KMS_KEY_NAME: שם למפתח Cloud KMS
- ‫KEY_FILE: נתיב מקומי לשמירת מפתח 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}

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

gcloud kms keys versions get-public-key ${KMS_KEY_VERSION} \
    --key=${KMS_KEY_NAME} \
    --keyring=${KMS_KEYRING_NAME} \
    --location=${KMS_KEY_LOCATION} \
    --output-file=${KEY_FILE} \
    --project=${KMS_KEY_PROJECT_ID}

מפתח מקומי

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

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

PRIVATE_KEY_FILE="/tmp/ec_private.pem"
openssl ecparam -genkey -name prime256v1 -noout -out ${PRIVATE_KEY_FILE}

קבלת המפתח הציבורי מהמפתח הפרטי:

PUBLIC_KEY_FILE="/tmp/ec_public.pem"
openssl ec -in ${PRIVATE_KEY_FILE} -pubout -out ${PUBLIC_KEY_FILE}

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

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

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

PKIX Cloud KMS

cat > /tmp/my-policy.yaml << EOF
gkePolicy:
  checkSets:
  - checks:
    - simpleSigningAttestationCheck:
        containerAnalysisAttestationProjects:
        - projects/ATTESTATION_PROJECT_ID
        attestationAuthenticators:
          pkixPublicKeySet:
            pkixPublicKeys:
              publicKeyPem: |
$(awk '{printf "                %s\n", $0}' ${KEY_FILE})
              signatureAlgorithm: ECDSA_P256_SHA256
              keyId: |-
                //cloudkms.googleapis.com/v1/projects/${KMS_KEY_PROJECT_ID}/locations/${KMS_KEY_LOCATION}/keyRings/${KMS_KEYRING_NAME}/cryptoKeys/${KMS_KEY_NAME}/cryptoKeyVersions/${KMS_KEY_VERSION}
EOF

מחליפים את הערך ATTESTATION_PROJECT_ID במזהה של הפרויקט שבו מאוחסרים אישורים שנוצרו באמצעות מפתח Cloud KMS הזה.

מפתח מקומי

cat > /tmp/my-policy.yaml <<EOF
gkePolicy:
  checkSets:
  - checks:
    - simpleSigningAttestationCheck:
        containerAnalysisAttestationProjects:
        - projects/ATTESTATION_PROJECT_ID
        attestationAuthenticators:
          pkixPublicKeySet:
            pkixPublicKeys:
              publicKeyPem: |
$(awk '{printf "                %s\n", $0}' /tmp/ec_public.pem)
              signatureAlgorithm: ECDSA_P256_SHA256
              keyId: |
                PUBLIC_KEY_ID
EOF

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

‫ATTESTATION_PROJECT_ID: מזהה הפרויקט שבו מאוחסרות אישורים שנוצרו באמצעות המפתח המקומי
‫PUBLIC_KEY_ID: מזהה ייחודי של המפתח המקומי

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

לפני השימוש בנתוני הפקודה הבאים, צריך להחליף את הנתונים הבאים:
- ‫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
```
שומרים את ערך המזהה לשימוש מאוחר יותר:
```
PUBLIC_KEY_ID="PUBLIC_KEY_ID"
```
מחליפים את PUBLIC_KEY_ID במזהה שציינתם בשדה keyId בקובץ מדיניות הפלטפורמה קודם במדריך הזה.

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

הפעלת 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

יצירת אשכול שמשתמש באכיפה ובמעקב אחר 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

יצירת ההערה של ניתוח הארטיפקט

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

יוצרים את משתני ההערה:

NOTE_PROJECT_ID=NOTE_PROJECT_ID
NOTE_ID="test-note"
NOTE_URI="projects/${NOTE_PROJECT_ID}/notes/${NOTE_ID}"
DESCRIPTION="CV test note"

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

יוצרים את קובץ התוכן של ההערה:

cat > /tmp/note_payload.json << EOM
{
  "name": "${NOTE_URI}",
  "attestation": {
    "hint": {
      "human_readable_name": "${DESCRIPTION}"
    }
  }
}
EOM

יוצרים את הפתק:
```
curl -X POST \
    -H "Content-Type: application/json" \
    -H "Authorization: Bearer $(gcloud auth print-access-token)"  \
    -H "x-goog-user-project: ${NOTE_PROJECT_ID}" \
    --data-binary @/tmp/note_payload.json "https://containeranalysis.googleapis.com/v1/projects/${NOTE_PROJECT_ID}/notes/?noteId=${NOTE_ID}"
```
מחליפים את NOTE_PROJECT_ID במזהה הפרויקט שמכיל את ההערה.

זהירות: Binary Authorization לא תומך באחסון אזורי או בנקודות קצה אזוריות של Artifact Analysis. מומלץ להשתמש בנקודת קצה ל-API הגלובלית של Artifact Analysis ‏ (https://containeranalysis.googleapis.com/).

אופציונלי: כדי לוודא שיצרתם את ההערה:

curl \
    -H "Authorization: Bearer $(gcloud auth print-access-token)"  \
    -H "x-goog-user-project: NOTE_PROJECT_ID" \
"https://containeranalysis.googleapis.com/v1/projects/NOTE_PROJECT_ID/notes/"

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

קורות חיים לדוגמה

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

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

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

IMAGE_PATH="us-docker.pkg.dev/google-samples/containers/gke/hello-app"
IMAGE_DIGEST="sha256:37e5287945774f27b418ce567cd77f4bbc9ef44a1bcd1a2312369f31f9cce567"
IMAGE_TO_ATTEST="${IMAGE_PATH}@${IMAGE_DIGEST}"

יצירת אישור

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

אפשר ליצור אישור באמצעות ה-CLI של gcloud או API בארכיטקטורת REST.

PKIX Cloud KMS

gcloud

כדי ליצור אישור באמצעות ה-CLI של gcloud:

חותמים על קובץ האימג' ויוצרים את האימות באמצעות קידוד לפני אימות (PAE) (מומלץ):

gcloud beta container binauthz attestations sign-and-create \
    --artifact-url=${IMAGE_TO_ATTEST} \
    --keyversion=${KMS_KEY_VERSION} \
    --keyversion-key=${KMS_KEY_NAME} \
    --keyversion-keyring=${KMS_KEYRING_NAME} \
    --keyversion-location=${KMS_KEY_LOCATION} \
    --note=${NOTE_URI} \
    --pae-encode-payload \
    --dsse-type=DSSE_TYPE

מחליפים את DSSE_TYPE בסוג ה-DSSE לקידוד PAE. ערך ברירת המחדל של הדגל הוא application/vnd.dev.cosign.simplesigning.v1+json.

‫API בארכיטקטורת REST

כדי ליצור אימות (attestation) באמצעות ה-API בארכיטקטורת REST:

יוצרים קובץ מטען חתימה:

cat > /tmp/generated_payload.json << EOM
{
  "critical": {
    "identity": {
      "docker-reference": "${IMAGE_PATH}"
    },
    "image": {
      "docker-manifest-digest": "${IMAGE_DIGEST}"
    },
    "type": "Google Cloud BinAuthz container signature"
  }
}
EOM

חתימה על המטען הייעודי (payload):

gcloud kms asymmetric-sign \
    --version=${KMS_KEY_VERSION} \
    --key=${KMS_KEY_NAME} \
    --keyring=${KMS_KEYRING_NAME} \
    --location=${KMS_KEY_LOCATION} \
    --digest-algorithm=sha256 \
    --input-file=/tmp/generated_payload.json \
    --signature-file=/tmp/ec_signature \
    --project=${KMS_KEY_PROJECT_ID}

יוצרים את תוכן האימות:

cat > /tmp/attestation.json << EOM
{
"resourceUri": "${IMAGE_TO_ATTEST}",
"note_name": "${NOTE_URI}",
"attestation": {
  "serialized_payload": "$(base64 --wrap=0 /tmp/generated_payload.json)",
  "signatures": [{
    "public_key_id": "${PUBLIC_KEY_ID}",
    "signature": "$(base64 --wrap=0 /tmp/ec_signature)"
  }]
}
}
EOM

יוצרים את האישור:

curl -X POST "https://containeranalysis.googleapis.com/v1/projects/${NOTE_PROJECT_ID}/occurrences/" \
  -H "Content-Type: application/json" \
  -H "X-Goog-User-Project: ${NOTE_PROJECT_ID}" \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  --data-binary @/tmp/attestation.json

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

מפתח מקומי

gcloud

יוצרים קובץ מטען ייעודי (payload) של חתימה:

cat > /tmp/generated_payload.json << EOM
{
  "critical": {
    "identity": {
      "docker-reference": "${IMAGE_PATH}"
    },
    "image": {
      "docker-manifest-digest": "${IMAGE_DIGEST}"
    },
    "type": "Google Cloud BinAuthz container signature"
  }
}
EOM

יוצרים את קובץ המטען הייעודי (payload) של החתימה:

openssl dgst -sha256 -sign ${PRIVATE_KEY_FILE} /tmp/generated_payload.json > /tmp/ec_signature

יוצרים את האישור:

gcloud container binauthz attestations create \
    --project=ATTESTATION_PROJECT_ID \
    --artifact-url=${IMAGE_TO_ATTEST} \
    --note=${NOTE_URI} \
    --signature-file=/tmp/ec_signature \
    --public-key-id=PUBLIC_KEY_ID

‫API בארכיטקטורת REST

יוצרים קובץ מטען חתימה:

cat > /tmp/generated_payload.json << EOM
{
  "critical": {
    "identity": {
      "docker-reference": "${IMAGE_PATH}"
    },
    "image": {
      "docker-manifest-digest": "${IMAGE_DIGEST}"
    },
    "type": "Google Cloud BinAuthz container signature"
  }
}
EOM

יוצרים את קובץ המטען הייעודי (payload) של החתימה:

openssl dgst -sha256 -sign ${PRIVATE_KEY_FILE} /tmp/generated_payload.json > /tmp/ec_signature

יוצרים את תוכן האישור:

cat > /tmp/attestation.json << EOM
{
"resourceUri": "${IMAGE_TO_ATTEST}",
"note_name": "${NOTE_URI}",
"attestation": {
  "serialized_payload": "$(base64 --wrap=0 /tmp/generated_payload.json)",
  "signatures": [{
    "public_key_id": "${PUBLIC_KEY_ID}",
    "signature": "$(base64 --wrap=0 /tmp/ec_signature)"
  }]
}
}
EOM

יוצרים את האישור:

curl -X POST "https://containeranalysis.googleapis.com/v1/projects/${NOTE_PROJECT_ID}/occurrences/" \
  -H "Content-Type: application/json" \
  -H "X-Goog-User-Project: ${NOTE_PROJECT_ID}" \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  --data-binary @/tmp/attestation.json

פריסת קובץ האימג' שיש לו אישור

כדי לפרוס תמונה שעבורה נוצר אישור:

הגדרה של 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-with-attestation --image=$IMAGE_PATH@$IMAGE_DIGEST
```
ה-Pod נפרס. מכיוון שלתמונה יש אישור, ה-CV לא יוצר רשומות ביומן שקשורות ל-Pod הזה.

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

בקטע הזה תפרסו קובץ אימג' שלא משויך אליו אישור.

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

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

kubectl run hello-app-without-attestation \
   --image=$IMAGE_PATH@$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: מזהה הפרויקט של המדיניות

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

עלויות

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

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

סקירה כללית

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

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

PKIX Cloud KMS

מפתח מקומי

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

PKIX Cloud KMS

מפתח מקומי

‫Linux,‏ macOS או Cloud Shell

‏Windows (PowerShell)

Windows‏ (cmd.exe)

הפעלת CV

יצירת אשכול שמשתמש במעקב אחרי 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

gcloud

‫API בארכיטקטורת REST

מפתח מקומי

gcloud

‫API בארכיטקטורת REST

פריסת קובץ האימג' שיש לו אישור

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

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

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

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

סוגי המחאות

יומן לדוגמה

הסרת המשאבים

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

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

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

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

שימוש בבדיקה פשוטה של אימות החתימה