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

שימוש בבדיקת SLSA

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

כדי להשתמש בבדיקה הזו, צריך ליצור קובצי אימג' באמצעות Cloud Build, שמפיק נתוני מקור שתואמים ל-SLSA.

בדוגמה שבמדריך הזה, מאגר קוד המקור הוא Cloud Source Repositories, מאגר קובצי האימג' הוא Artifact Registry, והכלי שמשמש ליצירת קובץ האימג' והמקור שלו הוא Cloud Build.

הכלי לבדיקת SLSA תומך רק ב-Cloud Build ככלי בנייה מהימן.

עלויות

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

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

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

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

נכנסים לחשבון 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 של Artifact Registry, ‏Binary Authorization, ‏Cloud Build, ‏GKE ו-Cloud Source Repositories, אם הם עדיין לא מופעלים:

תפקידים שנדרשים להפעלת ממשקי API

כדי להפעיל ממשקי API, צריך את ההרשאה serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד "בעלים" (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד "אדמין בממשק 'שימוש בשירות'" (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידים

gcloud services enable artifactregistry.googleapis.com binaryauthorization.googleapis.com cloudbuild.googleapis.com container.googleapis.com sourcerepo.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 של Artifact Registry, ‏Binary Authorization, ‏Cloud Build, ‏GKE ו-Cloud Source Repositories, אם הם עדיין לא מופעלים:

תפקידים שנדרשים להפעלת ממשקי API

gcloud services enable artifactregistry.googleapis.com binaryauthorization.googleapis.com cloudbuild.googleapis.com container.googleapis.com sourcerepo.googleapis.com

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

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

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

סקירה כללית

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

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

‫Artifact Registry Reader (roles/artifactregistry.reader) בחשבון השירות של Compute Engine בפרויקט של האשכול
אם פרויקט האשכול שונה מפרויקט המדיניות: Binary Authorization Policy Evaluator (roles/binaryauthorization.policyEvaluator) on the cluster project Binary Authorization Service Agent, for it to access the policy project
אם פרויקט האישור שונה מפרויקט המדיניות: 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

כדי לוודא שלחשבונות השירות בכל פרויקט יש את ההרשאות הנדרשות להערכת הבדיקה הזו, צריך להקצות לחשבונות השירות בכל פרויקט את תפקידי ה-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 שמשויך לפרויקט המדיניות:

PROJECT_NUMBER=$(gcloud projects list \
  --filter="projectId:POLICY_PROJECT_ID" \
  --format="value(PROJECT_NUMBER)")
POLICY_PROJECT_SERVICE_ACCOUNT="service-$PROJECT_NUMBER@gcp-sa-binaryauthorization.iam.gserviceaccount.com"

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

הקצאת התפקיד:

gcloud projects add-iam-policy-binding ATTESTATION_PROJECT_ID \
    --member="serviceAccount:$POLICY_PROJECT_SERVICE_ACCOUNT" \
    --role='roles/containeranalysis.occurrences.viewer'

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

מתן הרשאה לחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine לשלוף את התמונה מהמאגר:
1. משיגים את חשבון השירות של Compute Engine שמשויך לפרויקט של האשכול:
```
PROJECT_NUMBER=$(gcloud projects list \
  --filter="projectId:CLUSTER_PROJECT_ID" \
  --format="value(PROJECT_NUMBER)")
COMPUTE_ENGINE_SERVICE_ACCOUNT="$PROJECT_NUMBER-compute@developer.gserviceaccount.com"
```
  מחליפים את CLUSTER_PROJECT_ID במזהה של פרויקט האשכול שמכיל את המדיניות.
2. הקצאת התפקיד:
```
gcloud projects add-iam-policy-binding ARTIFACT_PROJECT_ID \
    --member="serviceAccount:$COMPUTE_ENGINE_SERVICE_ACCOUNT" \
    --role='roles/artifactregistry.reader'
```
  מחליפים את ARTIFACT_PROJECT_ID במזהה של פרויקט Artifact Registry שבו מאוחסנים האימג'ים שרוצים לפרוס.

אופציונלי: יצירה והעלאה של תמונה לדוגמה

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

יצירת מאגר לדוגמה

כדי ליצור מאגר ב-Cloud Source Repositories, מבצעים את הפעולות הבאות:

יוצרים את המאגר ומשכפלים אותו באופן מקומי:
```
gcloud source repos create SOURCE_REPO_NAME \
    --project=SOURCE_REPO_PROJECT_ID && \
gcloud source repos clone SOURCE_REPO_NAME \
    --project=SOURCE_REPO_PROJECT_ID && \
cd SOURCE_REPO_NAME
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫SOURCE_REPO_NAME: שם המאגר של קוד המקור, לדוגמה: slsa-check-test-repo
- ‫SOURCE_REPO_PROJECT_ID: מזהה הפרויקט של המאגר
כדי ליצור את קובצי המקור, התצורה וה-build:
1. יוצרים את מקור התמונה:
```
cat > quickstart.sh <<EOF
#!/bin/sh
echo "Hello, world! The time is $(date)."
sleep infinity
EOF
```
2. הופכים את הקובץ לקובץ הפעלה:
```
chmod +x quickstart.sh
```
3. יוצרים את קובץ התצורה Dockerfile:
```
cat > Dockerfile <<EOF
FROM alpine
COPY quickstart.sh /
CMD ["/quickstart.sh"]
EOF
```
4. יוצרים את קובץ Cloud Build‏ cloudbuild.yaml, שמעביר בדחיפה את קובץ האימג' ל-Artifact Registry:
```
cat > cloudbuild.yaml <<EOF
steps:
- name: 'gcr.io/cloud-builders/docker'
  args: [ 'build', '-t', 'LOCATION-docker.pkg.dev/ARTIFACT_PROJECT_ID/ARTIFACT_REPO_NAME/DIRECTORY/IMAGE', '.' ]
options:
  requestedVerifyOption: VERIFIED
images:
- 'LOCATION-docker.pkg.dev/ARTIFACT_PROJECT_ID/ARTIFACT_REPO_NAME/DIRECTORY/IMAGE'
EOF
```
  מחליפים את מה שכתוב בשדות הבאים:
  - ‫LOCATION: המיקום של Artifact Registry, לדוגמה: us-west2, ‏ europe-central2 או asia-east1
  - ‫ARTIFACT_PROJECT_ID: המזהה של הפרויקט שבו מאוחסנים ארטיפקטים של Artifact Registry
  - ‫ARTIFACT_REPO_NAME: שם המאגר ב-Artifact Registry, לדוגמה: slsa-check-test-repo
  - DIRECTORY: הספרייה, לדוגמה: slsa-check
  - ‫IMAGE: הנתיב לתמונה, לדוגמה: slsa-check-image
5. מבצעים קומיט של הקבצים ב-Cloud Source Repositories:
```
git add .
git commit -a
```

יצירה והעלאה של קובץ האימג' לדוגמה

כדי להקל על השימוש במדריך הזה, מומלץ להשתמש באותו פרויקט גם ל-SOURCE_REPO_PROJECT_ID וגם ל-ARTIFACT_PROJECT_ID. אם אתם משתמשים בפרויקטים שונים, יכול להיות שתצטרכו להגדיר הרשאות IAM נוספות. מידע נוסף על בקרת גישה ב-Artifact Registry מידע נוסף על Cloud Build זמין במאמר סקירה כללית על Cloud Build.

כדי ליצור את המאגר:

יוצרים את מאגר Artifact Registry:
```
gcloud artifacts repositories create ARTIFACT_REPO_NAME \
    --project=ARTIFACT_PROJECT_ID \
    --repository-format=docker \
    --location=LOCATION \
    --description="Docker repository"
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫ARTIFACT_REPO_NAME: השם של המאגר
- ‫ARTIFACT_PROJECT_ID: מזהה הפרויקט של הארטיפקט
- ‫LOCATION: המיקום של Artifact Registry, לדוגמה: us-west2, ‏ europe-central2 או asia-east1
יוצרים את הטריגר לפיתוח גרסת Build ב-Cloud Build:
```
gcloud beta builds triggers create cloud-source-repositories \
    --project=SOURCE_REPO_PROJECT_ID \
    --repo=SOURCE_REPO_NAME \
    --region=LOCATION \
    --branch-pattern=.* \
    --build-config=cloudbuild.yaml
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫SOURCE_REPO_NAME: שם מאגר קוד המקור
- ‫SOURCE_REPO_PROJECT_ID: מזהה הפרויקט ב-Cloud Build
- ‫LOCATION: המיקום
מפעילים build על ידי שליחת הקבצים שיצרתם קודם במדריך הזה.
```
git push
```
כשקובץ האימג' נוצר בהצלחה, Cloud Build יוצר נתוני מקור ומעלה את קובץ האימג' למאגר שלכם ב-Artifact Registry.
כדי לבדוק מהי התמונה העדכנית ביותר ולקבל את התקציר שלה:
1. מוודאים ש-Cloud Build יצר את קובץ האימג':
```
gcloud artifacts docker images list LOCATION-docker.pkg.dev/ARTIFACT_PROJECT_ID/REPO_NAME/DIRECTORY \
    --project=ARTIFACT_PROJECT_ID \
    --sort-by=create_time
```
  מחליפים את מה שכתוב בשדות הבאים:
  - ‫LOCATION: המיקום של Artifact Registry
  - ‫ARTIFACT_PROJECT_ID: מזהה הפרויקט של הארטיפקטים
  - ‫ARTIFACT_REPO_NAME: שם המאגר
  - ‫DIRECTORY: הספרייה
2. מעתיקים את התקציר של התמונה האחרונה. התקציר נראה כך: sha256:9432f747bd058b33de33bb5314d6eec1ac357d664e04c76824bb7072a9218d59

אופציונלי: כדי לראות את מקור התמונה:

gcloud artifacts docker images describe \
  LOCATION-docker.pkg.dev/ARTIFACT_PROJECT_ID/ARTIFACT_REPO_NAME/DIRECTORY/IMAGE@DIGEST \
    --project=ARTIFACT_PROJECT_ID \
    --show-provenance

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

‫ARTIFACT_PROJECT_ID: מזהה הפרויקט של הארטיפקטים
‫LOCATION: המיקום ב-Artifact Registry
‫ARTIFACT_REPO_NAME: שם מאגר הארטיפקטים
‫DIRECTORY: הספרייה
IMAGE: הנתיב לתמונה
‫DIGEST: ה-digest שמשויך לתמונה

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

image_summary:
  digest: sha256:9432f747bd058b33de33bb5314d6eec1ac357d664e04c76824bb7072a9218d59
  fully_qualified_digest: us-west2-docker.pkg.dev/my-project/slsa-check-repo/slsa-check-image@sha256:9432f747bd058b33de33bb5314d6eec1ac357d664e04c76824bb7072a9218d59
  registry: us-west2-docker.pkg.dev
  repository: slsa-check-repo
  slsa_build_level: 3
provenance_summary:
  provenance:
  - build:
      intotoStatement:
        _type: https://in-toto.io/Statement/v0.1
        predicateType: https://slsa.dev/provenance/v0.1
        slsaProvenance:
          builder:
            id: https://cloudbuild.googleapis.com/GoogleHostedWorker
          materials:
          - digest:
              sha1: de4e4227fff1d00d6f7785a827608627e4a369ea
            uri: git+https://source.cloud.google.com/my-project/slsa-check-source-repo
          metadata:
            ...
envelope:
  payload: eyJfdHlwZSI6I ... taW1hZ2U6dGFnMSJ9XX0=
  payloadType: application/vnd.in-toto+json
  signatures:
  - keyid: projects/verified-builder/locations/global/keyRings/attestor/cryptoKeys/provenanceSigner/cryptoKeyVersions/1
    sig: MEQCIBCCkho_re4EfAT-NBSSmAXOZlv4lU_vWzEru97tU8KmAiAKcAa99umWngzNQADmPixqYjbKjLOKQEUvrI5chSrf7g==
  - keyid: projects/verified-builder/locations/global/keyRings/attestor/cryptoKeys/builtByGCB/cryptoKeyVersions/1
    sig: MEUCIFOEq_7RpiZAB4vUlit3hkZ2yI0n37-5Y87l0JbU-EZSAiEA9TNZZcv_MnzKffTnswHWZR2DSLmYiklr5twWfIec-zo=

הפלט חייב להכיל את הבלוק provenance_summary כדי שהבדיקה של SLSA תפעל. אם הפלט לא מכיל את הבלוק, בודקים ש-Cloud Build הופעל על ידי טריגר לפיתוח גרסת Build. ‫Cloud Build לא יוצר מידע על מקורות כשהוא מופעל באופן ידני.

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

כדי ליצור את נתוני המקור, צריך להשתמש בטריגר לפיתוח גרסת Build של Cloud Build כדי ליצור את קובץ האימג', כמו שמתואר במאמר יצירה והעלאה של קובץ האימג' לדוגמה.

כדי ליצור מדיניות פלטפורמה עם בדיקת SLSA:

יוצרים את קובץ ה-YAML של מדיניות הפלטפורמה:
```
cat > POLICY_PATH <<EOF
gkePolicy:
  checkSets:
  - checks:
    - displayName: My SLSA check
      imageAllowlist:
        # This policy exempts images that are in the following artifact registry
        allowPattern:
        - ARTIFACT_LOCATION-docker.pkg.dev/ARTIFACT_PROJECT_ID/ARTIFACT_REPO_NAME/EXEMPT_IMAGE_PATH/**
      slsaCheck:
        rules:
        - attestationSource:
            containerAnalysisAttestationProjects:
            - projects/ATTESTATION_PROJECT_ID
          configBasedBuildRequired: true
          trustedBuilder: GOOGLE_CLOUD_BUILD
          trustedSourceRepoPatterns:
          - source.cloud.google.com/SOURCE_REPO_PROJECT_ID/SOURCE_REPO_NAME
          customConstraints: CEL_EXPRESSION
    displayName: My check set
EOF
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫POLICY_PATH: נתיב לקובץ המדיניות.
- ‫ARTIFACT_LOCATION: המיקום של המאגר ב-Artifact Registry.
- ‫ARTIFACT_PROJECT_ID: מזהה הפרויקט שמכיל את הארטיפקטים.
- ‫ARTIFACT_REPO_NAME: המאגר שמכיל את קובץ האימג'.
- ‫EXEMPT_IMAGE_PATH: נתיב אופציונלי לאחת או יותר תמונות שמוחרגות. לדוגמה: not-built-by-cloud-build. הבלוק imageAllowlist נכלל במדיניות הפלטפורמה הזו כדי שתוכלו להחריג תמונות שאין להן מקור, כך שהן לא יפרו את מדיניות הפלטפורמה. כדי לרשום במקום זאת הפרות מהתמונות האלה, משמיטים את הבלוק הזה.
- ‫ATTESTATION_PROJECT_ID: מזהה הפרויקט שבו מאוחסרים האישורים שנוצרו על ידי Cloud Build.
- ‫SOURCE_REPO_PROJECT_ID: מזהה הפרויקט שמכיל את קוד המקור.
- ‫SOURCE_REPO_NAME: המאגר שמכיל את התמונה. לדוגמה, כדי לאלץ הפרה של הבדיקה הזו, מגדירים את SOURCE_REPO_NAME למאגר קוד מקור שונה מזה שבו נמצאת התמונה.
- ‫POLICY_PROJECT_ID: מזהה הפרויקט שמכיל את מדיניות ה-CV.
- POLICY_ID: המזהה של המדיניות הזו.
- ‫CEL_EXPRESSION: ביטוי CEL שמספק אילוצים נוספים למדיניות SLSA. לדוגמה, כדי להוסיף אילוץ מותאם אישית שדורש שהתמונות יגיעו מנתיב ספציפי של ספרייה, מחליפים את CEL_EXPRESSION בביטוי הבא:
```
payload.predicate.externalParameters.buildConfigSource.path != "" && payload.predicate.externalParameters.buildConfigSource.repository.contains("github.com/my-repo/my-production-repo")
```
יוצרים את מדיניות הפלטפורמה:

לפני השימוש בנתוני הפקודה הבאים, צריך להחליף את הנתונים הבאים:
- 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

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

הגדרה של kubectl:
```
gcloud container clusters get-credentials CLUSTER_NAME \
    --location=LOCATION \
    --project=CLUSTER_PROJECT_ID
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫CLUSTER_NAME: השם של האשכול
- ‫LOCATION: המיקום של האשכול
- ‫CLUSTER_PROJECT_ID: מזהה הפרויקט של האשכול
פורסים את ה-Pod:
```
kubectl run hello-app \
    --image='LOCATION-docker.pkg.dev/ARTIFACT_PROJECT_ID/ARTIFACT_REPO_NAME/DIRECTORY/IMAGE@DIGEST'
```
ה-Pod נפרס. מכיוון שה-image נוצר עם מקוריות וממאגר המקורות של הקוד מהימן, הוא לא יפר את בדיקת ה-CV SLSA ולא ייווצרו רשומות ביומן.

כדי לגרום להפרה של בדיקת SLSA, אפשר להגדיר את SOURCE_REPO_NAME למאגר קוד מקור שונה מזה שבו נמצא קובץ האימג'. אפשר גם להפעיל את ה-build באופן ידני, וכך לדלג על יצירת המקור. לאחר מכן, בודקים אם יש רשומות ביומן.

הצגת יומנים של רשומות CV

אפשר לחפש רשומות יומן ב-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: מזהה הפרויקט של המדיניות

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

עלויות

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

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

סקירה כללית

הקצאת תפקידים באמצעות ה-CLI של 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)

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

הצגת יומנים של רשומות CV

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

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

סוגי הבדיקות

יומן לדוגמה

הסרת המשאבים

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

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

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

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

שימוש בבדיקת SLSA