פריסת קונטיינרים (GKE, ‏ Distributed Cloud)

בדף הזה מוסבר איך לפרוס קובץ אימג' של קונטיינר לאשכול 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

פריסת קובץ האימג' של הקונטיינר

פורסים את קובץ האימג' של הקונטיינר באופן הבא:

  1. מגדירים משתני סביבה:

    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.

  2. פורסים את התמונה באמצעות הפקודה 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}
  

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