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

תחילת העבודה עם 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.

Install the Google Cloud CLI.

If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

To initialize the gcloud CLI, run the following command:

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.

Install the Google Cloud CLI.

If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

To initialize the gcloud CLI, run the following command:

gcloud init

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

הפעלת Binary Authorization

לפני שמשתמשים ב-Binary Authorization, צריך להגדיר את פרויקט ברירת המחדל ולהפעיל את ממשקי ה-API הנדרשים של Google Cloud .

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

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

כדי להגדיר את סביבת Kubernetes, יוצרים אשכול עם Binary Authorization מופעל ומגדירים את kubectl כך שיפעל איתו.

יצירת האשכול

יוצרים אשכול 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 באזור us-central1-a ב-GKE.

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

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

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

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

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

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

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

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

יוצרים את ההערה על ידי שליחת בקשת HTTP ל-Artifact Analysis API בארכיטקטורת REST:
```
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 regional storage או regional endpoints. מומלץ להשתמש בנקודת הקצה הגלובלית ל-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) שיצרתם בלי זוג מפתחות משויך, שתיצרו בהמשך המדריך הזה.

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

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

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

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

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

המפתחות שנוצרים ומאוחסנים על ידי Cloud Key Management Service ‏ (Cloud KMS) תואמים ל-PKIX. מידע נוסף על שימוש במפתחות PKIX וב-Cloud KMS זמין במאמר יצירת מאמתים באמצעות ה-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}

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

עכשיו מוסיפים את המפתח הציבורי שייצאתם למאמת, כדי ש-Binary Authorization יוכל להשתמש בו לאימות הזהות:
```
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 של ה-payload מכיל את הפרטים הבאים:
  
  { "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 במזהה המפתח הציבורי שמצאתם בקטע יצירת זוג מפתחות.
  
  הדגל 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

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

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

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

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

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

PKIX (Cloud KMS)

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

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

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

יצירת אישור

Artifact Registry

PKIX Cloud KMS

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

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

הסרת המשאבים

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

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

הגדרה של `kubectl`