Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

סקירה כללית על אימות רציף

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

כש-CV קובע שקבוצות Pod מפרות את מדיניות הפלטפורמה, הוא רושם את ההפרות ב-Cloud Logging.

תיקוף רציף (CV) עם מדיניות פלטפורמה מחליף את האימות המתמשך מהדור הקודם (יצא משימוש).

למה כדאי להשתמש ב-CV?

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

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

התכונה 'ערכי המרה' שימושית בתרחישים הבאים:

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

לכן, כשמעדכנים את מדיניות ה-project-singleton של Binary Authorization, מומלץ גם ליצור או לעדכן מדיניות פלטפורמת CV שתתאים למדיניות ה-project-singleton. כך, CV יודיע לכם על הפעלת Pods שמפרים את המדיניות המעודכנת שלכם.
מעקב אחרי מטא-נתונים של תמונות: CV מספק בדיקות ספציפיות לשינויים במטא-נתונים של תמונות, כולל:
- אישורים: יומני CV כשהאישורים בתמונות של ה-Pods כבר לא תקפים.
- עדכניות: ה-CV מתעד מתי הוא מזהה שתמונות של Pods כבר לא עדכניות.
- מקור: ‏CV יכול לבדוק שקובצי האימג' של ה-Pods נוצרו באמצעות כלי build מהימן, תוך שימוש בהגדרות build שנמצאות במאגר מקורות מהימן.
- חתימות Sigstore: יומני CV כאשר לתמונות של ה-Pods חסרה חתימת Sigstore תקינה.
- ספרייה מהימנה: ה-CV מתעד מקרים שבהם תמונות ה-Pods נמצאות בספריית מאגר שלא מופיעה במדיניות הפלטפורמה.
- נקודות חולשה: CV מתעד ביומן מקרים שבהם מזוהות נקודות חולשה בתמונות של Pods.
מעקב אחר הרצה יבשה: כשמפעילים הרצה יבשה, Binary Authorization מאפשרת פריסה של כל התמונות. אם מפעילים את CV עם מדיניות פלטפורמה שתואמת למדיניות של הפרויקט, ‏ CV מתעד באופן קבוע תמונות שמפירות את מדיניות הפלטפורמה.
מעקב אחרי breakglass: כשפורסים Pod באמצעות breakglass, הכלי Binary Authorization עוקף את אכיפת המדיניות של פרויקט-סינגלטון ומתעד אירוע יחיד ביומני הביקורת של Cloud. עם זאת, אם משתמשים במדיניות תואמת של הפלטפורמה,‏ CV ממשיך לרשום באופן קבוע ביומן את ה-Pods שמפירים את המדיניות, כולל ה-Pods שנפרסו באמצעות breakglass.

איך פועל ה-CV

כדי להשתמש ב-CV, צריך להפעיל אותו באשכולות GKE.

אחרי שפורסים תמונות באשכול, מערכת CV עוקבת אחרי ה-Pods המשויכים כדי לוודא שהם עומדים במדיניות הפלטפורמה שמבוססת על בדיקות.

‫CV לא תומך בתגי תמונות, למעט התגים שמפורטים בתמונות שפטורות מדרישות.

‫CV בודק באופן קבוע את ה-Pods הפועלים

כדי לעקוב אחרי הפעלת ה-Pods, מערכת ה-CV בודקת את התמונות שמשויכות לכל Pod לפחות כל 24 שעות. ‫CV גם עוקב אחרי קונטיינרים של init וקונטיינרים זמניים.

במהלך כל בדיקה, CV מאחזר רשימה של תמונות שמשויכות לכל Pod. לאחר מכן, מערכת ה-CV בודקת שפרטי התמונה עומדים בדרישות של מדיניות הפלטפורמה.

הפרות של מדיניות הפלטפורמה ביומני CV

כש-CV קובע שתמונות מפירות את מדיניות הפלטפורמה, הוא רושם את ההפרות ואת הממצאים האחרים ב-Cloud Logging. לכל הפרה של מדיניות הפלטפורמה, ולכל Pod, נכתבת רשומה נפרדת ביומן.

כש-CV מעריך תמונות ב-Pod באמצעות מדיניות פלטפורמה, יכול להיות שהתמונות יעברו חלק מהבדיקות ולא יעברו אחרות. הכלי CV יוצר רשומה ביומן בכל פעם שתמונה של פוד מפרה בדיקה כלשהי. רשומת היומן כוללת רק את תמונות ה-Pod שמפירות את מדיניות הפלטפורמה. אם כל התמונות עומדות בכל הבדיקות, לא נוצרות רשומות ביומן.

הכלי CV ממשיך לרשום הפרות מדיניות עד ש-Pod עם תמונות שלא עומדות בדרישות המדיניות מסתיים. כשמבטלים את הפעלתם של Pods שלא עומדים בדרישות המדיניות במהלך המרווח בין אימותים, יכול להיות שרשומות היומן הסופיות שנוצרו על ידי CV יופיעו אחרי הביטול, במהלך ההערכה הבאה של CV.

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

ה-CV לא מפסיק את הפעלת ה-Pods.

ה-CV משתמש במשאב פיד

כדי לאחזר מידע על Pods שפועלים באשכול GKE,‏ CV יוצר משאב פיד שנקרא binauthz-cv-cai-feed.

המדיניות של פלטפורמת ה-CV

כדי להשתמש ב-CV, צריך קודם להגדיר את כללי המדיניות של הפלטפורמה.

כללי המדיניות של הפלטפורמה שונים מכללי מדיניות מדור קודם של Binary Authorization, שנקראים גם כללי מדיניות של פרויקט יחיד. למרות שבפרויקט הפריסה יכולה להיות רק מדיניות אחת של singleton בפרויקט מדור קודם, אפשר להגדיר כמה מדיניות פלטפורמה. כל מדיניות פלטפורמה יכולה להיות ממוקמת בפרויקט אחד או יותר.

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

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

כללי המדיניות של הפלטפורמה הם ספציפיים לפלטפורמה. ‫GKE היא הפלטפורמה היחידה שנתמכת.

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

מדיניות הפלטפורמה יכולה לפטור תמונות מהערכה על ידי CV.

ההרשאות הנדרשות

כדי לראות את רשימת כללי המדיניות של הפלטפורמה או תיאור שלהם, צריך את התפקיד binaryauthorization.policyViewer. כדי ליצור, לשנות ולמחוק כללי מדיניות של פלטפורמה, צריך להיות לכם תפקיד binaryauthorization.policyEditor. מידע נוסף זמין במאמר בנושא ניהול מדיניות הפלטפורמה.

עדכוני מדיניות

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

מדיניות של כמה פלטפורמות

אפשר ליצור מדיניות פלטפורמה באותו פרויקט שבו נמצא האשכול (מדיניות פלטפורמה מקומית) או בכל פרויקט אחר.

אפשר להגדיר מספר מדיניות פלטפורמה, ולכן צריך לתת לכל אחת מהן שם משאב ייחודי. כשמריצים פקודת ה-CLI של gcloud, מתייחסים למדיניות הפלטפורמה המקומית באמצעות המזהה שלה. כשמפנים למדיניות פלטפורמה בפרויקט אחר, משתמשים בשם המשאב בפורמט הבא: projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID

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

כמה בדיקות לכל מדיניות של פלטפורמה

אפשר להגדיר כמה בדיקות בכל מדיניות של פלטפורמה על ידי הוספתן לבלוק checks של המדיניות. מידע נוסף על בדיקות ספציפיות שאפשר להגדיר זמין במאמר בנושא בדיקות.

אם במדיניות של פלטפורמת ה-CV מצוין יותר מבדיקה אחת, תמונות שנבדקות על ידי בדיקה אחת ממשיכות להיבדק על ידי הבדיקות האחרות.

במסגרת Binary Authorization, כל הבדיקות שמוגדרות במדיניות הפלטפורמה מוערכות לגבי כל תמונה, אלא אם התמונה תואמת לדפוס של רשימת ההיתרים של התמונות הפטורות. מידע נוסף מופיע במאמר Exempt images (תמונות שמוחרגות).

הגדרה של פרויקט יחיד

אפשר להגדיר CV בפרויקט אחד.

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

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

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

הגדרה של כמה פרויקטים

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

בהגדרה של כמה פרויקטים, חשוב להבין את המטרה של כל פרויקט ואת המשאבים ש-CV צריך לגשת אליהם ולהגדיר בהם את תפקידי ה-IAM וההרשאות הנדרשים בהתאם.

איך משתמשים ב-CV

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

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

המחאות

בקטע הזה מתוארים הבדיקות הספציפיות ש-CV מספק.

כללי מדיניות מבוססי-בדיקה הם בפורמט הקנוני הבא:

gkePolicy:
  checkSets:
  - checks:
    - CHECK_TYPE1:
        CHECK_TYPE1_PARAMETERS
      displayName: CHECK_TYPE1_DISPLAY_NAME
    - CHECK_TYPE2:
        CHECK_TYPE2_PARAMETERS
      displayName: CHECK_TYPE2_DISPLAY_NAME
    displayName: CHECK_SET_DISPLAY_NAME

השדה displayName ב-checks וב-checkSets הוא אופציונלי. הוא משמש רק כשהמערכת מזהה הפרות מדיניות ביומני ערכי המהימנות. הוא מושמט בחלק מהדוגמאות שמופיעות בהמשך המדריך הזה.

בדיקה של דחייה תמיד

הבדיקה 'תמיד דחייה' מבטיחה שכל התמונות שחלות עליה ייכשלו בהערכה. בכל פעם ש-CV בודק את ה-Pods הפעילים באמצעות הבדיקה הזו, הוא יוצר רשומה ביומן לכל אחד מה-Pods.

אתם יכולים לשלב את הבדיקה של 'תמיד דחייה' עם רשימות היתרים או עם כמה קבוצות של בדיקות כדי לוודא ש-Binary Authorization תמיד יוצרת יומנים עבור Pods במקרים מסוימים.

כדי להשתמש בבדיקה של דחייה תמיד, מוסיפים alwaysDeny: true לבלוק checks, באופן הבא:

gkePolicy:
  checkSets:
    - displayName: "My check set"
      checks:
        - alwaysDeny: true

אי אפשר להגדיר את הערך של alwaysDeny כ-false. במקום זאת, צריך לבטל את הסימון.

דוגמאות לשימוש בבדיקה של דחייה תמידית מופיעות במאמר שימוש בכמה קבוצות של בדיקות.

בדיקת רמת העדכניות של התמונה

בדיקת הרעננות של התמונה מחשבת את משך הזמן שהתמונה מוצגת ומתעדת מתי משך הזמן חורג מסף הזמן, maxUploadAgeDays.

בקובץ ה-YAML הבא של מדיניות הפלטפורמה, ה-CV מתעד Pods עם תמונות שהועלו למאגר שממנו הם נפרסו לפני יותר מ-30 יום.

gkePolicy:
  checkSets:
    checks:
    - imageFreshnessCheck:
        maxUploadAgeDays: 30
      displayName: "My image freshness check"
    displayName: "My check set"

בדיקת אימות חתימה פשוטה

אתם יכולים להשתמש בבדיקת אימות חתימה פשוטה של CV כדי לוודא שלכל אחת מהתמונות של Pod יש אימות חתימה תקף.

הבדיקה הזו מקבילה להערכת האימות במדיניות האכיפה של Binary Authorization. אפשר להגדיר את הבדיקה הזו עם אותן הערות ומפתחות שבהם השתמשתם בבודק. מומלץ להשתמש בבדיקה הזו במקום באימות רציף מדור קודם (הוצא משימוש).

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

gkePolicy:
  checkSets:
    checks:
      simpleSigningAttestationCheck:
        containerAnalysisAttestationProjects:
        - "projects/my-attestation-project1"
        - "projects/my-attestation-project2"
        attestationAuthenticators:
          pkixPublicKeySet:
            pkixPublicKeys:
              publicKeyPem: |
                -----BEGIN PUBLIC KEY-----
                MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQxXxgAEvgQuW1FHYZPB2PTQfOJKUkS9sjMO/1os10xOWrhl1kQo4EnzMOovROWVLo+m9mcwp7nRQ2qQDThZdSFi0nFJ1A==
                -----END PUBLIC KEY-----
              signatureAlgorithm: ECDSA_P256_SHA256

במקום גורמים מאמתים (attestors) של Binary Authorization, בדיקות האימות של CV כוללות רכיבי אימות (authenticators). אתם מציינים את אמצעי האימות ישירות במדיניות, בבלוק attestationAuthenticators.

במדיניות פלטפורמה, simpleSigningAttestationCheck יכול להכיל כמה attestationAuthenticators וכמה מפתחות בכל pkixPublicKeySet. הבדיקה מתבצעת כשכל התמונות של ה-Pods כוללות אישור חוקי שחתום באמצעות כל מפתח ב-pkixPublicKeySet של כל מאמת.

מדיניות הפלטפורמה של CV שונה ממדיניות האכיפה של פרויקט-סינגלטון בכמה היבטים:

אין תמיכה במפתחות PGP.
אין צורך במאמתים. במקום זאת, יוצרים מפתחות באופן ידני ואז מתארים מדיניות פלטפורמה כדי לאחזר את מזהה המפתח שבו משתמשים ליצירת האישור.
אתם יוצרים וחותמים באופן ידני על מטען הייעודי (payload), יוצרים את קובץ ה-JSON של האישור ויוצרים את האישור באמצעות Artifact Analysis API.
עדיין יוצרים הערה לניתוח ארטיפקטים, אבל לא מציינים אותה במדיניות. במקום זאת, CV מחפש אישורים בכל פרויקט שמופיע בשדה containerAnalysisAttestationProjects.
האישורים עדיין מאוחסנים במופעים של Artifact Analysis, אבל אפשר לאחסן אותם ביותר מפרויקט אחד.
צריך לציין באופן מפורש פרויקט אחד או יותר שמכילים אישורים באמצעות שם המשאב projects/ATTESTATION_PROJECT_ID.

‫CV לא תומך בתגי תמונות, למעט אלה שמצוינים ב-exempt images.

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

בדיקת SLSA

בדיקת ה-SLSA בודקת את המוצא שצוין ב-SLSA של תמונות ה-Pods.

הדוגמה הבאה מציגה הגדרת YAML של מדיניות פלטפורמת CV:

gkePolicy:
  checkSets:
    checks:
      imageAllowlist:
        allowPattern: "gcr.io/my-images/not-built-by-GCB/**"
    - slsaCheck:
        rules:
          trustedBuilder: GOOGLE_CLOUD_BUILD
          attestationSource:
          - containerAnalysisAttestationProjects: "projects/attestation-project1"
          - containerAnalysisAttestationProjects: "projects/attestation-project2"
          # Require that images were built using a checked-in top-level config file.
          configBasedBuildRequired: true
          # Which repos the config file can be from.
          trustedSourceRepoPatterns:
          - "source.cloud.google.com/my-project/my-source-repo"
          - "github.com/my-github-user/*"
      displayName: "My SLSA check"
    displayName: "My check set"

כשמערכת ה-CV בודקת תמונות באמצעות מדיניות הפלטפורמה הזו, היא בודקת את הדברים הבאים:

התמונות חייבות להיווצר על ידי builder מהימן. ‫Cloud Build הוא הכלי היחיד לבנייה מהימן שנתמך על ידי בדיקת SLSA.
האישורים צריכים להיווצר על ידי Cloud Build בפורמט attestation-project1 או attestation-project2.
התמונות צריכות להיבנות באמצעות קובץ הגדרה ברמה העליונה מאחד המאגרים המהימנים הבאים:
- המאגר source.cloud.google.com/my-project/my-source-repo/
- מאגרי מידע כלשהם בgithub.com/my-github-user/
התמונות ב-gcr.io/my-images/not-built-by-GCB/ או בספריות המשנה שלו (שלא נוצרו על ידי Cloud Build) פטורות מהבדיקה כי הן יפרו אותה.

בדיקת חתימה של Sigstore

בדיקת החתימה של Sigstore מאמתת שהתמונות נחתמו באמצעות חתימות של Sigstore.

הבדיקה הזו תומכת רק בתמונות שמארחים ב-Artifact Registry. הכלי בודק אם אפשר לאמת בהצלחה חתימה כלשהי שנשלפה מ-Artifact Registry באמצעות מפתח כלשהו במדיניות.

מדיניות הפלטפורמה הבאה לדוגמה מתארת איך להגדיר בדיקת חתימה של Sigstore:

  gkePolicy:
    checkSets:
    - checks:
      - displayName: sigstore-signature-check
        sigstoreSignatureCheck:
          sigstoreAuthorities:
          - displayName: sigstore-authority
            publicKeySet:
              publicKeys:
                publicKeyPem: |
                  -----BEGIN PUBLIC KEY-----
                  MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQxXxgAEvgQuW1FHYZPB2PTQfOJKUkS9sjMO/1os10xOWrhl1kQo4EnzMOovROWVLo+m9mcwp7nRQ2qQDThZdSFi0nFJ1A==
                  -----END PUBLIC KEY-----

במדיניות הפלטפורמה, sigstoreSignatureCheck יכול להכיל כמה sigstoreAuthorities וכמה מפתחות בכל publicKeySet. הבדיקה מתבצעת כשכל התמונות של ה-Pods כוללות אישור חוקי שחתום באמצעות כל מפתח ב-publicKeySet של כל מאמת.

בדיקה של ספרייה מהימנה

בדיקת הספרייה המהימנה בודקת שהתמונות של ה-Pods נמצאות באחת מהספריות המהימנות שצוינו במדיניות הפלטפורמה.

כשמשתמשים בבדיקה הזו, מומלץ גם להגן על המאגרים שמופיעים במדיניות בתור ספריות מהימנות מפני גישה לא מורשית.

בדוגמה הבאה של מדיניות פלטפורמה מתואר איך להגדיר בדיקה של ספרייה מהימנה:

gkePolicy:
  checkSets:
    checks:
      trustedDirectoryCheck:
        trustedDirPatterns:
        - "gcr.io/my-project/gcr-directory"
        - "us-central1-docker.pkg.dev/my-project/ar-directory"
        displayName: "My trusted directory check"
    displayName: "My check set"

בדוגמה למדיניות הפלטפורמה, trustedDirPatterns מפרט את הספריות המהימנות. אם כל התמונות של ה-Pods נמצאות בספריות שמופיעות ברשימה, הן עומדות בדרישות המדיניות. תמונות של פודים שלא נמצאות בספריות שמופיעות ברשימה מפירות את המדיניות, והפרות מתועדות ביומני CV.

בדיקת נקודות חולשה

בבדיקת הפגיעות נעשה שימוש בסריקת פגיעות של Artifact Analysis כדי לבדוק אם תמונות ה-Pods מכילות פגיעות. זה כולל נקודות חולשה חדשות שזוהו על ידי סריקת נקודות חולשה מאז הפריסה של ה-Pod. בבדיקת נקודות התורפה, אפשר להגדיר ספים של רמת חומרה של נקודת תורפה ונקודות תורפה ספציפיות (כ-CVE). תמונות עם נקודות חולשה שמפירות את בדיקת נקודות החולשה מתועדות ב-Logging.

כדי להשתמש בבדיקה הזו, צריך קודם להפעיל את סריקת הפגיעויות ב-Artifact Analysis.

הדוגמה הבאה להגדרת מדיניות פלטפורמה מכילה בדיקת פגיעות:

gkePolicy:
  checkSets:
    - displayName: "Default check set"
      checks:
        - vulnerabilityCheck:
           maximumFixableSeverity: MEDIUM
           maximumUnfixableSeverity: HIGH
           allowedCves:
             - "CVE-2022-11111"
             - "CVE-2022-22222"
           blockedCves:
             - "CVE-2022-33333"
             - "CVE-2022-44444"
           containerAnalysisVulnerabilityProjects: "projects/my-project"

בדוגמה, maximumUnfixableSeverity ו-maximumFixableSeverity מגדירים רמות חומרה של Common Vulnerability Scoring System (CVSS) שמשויכות לכל פגיעות ש-Artifact Analysis יכול לזהות. בנוסף, blockedCves מפרט נקודות חולשה או חשיפה נפוצות (CVE). אם נקודת חולשה מזוהה חורגת מאחת מרמות החומרה שצוינו או תואמת לאחת מנקודות החולשה הנפוצות (CVE) שמופיעות ב-blockedCves, והיא לא תואמת לאחת מנקודות החולשה הנפוצות (CVE) שמופיעות ב-allowedCves, אז CV רושם רשומה ב-Logging.

אימות של מדיניות מעודכנת

אחרי שמעדכנים את המדיניות של פלטפורמת CV, מומלץ מאוד לוודא ש-Binary Authorization ו-CV ממשיכים לפעול כצפוי.

אימות ההגדרה

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

אימות הפעולה

כדי לוודא ש-Binary Authorization ו-CV פועלים כמו שציפיתם, אתם יכולים לפרוס Pods לבדיקה ואז לבדוק את הרשומות של Binary Authorization ב-Logging.

תמונות שמוחרגות באמצעות רשימות היתרים

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

תבניות של רשימת היתרים הן תבניות שתואמות לכתובת URL אחת או יותר של תמונות. תבנית של רשימת היתרים יכולה להיות אחת מהאפשרויות הבאות:

תחילית של שם תמונה, שמסתיימת בתו הכללי * או **.
רק שם התמונה, בלי תג או תקציר.
שם תמונה עם תג (או קידומת תג עם התו הכללי *).
שם של תמונה עם תקציר.
שם תמונה עם תג ו-digest.

דוגמאות לדפוסי רשימת היתרים:

us-central1.pkg.dev/my-project/my-image:latest@sha256:77b0b75136b9bd0fd36fb50f4c92ae0dbdbbe164ab67885e736fa4374e0cbb8c תואם לשם, לתג ולערך הגיבוב של תמונה ספציפית.
‫us-central1.pkg.dev/my-project/my-image:latest תואם לשם ולתג, עם כל תקציר (או ללא תקציר).
‫us-central1.pkg.dev/my-image:foo* זהה לשם ולקידומת התג (למשל myimage:foo ו-myimage:foobar), עם או בלי תקציר.
us-central1.pkg.dev/my-project/my-image@sha256:77b0b75136b9bd0fd36fb50f4c92ae0dbdbbe164ab67885e736fa4374e0cbb8c תואם לשם ולתקציר, עם תג כלשהו (או ללא תג).
‫us-central1.pkg.dev/my-project/my-image תואם לשם, עם תג ו/או גיבוב.

אפשר להשתמש בתווים הכלליים לחיפוש * ו-** כדי להתאים לכל שם עם קידומת מסוימת. ‫* תואם לסיומות שלא כוללות את /. ‫** תואם לסיומות שיכולות לכלול /, אבל אפשר להשתמש ב-** רק אחרי /. שימו לב שאי אפשר להשתמש ב-* וב-** עם תגים או סיכומים.

לדוגמה:

‫us-central1.pkg.dev/my-project/my-image* תואם ל-us-central1.pkg.dev/myproject/my-image,‏ us-central1.pkg.dev/myproject/my-image1 ו-us-central1.pkg.dev/myproject/my-image2, עם כל תג או תקציר.
‫us-central1.pkg.dev/my-project/** תואם ל-us-central1.pkg.dev/myproject/my-image ול-us-central1.pkg.dev/my-project/some-directory/other-image, עם תג או תקציר כלשהו.

חשוב לשים לב שחובה להזין תחיליות לשמות ולתגיות. לכן, * או ** לבד לא מהווים תבנית תקינה, וגם לא us-central1.pkg.dev/my-image:*.

פטור ברמת המדיניות של GKE

בדוגמה הבאה מוצג איך להחריג תמונות ברמת מדיניות הפלטפורמה. כל התמונות בספריות exempt-images1 ו-exempt-images2 ובתיקיות המשנה שלהן לא נכללות במעקב אחר CV.

gkePolicy:
  imageAllowlist:
  - allowPattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images1/**"
  - allowPattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images2/**"
  checkSets:
      checks:
        ...

במדיניות, התמונות שמפורטות בקטע imageAllowlist פטורות מכל הבדיקות (checkSets) שמפורטות בקטע gkePolicy.

checkSet-level exemption

בדוגמה הבאה מוסבר איך להחריג תמונות ברמת קבוצת הבדיקות:

gkePolicy:
  checkSets:
    imageAllowlist:
    - allowPattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images1/**"
    - allowPattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images2/**"
    checks:
      ...

במדיניות, התמונות שמפורטות בקטע imageAllowlist פטורות מכל הבדיקות שמפורטות בקטע checkSets.

פטור ברמת הבדיקות

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

gkePolicy:
  checkSets:
    checks:
      imageAllowlist:
      - allowPattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images1/**"
      - allowPattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images2/**"
      ...

שימוש בכמה קבוצות של בדיקות

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

כל קבוצת בדיקות מוגבלת למרחב שמות של Kubernetes או לחשבון שירות של Kubernetes. ההיקף קובע לאילו פודים חלה קבוצת הבדיקות.

כשמגדירים היקף לסט של בדיקות, הוא חל רק על ה-Pods שפועלים בהיקף הזה.

כשקבוצת בדיקות לא כוללת היקף, היא נקראת קבוצת בדיקות שמוגדרת כברירת מחדל, כלומר הבדיקות חלות על כל ה-Pods, ללא קשר למרחב השמות של Kubernetes או להיקף של חשבון השירות.

רוב דוגמאות המדיניות במדריכים בנושא CV משתמשות רק בקבוצת בדיקות ברירת מחדל.

ההגדרה הבאה של מדיניות מגדירה שלוש קבוצות של בדיקות:

gkePolicy:
  checkSets:
    - displayName: "Prod check set"
      scope:
        kubernetesNamespace: "prod-namespace"
      checks:
        - trustedDirectoryCheck:
            trustedDirPatterns: "gcr.io/my-project/prod-images"
        - imageFreshnessCheck:
            maxUploadAgeDays: 30
    - displayName: "Dev check set"
      scope:
        kubernetesNamespace: "dev-namespace"
      checks:
        - trustedDirectoryCheck:
            trustedDirPatterns: "gcr.io/my-project/dev-images"
    - displayName: "Default check set"
      checks:
        - alwaysDeny: true

בהגדרת הדוגמה, קבוצת הבדיקות הראשונה מוגבלת ל-prod-namespace, ולכן הבדיקות שלה משפיעות רק על Pods שפועלים בהיקף הזה. הבדיקה השנייה מוגבלת ל-dev-namespace, ולכן הבדיקות שלה משפיעות רק על Pods שפועלים בהיקף הזה. ערכת הבדיקה השלישית היא ערכת בדיקה שמוגדרת כברירת מחדל. הבדיקות שלו חלות על כל ה-Pods באשכול שפועלים מחוץ להיקפים prod-namespace ו-dev-namespace.

כש-CV מעריך את קבוצת הבדיקות שנקראת Prod check set, הוא בודק את הדברים הבאים לגבי תמונות של Pods שפועלות במרחב השמות prod-namespace Kubernetes:

התמונות מאוחסנות בספרייה המהימנה prod-images.
התמונות הועלו ב-30 הימים האחרונים.

כש-CV מעריך את ערכת הבדיקה שנקראת Dev check set הוא מעריך את ה-Pods שפועלים במרחב השמות dev-namespace של Kubernetes, ובודק אם התמונות ב-Pod מגיעות מהספרייה dev-images.

הגדרת ברירת המחדל של הבדיקות פועלת כפתרון כללי. בדיקת ה-always-deny מוודאת ש-CV מתעד את כל ה-Pods שפועלים במרחב שמות אחר.

כדי להשתמש בחשבון שירות של Kubernetes כהיקף של קבוצת בדיקות, מחליפים את המפתח kubernetesNamespace בדוגמה ב-kubernetesServiceAccount. הערך הוא בפורמט my-namespace:my-service-account.

הכללים הבאים חלים על היקפי גישה מוגדרים:

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

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

CV מדור קודם

בקטע הזה מתוארת מדיניות CV מדור קודם. אם אתם חדשים ב-CV, מומלץ להשתמש במקום זאת ב-CV עם מדיניות מבוססת-בדיקות.

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

איך משתמשים ב-CV מדור קודם (הוצא משימוש) ואיך צופים באירועי CV מדור קודם ב-Cloud Logging