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

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

בדף הזה מוסבר איך להשתמש ב-בדיקת SLSA של אימות רציף (CV) ב-Binary Authorization. הבדיקה הזו בודקת את מקורות המידע (provenance) של קובצי אימג' בקונטיינרים שתואמים ל-SLSA, שמשויכים ל-Pods שפועלים באשכולות 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, צריך את תפקיד ה-IAM 'אדמין של Service Usage' (roles/serviceusage.serviceUsageAdmin), שכולל את ההרשאה serviceusage.services.enable. איך מקצים תפקידים

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

קורא של Artifact Registry (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. בהמשך המדריך נשתמש בנתוני המקור כדי להדגים את הבדיקה. מידע נוסף על אישור המקור של Build ב-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

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

פריסת התמונה

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

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

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

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

{
  "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: מזהה הפרויקט של המדיניות

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

עלויות

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

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

סקירה כללית

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

פריסת התמונה

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

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

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

סוגי המחאות

יומן לדוגמה

הסרת המשאבים

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

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

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

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

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