בדף הזה מוסבר איך לפרוס קובץ אימג' של קונטיינר לאשכול GKE (ב-Google Cloud או ב-Google Distributed Cloud) שבו מופעלת Binary Authorization.
פקודות kubectl שבהן משתמשים כדי לפרוס את התמונה זהות לפקודות שבהן משתמשים כדי לפרוס תמונות באשכולות שלא נעשה בהם שימוש ב-Binary Authorization.
לפני שמתחילים
מוודאים ש-Binary Authorization API מופעל בפרויקט ושיש אשכול GKE עם Binary Authorization מופעל. הוראות להגדרה ב-Google Kubernetes Engine או הוראות להגדרה ב-Distributed Cloud
מתקינים את kubectl כדי ליצור אינטראקציה עם GKE.
הגדרה של kubectl
צריך לעדכן את קובץ kubeconfig המקומי בהתקנת kubectl.
כך מקבלים את פרטי הכניסה ונקודת הקצה שנדרשים לגישה לאשכול ב-GKE או ב-Distributed Cloud.
כדי להגדיר את kubectl, מריצים את הפקודה הבאה של gcloud:
GKE
gcloud container clusters get-credentials \
--zone ZONE \
CLUSTER_NAME
מחליפים את מה שכתוב בשדות הבאים:
- ZONE: השם של אזור GKE שבו האשכול פועל, למשל
us-central1-a - CLUSTER_NAME: שם האשכול
Distributed Cloud
gcloud container fleet memberships get-credentials \
--location LOCATION \
MEMBERSHIP_NAME
מחליפים את מה שכתוב בשדות הבאים:
- LOCATION: המיקום של החברות ב-Fleet של אשכול GKE, לדוגמה,
global - MEMBERSHIP_NAME: השם של החברות ב-Fleet של אשכול GKE
פריסת קובץ האימג' של הקונטיינר
פורסים את קובץ האימג' של הקונטיינר באופן הבא:
מגדירים משתני סביבה:
POD_NAME=POD_NAME IMAGE_PATH=IMAGE_PATH IMAGE_DIGEST=IMAGE_DIGESTמחליפים את מה שכתוב בשדות הבאים:
- POD_NAME: השם שרוצים להשתמש בו עבור עומס העבודה (workload) של GKE
- IMAGE_PATH: הנתיב של התמונה ב-Artifact Registry או במאגר אחר.
IMAGE_DIGEST: ה-digest של מניפסט התמונה. דוגמה:
- Artifact Registry:
- נתיב:
us-docker.pkg.dev/google-samples/containers/gke/hello-app - תקציר:
sha256:37e5287945774f27b418ce567cd77f4bbc9ef44a1bcd1a2312369f31f9cce567
- נתיב:
במאמר בנושא ניהול תמונות מוסבר איך מקבלים את ה-digest של תמונה ב-Artifact Registry.
- Artifact Registry:
פורסים את התמונה באמצעות הפקודה
kubectl run.חובה לפרוס את התמונה באמצעות ה-digest ולא באמצעות תג כמו
1.0אוlatest, כי Binary Authorization משתמש ב-digest כדי לחפש אישורים.כדי לפרוס את האימג', מריצים את הפקודה הבאה
kubectl:kubectl run ${POD_NAME} \ --image ${IMAGE_PATH}@${IMAGE_DIGEST}עכשיו מאמתים שהפריסה נחסמה על ידי Binary Authorization:
kubectl get pods
ה-Pod שלכם מופיע ברשימה.
שגיאת Fail Open
אם ל-GKE אין אפשרות להגיע לשרת של Binary Authorization מסיבה כלשהי, או אם השרת מחזיר שגיאה, ל-GKE אין אפשרות לקבוע אם Binary Authorization יאפשר או יחסום את התמונה. במקרה כזה, GKE נכשל בפתיחה: ברירת המחדל היא לאפשר את פריסת התמונה, אבל נוצרת רשומה ביומן ביומני הביקורת של Cloud כדי לתעד למה התמונה אושרה.
האכיפה של GKE נכשלת כי יש פה פשרה בין אמינות לאבטחה. GKE שולח בקשה ל-Binary Authorization בכל פעם שנוצר או מתעדכן Pod. זה כולל תרחישים שבהם יחידות Pod נוצרות או מתעדכנות באופן אוטומטי על ידי בקרי עומסי עבודה של Kubernetes ברמה גבוהה יותר, כמו ReplicaSets ו-StatefulSets. אם GKE נסגר במקום להיפתח, כל הפסקת שירות של Binary Authorization תגרום להפסקת הפעלת ה-Pods האלה. בנוסף, כשמתרחשת דחייה של Pods, יתירות כשל עלולה להוביל לכשלים מדורגים, כי תעבורת הנתונים שמופנית מחדש מעמיסה יתר על המידה על Pods שעדיין פועלים. כל הפסקה בשירות של Binary Authorization עלולה לגרום להשבתה מלאה של האשכול, גם בלי לפרוס תמונות חדשות.
פריסת תמונות שמפירות את המדיניות
ב-Binary Authorization יש תכונה שנקראת breakglass, שמאפשרת לפרוס תמונה גם אם היא מפרה את המדיניות.
מידע נוסף זמין במאמר בנושא שימוש בגישת חירום
הסרת המשאבים
כדי לנקות, מוחקים את ה-Pod על ידי הפעלת הפקודה הבאה:
kubectl delete pod ${POD_NAME}
המאמרים הבאים
- מידע נוסף על מצב הרצה יבשה
- איך משתמשים ב-CV
- איך משתמשים באימות רציף מדור קודם (יצא משימוש)
- איך משתמשים ב-digests של תמונות במניפסטים של Kubernetes