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

תחילת העבודה עם Google Cloud CLI‏ (GKE)

במדריך הזה מוסבר איך להגדיר ולבדוק מדיניות של Binary Authorization שדורשת אימותים (attestations). סוג המדיניות הזה מאבטח את שרשרת האספקה של התוכנה שמבוססת על קונטיינרים, על ידי אימות של קובץ אימג' של קונטיינר באמצעות אישור חתום לפני שמאפשרים את הפריסה של קובץ האימג'.

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

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

השלבים הבאים מתארים משימות שמבצעים בשורת הפקודה. כדי לבצע את השלבים האלה באמצעות מסוף Google Cloud , אפשר לעיין במאמר תחילת העבודה עם מסוף Google Cloud .

מטרות

במדריך הזה תלמדו איך:

יצירת אשכול Google Kubernetes Engine‏ (GKE) עם הפעלה של Binary Authorization
יצירת גורם מאמת (attestor) שהמערכת לאכיפת Binary Authorization משתמשת בו כדי לאמת את החתימה על אימות (attestation)
הגדרת מדיניות שדורשת אישור
יצירת זוג מפתחות קריפטוגרפיים לחתימה על אישורים ולאימות שלהם בהמשך
חתימה על תקציר של קובץ אימג' של קונטיינר, ליצירת חתימה
יצירת אישור באמצעות החתימה
בדיקת המדיניות באמצעות פריסת קובץ אימג' של קונטיינר ב-GKE

עלויות

במסמך הזה משתמשים ברכיבים הבאים של Google Cloud, והשימוש בהם כרוך בתשלום:

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

משתמשים חדשים של Google Cloud ? יכול להיות שאתם זכאים לתקופת ניסיון בחינם.

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

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

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

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

אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.

כדי לאתחל את ה-CLI של gcloud, הריצו את הפקודה הבאה:

gcloud init

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

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

אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.

כדי לאתחל את ה-CLI של gcloud, הריצו את הפקודה הבאה:

gcloud init

מתקינים את kubectl כדי ליצור אינטראקציה עם GKE.

הפעלת Binary Authorization

הגדרת פרויקט ברירת מחדל

השלב הראשון הוא להגדיר את פרויקט ברירת המחדל Google Cloud שבו משתמשת הפקודה gcloud:

PROJECT_ID=PROJECT_ID
gcloud config set project ${PROJECT_ID}

כאשר PROJECT_ID הוא שם הפרויקט.

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

הפעלת ממשקי API עבור:

Artifact Registry

gcloud --project=${PROJECT_ID} \
    services enable\
    container.googleapis.com\
    artifactregistry.googleapis.com\
    binaryauthorization.googleapis.com

יצירת אשכול עם Binary Authorization מופעל

יצירת האשכול

יוצרים אשכול GKE עם Binary Authorization מופעל. זהו האשכול שבו רוצים להפעיל את קובצי האימג' של הקונטיינרים שפרסתם. כשיוצרים את האשכול, מעבירים את הדגל --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE לפקודה gcloud container clusters create.

כדי ליצור את האשכול, מבצעים את השלבים הבאים:

gcloud container clusters create \
    --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE \
    --zone us-central1-a \
    test-cluster

בדוגמה הזו, יוצרים אשכול בשם test-cluster באזור GKE‏ us-central1-a.

הגדרה של `kubectl`

צריך גם לעדכן את קובץ kubeconfig המקומי בהתקנת kubectl. הפעולה הזו מספקת את פרטי הכניסה ופרטי נקודת הקצה שנדרשים כדי לגשת לאוסף ב-GKE.

כדי לעדכן את הקובץ המקומי kubeconfig:

gcloud container clusters get-credentials \
    --zone us-central1-a \
    test-cluster

הצגת מדיניות ברירת המחדל

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

Binary Authorization מאפשרת לייצא ולייבא קובץ מדיניות בפורמט YAML. הפורמט הזה משקף את המבנה של מדיניות כפי שהיא מאוחסנת בשירות. כשמגדירים מדיניות באמצעות פקודות gcloud, עורכים את הקובץ הזה.

כדי לראות את מדיניות ברירת המחדל, מייצאים את קובץ ה-YAML של המדיניות:

gcloud container binauthz policy export

כברירת מחדל, הקובץ מכיל את התוכן הבא:

defaultAdmissionRule:
  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
  evaluationMode: ALWAYS_ALLOW
globalPolicyEvaluationMode: ENABLE
name: projects/PROJECT_ID/policy

כלל ברירת המחדל מוגדר בצומת defaultAdmissionRule. ‫evaluationMode מציין שהמדיניות מאפשרת את כל הניסיונות לפריסת תמונות. במדריך הזה תלמדו איך לעדכן את כלל ברירת המחדל כדי לדרוש אישורים.

globalPolicyEvaluationMode החרגה של קובצי אימג' של המערכת שמנוהלים על ידי Google מאכיפת Binary Authorization.

כדי להוסיף תמונה שפטורה מהכללים לרשימת ההיתרים, מוסיפים את השורה הבאה לקובץ המדיניות:

admissionWhitelistPatterns:
  - namePattern: EXEMPT_IMAGE_PATH

מחליפים את EXEMPT_IMAGE_PATH בנתיב לתמונה שרוצים להחריג. כדי להחריג תמונות נוספות, מוסיפים עוד רשומות של - namePattern. מידע נוסף על admissionWhitelistPatterns

בדף העזר בנושא מדיניות YAML תוכלו לקרוא על המבנה של מדיניות.

יצירת גורם מאמת

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

כדי ליצור מאמת, צריך:

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

במדריך הזה יש מאמת אחד בשם test-attestor והערה של ניתוח מאגר תגים בשם test-attestor-note. בתרחיש מהעולם האמיתי, יכולים להיות מספר כלשהו של גורמים מאמתים (attestors), כשכל אחד מהם מייצג צד שמשתתף בתהליך ההרשאה של קובץ אימג' של קונטיינר.

יצירת ההערה של Artifact Analysis

מגדירים משתנים שמאחסנים את השם של גורם מאמת (attestor) ואת ההערה של Artifact Analysis
```
ATTESTOR_NAME=test-attestor
NOTE_ID=test-attestor-note
```
מחליפים את:
- ‫test-attestor: שם גורם מאמת שבחרתם.
- ‫attestor-note: שם הערה של מאמת לפי בחירתכם.

יוצרים קובץ JSON ב-/tmp/note_payload.json שמתאר את הערת ניתוח המאגר:

cat > /tmp/note_payload.json << EOM
{
  "name": "projects/${PROJECT_ID}/notes/${NOTE_ID}",
  "attestation": {
    "hint": {
      "human_readable_name": "Attestor Note"
    }
  }
}
EOM

יוצרים את ההערה על ידי שליחת בקשת HTTP ל-Artifact Analysis REST API:
```
curl -X POST \
    -H "Content-Type: application/json" \
    -H "Authorization: Bearer $(gcloud auth print-access-token)"  \
    --data-binary @/tmp/note_payload.json  \
    "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/?noteId=${NOTE_ID}"
```
זהירות: Binary Authorization לא תומך ב-Artifact Analysis באחסון אזורי או בנקודות קצה אזוריות. מומלץ להשתמש בנקודת קצה ל-API הגלובלית של Artifact Analysis ‏ (https://containeranalysis.googleapis.com/).

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

curl \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
"https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/${NOTE_ID}"

יצירת גורם מאמת

עכשיו אפשר ליצור את המאשר:

יוצרים את המאשר ב-Binary Authorization:

gcloud container binauthz attestors create ${ATTESTOR_NAME} \
--attestation-authority-note=${NOTE_ID} \
--attestation-authority-note-project=${PROJECT_ID}

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

gcloud container binauthz attestors list

אי אפשר להשתמש עדיין בגורם המאמת (attestor) שיצרתם בלי זוג מפתחות משויך, שאותו יוצרים בהמשך המדריך הזה.

בהגדרה של כמה פרויקטים, צריך להגדיר הרשאות בהערה של ניתוח מאגר התגים, כמו שמתואר במאמר בנושא הגדרה של כמה פרויקטים. ההרשאה הזו לא נדרשת בתרחיש של פרויקט יחיד, כי לפרויקט יש את ההרשאה הנדרשת roles/containeranalysis.notes.occurrences.viewer כברירת מחדל.

יצירת צמד מפתחות

ב-Binary Authorization משתמשים במפתחות קריפטוגרפיים כדי לאמת בצורה מאובטחת את הזהות של חותמים. כך מוודאים שאפשר לפרוס רק קובצי אימג' מורשים של קונטיינרים. זוג המפתחות מורכב ממפתח פרטי וממפתח ציבורי. החותם משתמש במפתח הפרטי כדי לחתום על ה-digest של קובץ אימג' של קונטיינר, וכך נוצרת חתימה שנשמרת באימות (attestation). המפתח הציבורי מאוחסן במאמת. בזמן הפריסה, כלי האכיפה של Binary Authorization משתמש במפתח הציבורי של גורם מאמת (attestor) כדי לאמת את החתימה באימות (attestation) לפני שהוא מאפשר את פריסת הקונטיינר.

במדריך הזה נשתמש בפורמט Public-Key Infrastructure (X.509) (PKIX)‎ למפתחות קריפטוגרפיים. במדריך הזה נעשה שימוש באלגוריתם המומלץ לחתימה דיגיטלית של עקומות אליפטיות (ECDSA) כדי ליצור זוג מפתחות PKIX. אפשר גם להשתמש במפתחות RSA או PGP לחתימה על תמונות.

מידע נוסף על אלגוריתמים לחתימה מופיע במאמר מטרות ואלגוריתמים של מפתחות.

המפתחות שנוצרים ומאוחסנים על ידי Cloud Key Management Service ‏ (Cloud KMS) תואמים ל-PKIX. מידע נוסף על שימוש במפתחות PKIX וב-Cloud KMS מופיע במאמר יצירת גורמים מאמתים (attestors) באמצעות ה-CLI של gcloud.

PKIX (Cloud KMS)

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

מגדירים את משתני הסביבה שנדרשים ליצירת זוג המפתחות.

KMS_KEY_PROJECT_ID=${PROJECT_ID}
KMS_KEYRING_NAME=my-binauthz-keyring
KMS_KEY_NAME=my-binauthz-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

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

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

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

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}

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

gcloud --project="${PROJECT_ID}" \
    container binauthz attestors public-keys add \
    --attestor="${ATTESTOR_NAME}" \
    --keyversion-project="${KMS_KEY_PROJECT_ID}" \
    --keyversion-location="${KMS_KEY_LOCATION}" \
    --keyversion-keyring="${KMS_KEYRING_NAME}" \
    --keyversion-key="${KMS_KEY_NAME}" \
    --keyversion="${KMS_KEY_VERSION}"

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

אפשר לראות את המזהה של המפתח הציבורי בכל שלב באמצעות הפקודה: gcloud container binauthz attestors describe <var>ATTESTOR_NAME</var>.

כדי לשמור את מזהה המפתח הציבורי במשתנה סביבה, מזינים את הפקודה הבאה:
```
PUBLIC_KEY_ID=$(gcloud container binauthz attestors describe ${ATTESTOR_NAME} \
--format='value(userOwnedGrafeasNote.publicKeys[0].id)' --project ${PROJECT_ID})
```

PKIX (מפתח מקומי)

כדי ליצור צמד מפתחות PKIX, פועלים לפי השלבים הבאים:

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

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}

מוסיפים את המפתח הציבורי למאמת.

עכשיו מוסיפים את המפתח הציבורי שייצאתם לגורם המאמת (attestor), כדי שניתן יהיה להשתמש בו ב-Binary Authorization לאימות זהות (IDV):
```
gcloud --project="${PROJECT_ID}" \
    container binauthz attestors public-keys add \
    --attestor="${ATTESTOR_NAME}" \
    --pkix-public-key-file=${PUBLIC_KEY_FILE} \
    --pkix-public-key-algorithm=ecdsa-p256-sha256
```
הערה: הפקודה הזו מחזירה את PUBLIC_KEY_ID שבו משתמשים כשיוצרים אישור. הוא מופיע בשדה id של הפלט ונראה כך: ni:///sha-256;ybf_gINTzsBKLCaRIeQnExNhKFkGONXXXlr63QeZY-Q.
שומרים את המזהה של המפתח הציבורי.

כדי לשמור את מזהה המפתח הציבורי, אפשר להעתיק אותו מהפלט של public-keys add שמופיע למעלה. כדי לראות את מזהה המפתח הציבורי של המאמת אחרי שמוסיפים אותו למאמת, משתמשים ב-gcloud container binauthz attestors describe ${ATTESTOR_NAME}:
```
PUBLIC_KEY_ID=$(gcloud container binauthz attestors describe ${ATTESTOR_NAME} \
  --format='value(userOwnedGrafeasNote.publicKeys[0].id)')
```

הגדרת המדיניות

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

כדי להגדיר את המדיניות, מבצעים את השלבים הבאים:

יוצרים קובץ מדיניות חדש שמאפשר תמונות מערכת שמתוחזקות על ידי Google, מגדירים את evaluationMode ל-REQUIRE_ATTESTATION ומוסיפים צומת בשם requireAttestationsBy שמפנה למאמת שיצרתם:

cat > /tmp/policy.yaml << EOM
    globalPolicyEvaluationMode: ENABLE
    defaultAdmissionRule:
      evaluationMode: REQUIRE_ATTESTATION
      enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
      requireAttestationsBy:
        - projects/${PROJECT_ID}/attestors/${ATTESTOR_NAME}
    name: projects/${PROJECT_ID}/policy
EOM

מייבאים את קובץ ה-YAML של המדיניות אל Binary Authorization:
```
gcloud container binauthz policy import /tmp/policy.yaml
```

מידע נוסף על הגדרת מדיניות זמין במאמר הגדרת מדיניות באמצעות ה-CLI של gcloud.

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

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

במדריך הזה אפשר להשתמש בתמונות לדוגמה מ-Artifact Registry. התמונה מ-Artifact Registry נמצאת בנתיב us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0. הנתיב מכיל תמונה ציבורית שנוצרה על ידי Google, שמכילה אפליקציה לדוגמה עם הכיתוב Hello, World!.

קודם כול, מנסים לפרוס את התמונה:

kubectl run hello-server --image us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0 --port 8080

עכשיו מאמתים שהפריסה נחסמה על ידי Binary Authorization:

kubectl get pods

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

No resources found.

אפשר לקבל פרטים נוספים על הפריסה:

kubectl get event --template \
'{{range.items}}{{"\033[0;36m"}}{{.reason}}:{{"\033[0m"}}\{{.message}}{{"\n"}}{{end}}'

תופיע תגובה שדומה לתגובה הבאה:

FailedCreate: Error creating: pods POD_NAME is forbidden: admission webhook "imagepolicywebhook.image-policy.k8s.io" denied the request: Image IMAGE_NAME denied by Binary Authorization default admission rule. Image IMAGE_NAME denied by attestor ATTESTOR_NAME: No attestations found

בפלט הזה:

‫POD_NAME: שם ה-Pod.
‫IMAGE_NAME: שם התמונה.
‫ATTESTOR_NAME: השם של הגורם המאמת.

חשוב למחוק את הפריסה כדי להמשיך לשלב הבא:

kubectl delete deployment hello-server

יצירת אישור

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

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

כדי ליצור אישור, מבצעים את השלבים הבאים:

מגדירים משתנים שמאחסנים את נתיב הרישום ואת ה-digest של התמונה:

Artifact Registry

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

כדי ליצור את האישור:
PKIX Cloud KMS
כדי ליצור את האישור באמצעות מפתח Cloud KMS, מריצים את הפקודה הבאה:
gcloud container binauthz attestations sign-and-create \ --project="${PROJECT_ID}" \ --artifact-url="${IMAGE_TO_ATTEST}" \ --attestor="${ATTESTOR_NAME}" \ --attestor-project="${PROJECT_ID}" \ --keyversion-project="${KMS_KEY_PROJECT_ID}" \ --keyversion-location="${KMS_KEY_LOCATION}" \ --keyversion-keyring="${KMS_KEYRING_NAME}" \ --keyversion-key="${KMS_KEY_NAME}" \ --keyversion="${KMS_KEY_VERSION}"
PKIX (מפתח מקומי)
כדי ליצור את האישור באמצעות המפתח המקומי:
1. יוצרים את המטען הייעודי (payload) של האימות:
  
  הערה: בפקודה הבאה, נדרש ${IMAGE_PATH} כדי ליצור את מטען החתימה לאישור, אבל רק ${IMAGE_DIGEST} נמצא בשימוש בזמן הפריסה. המשמעות היא שאפשר לפרוס תמונת קונטיינר זהה מכמה מיקומים עם אותו אישור.
  
  gcloud container binauthz create-signature-payload \ --artifact-url=${IMAGE_TO_ATTEST} > /tmp/generated_payload.json
  
  קובץ ה-JSON של המטען הייעודי מכיל את הפרטים הבאים:
  
  { "critical": { "identity": { "docker-reference": "us-docker.pkg.dev/google-samples/containers/gke/hello-app" }, "image": { "docker-manifest-digest": "sha256:c62ead5b8c15c231f9e786250b07909daf6c266d0fcddd93fea 882eb722c3be4" }, "type": "Google cloud binauthz container signature" } }
2. כדי לחתום על מטען הייעודי (payload) באמצעות המפתח הפרטי של PKIX וליצור קובץ חתימה, מריצים את הפקודה הבאה:
  
  openssl dgst -sha256 -sign ${PRIVATE_KEY_FILE} /tmp/generated_payload.json > /tmp/ec_signature
  
  קובץ החתימה הוא הגרסה החתומה של קובץ ה-JSON של המטען הייעודי (payload) שיצרתם קודם במדריך הזה.
3. יוצרים ומאמתים את האישור:
  
  gcloud container binauthz attestations create \ --project="${PROJECT_ID}" \ --artifact-url="${IMAGE_TO_ATTEST}" \ --attestor="projects/${PROJECT_ID}/attestors/${ATTESTOR_NAME}" \ --signature-file=/tmp/ec_signature \ --public-key-id="${PUBLIC_KEY_ID}" \ --validate
  
  מחליפים את PUBLIC_KEY_ID במזהה המפתח הציבורי שמצאתם בקטע יצירת צמד מפתחות PKIX למעלה.
  
  הדגל validate בודק שאפשר לאמת את האישור על ידי המאשר שהגדרתם במדיניות.

מוודאים שהאישור נוצר:

gcloud container binauthz attestations list \
    --attestor=$ATTESTOR_NAME --attestor-project=$PROJECT_ID

מידע נוסף על יצירת אישורים זמין במאמר יצירת אישורים.

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

שוב, בודקים את המדיניות על ידי פריסת קובץ אימג' של קונטיינר לדוגמה באשכול. הפעם, צריך לפרוס את התמונה באמצעות ה-digest ולא באמצעות תג כמו 1.0 או latest, כי Binary Authorization ישתמש ב-digest כדי לחפש אישורים. במקרה הזה, Binary Authorization מאפשרת לפרוס את התמונה כי נוצרה ההצהרה הנדרשת.

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

kubectl run hello-server --image ${IMAGE_TO_ATTEST} --port 8080

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

kubectl get pods

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

NAME                            READY     STATUS    RESTARTS   AGE
hello-server-579859fb5b-h2k8s   1/1       Running   0          1m

הסרת המשאבים

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

מוחקים את האשכול שיצרתם ב-GKE:

gcloud container clusters delete \
    --zone=us-central1-a \
    test-cluster

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

מידע נוסף על Binary Authorization
מושגי מפתח שמשמשים ב-Binary Authorization
שימוש בbuilt-by-cloud-build גורם מאמת (attestor) כדי לפרוס רק קובצי אימג' שנוצרו על ידי Cloud Build (גרסת טרום-השקה (Preview)).
הפעלת מצב הרצה יבשה כדי להשבית את האכיפה
שימוש ב-breakglass כדי לעקוף את האכיפה

תחילת העבודה עם Google Cloud CLI‏ (GKE) קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.

מטרות

עלויות

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

הפעלת Binary Authorization

הגדרת פרויקט ברירת מחדל

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

Artifact Registry

יצירת אשכול עם Binary Authorization מופעל

יצירת האשכול

הגדרה של kubectl

הצגת מדיניות ברירת המחדל

יצירת גורם מאמת

יצירת ההערה של Artifact Analysis

יצירת גורם מאמת

יצירת צמד מפתחות

PKIX (Cloud KMS)

PKIX (מפתח מקומי)

הגדרת המדיניות

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

יצירת אישור

Artifact Registry

PKIX Cloud KMS

PKIX (מפתח מקומי)

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

הסרת המשאבים

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

תחילת העבודה עם Google Cloud CLI‏ (GKE)

הגדרה של `kubectl`