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

הערה: במדריך הזה מניחים שקראתם את הסקירה הכללית על אישור בינארי.

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

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

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

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

מטרות

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

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

עלויות

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

• Artifact Registry
• Binary Authorization
• GKE
• Optional: Cloud Key Management Service

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

משתמשים חדשים של 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.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

Enable the Container Registry, Artifact Analysis and Binary Authorization APIs.

Roles required to enable APIs

To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

Enable the APIs

התקינו את ה-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.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

Enable the Container Registry, Artifact Analysis and Binary Authorization APIs.

Roles required to enable APIs

To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

Enable the APIs

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

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

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

gcloud init

1. מתקינים את kubectl.

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

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

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

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

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

6. לוחצים על זמינות, רשת, אבטחה ותכונות נוספות.

7. בקטע אבטחה, בוחרים באפשרות Binary Authorization.

8. בוחרים באפשרות אכיפה בלבד.

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

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

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

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

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

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

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

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

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

אזהרה: אנחנו ממליצים מאוד לא להשתמש בזוגות מפתחות שנוצרו באופן מקומי בסביבות ייצור, כי הם מהווים סיכון אבטחה. במקום זאת, מומלץ להשתמש ב-Cloud Key Management Service. הדוגמה הזו מיועדת להמחשה בלבד.

כדי ליצור זוג מפתחות 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. מוודאים שהתיבה יצירת הערה אוטומטית של Artifact Analysis מסומנת.

   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. לוחצים על Add 1 Attestor (הוספת מאמת אחד).

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) של האימות:

   הערה: בפקודה הבאה, נדרש ${IMAGE_PATH} כדי ליצור את מטען החתימה של האישור, אבל רק ${IMAGE_DIGEST} נמצא בשימוש בזמן הפריסה. המשמעות היא שאפשר לפרוס תמונת קונטיינר זהה מכמה מיקומים עם אותו אישור.

   Artifact Registry

   gcloud container binauthz create-signature-payload \
   --artifact-url=${IMAGE_PATH}@${IMAGE_DIGEST} > /tmp/generated_payload.json
   

   קובץ ה-JSON של המטען הייעודי מכיל את הפרטים הבאים:

   {
   "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

הסרת המשאבים

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

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

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

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

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