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

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

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

PROJECT_ID=PROJECT_ID

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

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

gcloud config set project ${PROJECT_ID}

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

יצירת האשכול

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

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

1. נכנסים לתפריט GKE במסוף Google Cloud .

   מעבר אל GKE

2. לוחצים על Create Cluster (יצירת אשכול).

3. מזינים test-cluster בשדה שם.

4. בוחרים באפשרות Zonal (אזורי) באפשרויות של Location type (סוג המיקום).

5. בתפריט הנפתח Zone, בוחרים באפשרות us-central1-a.

6. בחלונית הניווט, בקטע Cluster (אשכול), לוחצים על Advanced settings (הגדרות מתקדמות).

7. בשורה Binary authorization לוחצים על edit Edit configuration.

8. בוחרים באפשרות Binary Authorization.

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

10. לוחצים על יצירה.

הגדרה של kubectl

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

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

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

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

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

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

1. נכנסים לדף Binary Authorization במסוף Google Cloud .

   מעבר אל Binary Authorization

2. לוחצים על עריכת המדיניות.

3. בקטע Project Default Rule, מוצגת האפשרות Allow All Images.

4. לוחצים על שמירת המדיניות.

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

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

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

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

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

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

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

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

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

כדי ליצור זוג מפתחות PKIX:

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

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

2. מחילוץ המפתח הציבורי מהמפתח הפרטי:

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

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

עכשיו אפשר ליצור את מאמת ההצהרות עצמו ב-Binary Authorization ולשייך אליו את המפתח הציבורי שיצרתם.

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

1. חוזרים לדף Binary Authorization במסוף Google Cloud .

   חזרה אל Binary Authorization

2. בכרטיסייה Attestors, לוחצים על Create.

   

3. ממלאים את השדות לפי ההנחיות הבאות:

   1. מזינים test-attestor בשדה Attestor name.

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

   3. לוחצים על הוספת מפתח ציבורי של PKIX.

   4. פותחים את /tmp/ec_public.pem בכלי לעריכת טקסט. זהו קובץ המפתח הציבורי שיצרתם בשלב הקודם. מעתיקים את התוכן של הקובץ לתיבת הטקסט Public key material.

   5. לוחצים על Elliptic Curve P-256 - SHA256 Digest בתפריט הנפתח אלגוריתם חתימה.

   6. לוחצים על סיום.

4. לוחצים על יצירה כדי ליצור את הגורם המאשר.

5. מאחסנים את מזהה המפתח הציבורי.

   כדי להציג את מזהה המפתח הציבורי של הגורם המאשר אחרי שמוסיפים אותו לגורם המאשר, משתמשים בפונקציה gcloud container binauthz attestors describe ${ATTESTOR_NAME}. כדי ליצור משתנה סביבה לאחסון מזהה המפתח הציבורי, מריצים את הפקודה הבאה:

   ATTESTOR_NAME=test-attestor
   PUBLIC_KEY_ID=$(gcloud container binauthz attestors describe ${ATTESTOR_NAME}\
     --format='value(userOwnedGrafeasNote.publicKeys[0].id)')
   

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

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

1. חוזרים לדף Binary Authorization במסוף Google Cloud .

2. בכרטיסייה מדיניות, לוחצים על עריכת המדיניות.

3. בוחרים באפשרות Allow Only Images That Have Been Approved By the Following Attestors (אפשר להעלות רק תמונות שאושרו על ידי הגורמים הבאים).

4. לוחצים על הוספת מאשרים.

5. לוחצים על הוספה לפי שם הפרויקט והמאשר.

6. מזינים PROJECT_ID בשדה Project name (שם הפרויקט).

7. מזינים test-attestor בשדה Attestor name.

8. לוחצים על הוספת מאשר אחד.

9. לוחצים על שמירת המדיניות.

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

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

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

במדריך הזה אפשר להשתמש בתמונות לדוגמה מ-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_NAME: No attestations found

בפלט הזה:

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

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

kubectl delete deployment hello-server

יצירת אישור

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

במדריך הזה יוצרים אישור לתמונות לדוגמה מ-Artifact Registry.

כדי ליצור אישור:

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

   Artifact Registry

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

2. יוצרים את המטען הייעודי (payload) של האימות:

   Artifact Registry

   gcloud container binauthz create-signature-payload \
   --artifact-url=${IMAGE_PATH}@${IMAGE_DIGEST} > /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:37e5287945774f27b418ce567cd77f4bbc9ef44a1bcd1a2312369f31f9cce567"
     },
     "type": "Google cloud binauthz container signature"
   }
   }
   

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

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

   קובץ החתימה הוא גרסה חתומה דיגיטלית של קובץ ה-JSON של המטען הייעודי (payload) שיצרתם למעלה.

4. יצירה ואימות של האישור:

   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 בודק שאפשר לאמת את האישור על ידי המאשר שהגדרתם במדיניות.

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

   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_PATH}@${IMAGE_DIGEST} --port 8080

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

kubectl get pods

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

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

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

kubectl delete pod hello-server