בתנאים ובהגבלות של Google Cloud Platform (בקטע 'הפסקת השירותים') מוגדרת מדיניות ההוצאה משימוש שחלה על Binary Authorization. מדיניות ההוצאה משימוש חלה רק על השירותים, התכונות או המוצרים המפורטים בה.
כשמוציאים משימוש שירותים, תכונות או מוצרים, הם ממשיכים להיות זמינים לפרק זמן מינימלי שמוגדר בתנאים ובהגבלות. אחרי פרק הזמן הזה, השירות יתוזמן להפסקה.
התמיכה ב-Binary Authorization בתיקוף רציף מדור קודם (CV מדור קודם) עם מדיניות של פרויקט יחיד ב-GKE תסתיים.
- החל מ-15 באפריל 2024, אי אפשר להפעיל את התכונה 'אימות תאימות מדור קודם' ב-Google Kubernetes Engine (GKE) בפרויקטים חדשים.
- הכלי Legacy CV ימשיך לעקוב אחרי ה-Pods של GKE באמצעות מדיניות של פרויקט יחיד בפרויקטים קיימים שבהם הוא כבר מופעל, עד 1 במאי 2025. אחרי 1 במאי 2025, הגרסה הקודמת של CV לא תנטר יותר את ה-Pods, ולא יופקו יותר רשומות ב-Cloud Logging לגבי תמונות של Pods שלא עומדות בדרישות של מדיניות אישור הבינארי (Binary Authorization) של הפרויקט.
החלפה: אימות רציף (CV) עם מדיניות פלטפורמה מבוססת-בדיקות
אפשר לעקוב אחרי הפודים באמצעות אימות רציף (CV) עם מדיניות פלטפורמה מבוססת-בדיקות.
בנוסף לתמיכה באישורים, מדיניות הפלטפורמה שמבוססת על בדיקות מאפשרת לכם לעקוב אחרי המטא-נתונים של תמונות קונטיינר שמשויכות ל-Pods שלכם, כדי לעזור לכם לצמצם בעיות אבטחה פוטנציאליות. כללי מדיניות שמבוססים על בדיקת CV מספקים בדיקות שכוללות את הפרטים הבאים:
- בדיקת פגיעוּת: המערכת בודקת את התמונה כדי לזהות נקודות חולשה באבטחה ברמת חומרה שאתם מגדירים.
- בדיקת Sigstore: לתמונה יש אישורים שחתומים על ידי Sigstore.
- בדיקת SLSA: קובץ האימג' נוצר ממקור בספרייה מהימנה על ידי כלי מהימן ליצירת גרסאות build.
- בדיקה של ספרייה מהימנה: התמונה צריכה להיות בספרייה מהימנה במאגר תמונות מהימן.
בדומה לאימות רציף מדור קודם, גם אימות רציף עם מדיניות מבוססת-בדיקות מתעד ביומן את הפודים עם תמונות שלא עומדות בדרישות.
אם אתם משתמשים באימות רציף מדור קודם (CV מדור קודם), כדאי לעיין במאמר בנושא העברה.
מידע נוסף על שימוש באימות רציף עם מדיניות פלטפורמה שמבוססת על בדיקות זמין במאמר בנושא סקירה כללית על אימות רציף.
העברה
כדי להעביר מדיניות מסוג singleton של פרויקט CV מדור קודם למדיניות פלטפורמה מקבילה שמבוססת על בדיקה, פועלים לפי השלבים הבאים:
- כדי ליצור מדיניות
ALWAYS_ALLOWproject-singleton, צריך ליצור מדיניות פלטפורמה מבוססת-בדיקה בליcheckSetblock. - כדי ליצור מדיניות
ALWAYS_DENYproject-singleton, יוצרים מדיניות פלטפורמה מבוססת-בדיקה עם בלוקcheckSetיחיד שיש לו בדיקהalwaysDeny. - כדי ליצור מדיניות מסוג project-singleton שדורשת אישורים, צריך ליצור מדיניות אחת מבוססת-בדיקות, ולכל מאשר במדיניות מסוג project-singleton, להוסיף SimpleSigningAttestationCheck אחד למדיניות מבוססת-בדיקות. אם משתמשים באותו צמד מפתחות, הבדיקה ממשיכה לפעול עם האישורים הקיימים, ומתבצע רישום ביומן רק של תמונות של Pod שלא כוללות אישורים תקפים.
מדיניות פלטפורמה שמבוססת על בדיקות מוגבלת לאשכול GKE, ולא לפרויקט Google Cloud . אחרי שיוצרים מדיניות פלטפורמה מבוססת-בדיקה, אפשר להחיל את המדיניות הזו על אשכול אחד או יותר.
כדי להפעיל CV עם מדיניות פלטפורמה מבוססת-בדיקות באשכול, צריך להגדיר את הגדרות Binary Authorization של האשכול במהלך תהליך היצירה או העדכון של האשכול.