ארכיון עדכוני אבטחה דחופים

בדף הזה מופיע ארכיון היסטורי של כל עדכוני האבטחה לפני 2020 למוצרים הבאים:

Google Kubernetes Engine (GKE)‎
‫Google Distributed Cloud

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

עדכוני אבטחה דחופים ל-GKE

14 בנובמבר 2019

תאריך פרסום: 14 בנובמבר 2019
תאריך עדכון: 14 בנובמבר 2019

תיאור רמת סיכון הערות

תיאור	רמת סיכון	הערות
ב-Kubernetes חשפו בעיית אבטחה ב-sidecars של kubernetes-csi‏ `external-provisioner`,‏ `external-snapshotter` ו-`external-resizer` שמשפיעה על רוב הגרסאות של ה-sidecars שצורפו למנהלי התקנים של Container Storage Interface‏ (CSI). פרטים נוספים זמינים בגילוי הנאות בנושא Kubernetes. פעולות מומלצות נקודת החולשה הזו לא משפיעה על רכיבי GKE מנוהלים. הבעיה הזו עלולה להשפיע עליכם אם אתם מנהלים בעצמכם את מנהלי ה-CSI באשכולות אלפא של GKE שמריצים את גרסה 1.12 של GKE או גרסה חדשה יותר. אם אתם מושפעים מהבעיה, כדאי לפנות לספק של מנהל ההתקן של CSI כדי לקבל הוראות לשדרוג. אילו נקודות חולשה טופלו במסגרת התיקון הזה? CVE-2019-11255: זוהי נקודת חולשה ב-sidecars של `kubernetes-csi` `external-provisioner`, `external-snapshotter`, ושל `external-resizer` שיכולה לאפשר גישה לא מורשית לנתוני נפח או שינוי שלהם. הבעיה הזו משפיעה על רוב הגרסאות של רכיבי ה-sidecar שכלולים בדרייברים של CSI.	בינוני	CVE-2019-11255

ב-Kubernetes חשפו בעיית אבטחה ב-sidecars של kubernetes-csi‏ external-provisioner,‏ external-snapshotter ו-external-resizer שמשפיעה על רוב הגרסאות של ה-sidecars שצורפו למנהלי התקנים של Container Storage Interface‏ (CSI). פרטים נוספים זמינים בגילוי הנאות בנושא Kubernetes.

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

אילו נקודות חולשה טופלו במסגרת התיקון הזה?
CVE-2019-11255: זוהי נקודת חולשה ב-sidecars של kubernetes-csi external-provisioner, external-snapshotter, ושל external-resizer שיכולה לאפשר גישה לא מורשית לנתוני נפח או שינוי שלהם. הבעיה הזו משפיעה על רוב הגרסאות של רכיבי ה-sidecar שכלולים בדרייברים של CSI.

בינוני

CVE-2019-11255

12 בנובמבר 2019

תאריך פרסום: 12 בנובמבר 2019
תאריך עדכון: 12 בנובמבר 2019

תיאור רמת סיכון הערות

תיאור	רמת סיכון	הערות
חברת Intel חשפה CVEs שמאפשרים אינטראקציות בין ביצוע ספקולטיבי לבין מצב מיקרו-ארכיטקטוני, שעשויות לחשוף נתונים. פרטים נוספים זמינים בדיווח של Intel. תשתית המארח שמריצה את Kubernetes Engine מבודדת את עומסי העבודה של הלקוחות. אלא אם אתם מריצים קודים לא מהימנים בתוך אשכולות GKE מרובי-דיירים משלכם וגם משתמשים בצמתים מסוג N2, ‏ M2 או C2, לא נדרשת פעולה נוספת. במקרים של מכונות GKE בצמתי N1, לא נדרשת פעולה חדשה. אם אתם מריצים את Google Distributed Cloud, החשיפה תלויה בחומרה. עליך להשוות את התשתית שלך לגילוי הנאות של Intel. מה לעשות? הבעיה משפיעה עליכם רק אם אתם משתמשים במאגרי צמתים עם צמתים מסוג N2,‏ M2 או C2 וגם הצמתים האלה מריצים קודים לא מהימנים בתוך אשכולות GKE מרובי-דיירים. הפעלת הצמתים מחדש תחיל את התיקון. הדרך הכי פשוטה להפעיל מחדש את כל הצמתים במאגר הצמתים היא להשתמש בפעולת השדרוג כדי לכפות הפעלה מחדש בכל מאגר הצמתים שהושפע. הערה: אין צורך לשנות גרסאות במהלך שדרוג. אפשר להתחיל שדרוג לאותה גרסת צומת באמצעות הדגל `cluster-version`. אילו נקודות חולשה טופלו במסגרת התיקון הזה? התיקון טיפל בנקודות החולשה הבאות: ‫CVE-2019-11135: נקודת החולשה הזו נקראת גם TSX Async Abort (‏TAA). התקפת TAA מספקת דרך נוספת להוצאת נתונים באמצעות אותם מבני נתונים במיקרו-ארכיטקטורה שנוצלו על ידי דגימת נתונים של מיקרו-ארכיטקטורה (MDS). ‫CVE-2018-12207 זוהי נקודת חולשה של התקפת מניעת שירות (DoS) שמשפיעה על מארחים של מכונות וירטואליות, ומאפשרת לאורח זדוני להפיל מארח לא מוגן. ה-CVE הזה נקרא גם Machine Check Error on Page Size Change'‏ השינוי לא משפיע על GKE.	בינוני	CVE-2019-11135 CVE-2018-12207

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

תשתית המארח שמריצה את Kubernetes Engine מבודדת את עומסי העבודה של הלקוחות. אלא אם אתם מריצים קודים לא מהימנים בתוך אשכולות GKE מרובי-דיירים משלכם וגם משתמשים בצמתים מסוג N2, ‏ M2 או C2, לא נדרשת פעולה נוספת. במקרים של מכונות GKE בצמתי N1, לא נדרשת פעולה חדשה.

אם אתם מריצים את Google Distributed Cloud, החשיפה תלויה בחומרה. עליך להשוות את התשתית שלך לגילוי הנאות של Intel.

מה לעשות?

הבעיה משפיעה עליכם רק אם אתם משתמשים במאגרי צמתים עם צמתים מסוג N2,‏ M2 או C2 וגם הצמתים האלה מריצים קודים לא מהימנים בתוך אשכולות GKE מרובי-דיירים.

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

הערה: אין צורך לשנות גרסאות במהלך שדרוג. אפשר להתחיל שדרוג לאותה גרסת צומת באמצעות הדגל cluster-version.

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

התיקון טיפל בנקודות החולשה הבאות:

‫CVE-2019-11135: נקודת החולשה הזו נקראת גם TSX Async Abort (‏TAA). התקפת TAA מספקת דרך נוספת להוצאת נתונים באמצעות אותם מבני נתונים במיקרו-ארכיטקטורה שנוצלו על ידי דגימת נתונים של מיקרו-ארכיטקטורה (MDS).

‫CVE-2018-12207 זוהי נקודת חולשה של התקפת מניעת שירות (DoS) שמשפיעה על מארחים של מכונות וירטואליות, ומאפשרת לאורח זדוני להפיל מארח לא מוגן. ה-CVE הזה נקרא גם Machine Check Error on Page Size Change'‏ השינוי לא משפיע על GKE.

בינוני

CVE-2019-11135
CVE-2018-12207

‫22 באוקטובר 2019

תאריך פרסום: 22 באוקטובר 2019
תאריך עדכון: 22 באוקטובר 2019

תיאור	רמת סיכון	הערות
לאחרונה התגלתה נקודת חולשה בשפת התכנות Go, כפי שמפורט ב-CVE-2019-16276. נקודת החולשה הזו עלולה להשפיע על הגדרות Kubernetes שמשתמשות בשרת proxy לאימות. פרטים נוספים זמינים בגילוי הנאות בנושא Kubernetes. ‫Kubernetes Engine לא מאפשר הגדרה של שרת proxy לאימות, ולכן הוא לא מושפע מנקודת החולשה הזו.	ללא	CVE-2019-16276

תיאור

רמת סיכון

הערות

לאחרונה התגלתה נקודת חולשה בשפת התכנות Go, כפי שמפורט ב-CVE-2019-16276. נקודת החולשה הזו עלולה להשפיע על הגדרות Kubernetes שמשתמשות בשרת proxy לאימות. פרטים נוספים זמינים בגילוי הנאות בנושא Kubernetes.

‫Kubernetes Engine לא מאפשר הגדרה של שרת proxy לאימות, ולכן הוא לא מושפע מנקודת החולשה הזו.

ללא

CVE-2019-16276

‫16 באוקטובר 2019

תאריך פרסום: 16 באוקטובר 2019
תאריך עדכון: 24 באוקטובר 2019

תיאור	רמת סיכון	הערות
עדכון מ-24 באוקטובר 2019: גרסאות עם תיקוני אבטחה זמינות עכשיו בכל האזורים. לאחרונה התגלתה ב-Kubernetes נקודת חולשה שמתוארת ב-CVE-2019-11253. נקודת החולשה הזו מאפשרת לכל משתמש שמורשה לשלוח בקשות POST להריץ התקפה מסוג מניעת שירות (DoS) מרחוק על שרת Kubernetes API. הוועדה לאבטחת מוצרים (PSC) של Kubernetes פרסמה מידע נוסף על נקודת החולשה הזו, שאפשר למצוא כאן. אשכולות GKE שמשתמשים ב-Master Authorized Networks וב-Private clusters with no public endpoint לא חשופים לנקודת החולשה הזו. מה לעשות? מומלץ לשדרג את האשכול לגרסה עם תיקון ברגע שהיא תהיה זמינה. אנחנו צופים שהם יהיו זמינים בכל האזורים עם הגרסה של GKE שמתוכננת לשבוע שמתחיל ב-14 באוקטובר. גרסאות התיקון שיכללו את הפתרון מפורטות בהמשך: 1.12.10-gke.15 1.13.11-gke.5 1.14.7-gke.10 1.15.4-gke.15 אילו נקודות חולשה טופלו במסגרת התיקון הזה? התיקון טיפל בנקודות החולשה הבאות: ‫CVE-2019-11253 היא נקודת חולשה של התקפת מניעת שירות (DoS).	גבוהה	CVE-2019-11253

תיאור

רמת סיכון

הערות

עדכון מ-24 באוקטובר 2019: גרסאות עם תיקוני אבטחה זמינות עכשיו בכל האזורים.

לאחרונה התגלתה ב-Kubernetes נקודת חולשה שמתוארת ב-CVE-2019-11253. נקודת החולשה הזו מאפשרת לכל משתמש שמורשה לשלוח בקשות POST להריץ התקפה מסוג מניעת שירות (DoS) מרחוק על שרת Kubernetes API. הוועדה לאבטחת מוצרים (PSC) של Kubernetes פרסמה מידע נוסף על נקודת החולשה הזו, שאפשר למצוא כאן.

אשכולות GKE שמשתמשים ב-Master Authorized Networks וב-Private clusters with no public endpoint לא חשופים לנקודת החולשה הזו.

מה לעשות?

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

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

1.12.10-gke.15
1.13.11-gke.5
1.14.7-gke.10
1.15.4-gke.15

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

התיקון טיפל בנקודות החולשה הבאות:

‫CVE-2019-11253 היא נקודת חולשה של התקפת מניעת שירות (DoS).

גבוהה

CVE-2019-11253

‫16 בספטמבר 2019

תאריך פרסום: 16 בספטמבר 2019
תאריך עדכון: 16 באוקטובר 2019

תיאור	רמת סיכון	הערות
העדכנו את העלון הזה מאז הפרסום המקורי שלו. לאחרונה התגלו בשפת התכנות Go נקודות חולשה חדשות באבטחה CVE-2019-9512 ו-CVE-2019-9514, שהן נקודות חולשה של התקפת מניעת שירות (DoS). ב-GKE, הדבר עלול לאפשר למשתמש ליצור בקשות זדוניות שצורכות כמויות מוגזמות של CPU בשרת Kubernetes API, ועלול להפחית את הזמינות של מישור הבקרה של האשכול. פרטים נוספים זמינים בגילוי הנאות בנוגע לשפת התכנות Go. מה לעשות? מומלץ לשדרג את האשכול לגרסת התיקון האחרונה, שמכילה את הפתרון לנקודת החולשה הזו, ברגע שהיא תהיה זמינה. אנחנו צופים שהם יהיו זמינים בכל האזורים עם הגרסה הבאה של GKE, בהתאם ללוח הזמנים של הגרסאות. גרסאות התיקון שיכללו את הפתרון מפורטות בהמשך: עדכון מ-16 באוקטובר 2019: 1.12.10-gke.15 1.13.10-gke.0 1.14.6-gke.1 אילו נקודות חולשה טופלו במסגרת התיקון הזה? התיקון טיפל בנקודות החולשה הבאות: ‫CVE-2019-9512 ו-CVE-2019-9514 הן נקודות חולשה של התקפת מניעת שירות (DoS).	גבוהה	CVE-2019-9512 CVE-2019-9514

תיאור

רמת סיכון

הערות

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

לאחרונה התגלו בשפת התכנות Go נקודות חולשה חדשות באבטחה CVE-2019-9512 ו-CVE-2019-9514, שהן נקודות חולשה של התקפת מניעת שירות (DoS). ב-GKE, הדבר עלול לאפשר למשתמש ליצור בקשות זדוניות שצורכות כמויות מוגזמות של CPU בשרת Kubernetes API, ועלול להפחית את הזמינות של מישור הבקרה של האשכול. פרטים נוספים זמינים בגילוי הנאות בנוגע לשפת התכנות Go.

מה לעשות?

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

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

עדכון מ-16 באוקטובר 2019: 1.12.10-gke.15
1.13.10-gke.0
1.14.6-gke.1

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

התיקון טיפל בנקודות החולשה הבאות:

‫CVE-2019-9512 ו-CVE-2019-9514 הן נקודות חולשה של התקפת מניעת שירות (DoS).

גבוהה

CVE-2019-9512
CVE-2019-9514

5 בספטמבר 2019

תאריך פרסום: 5 בספטמבר 2019
תאריך עדכון: 5 בספטמבר 2019

העדכון לתיקון נקודת החולשה שמתוארת בגיליון המידע מ31 במאי 2019 עודכן.

22 באוגוסט 2019

תאריך פרסום: 22 באוגוסט 2019
תאריך עדכון: 22 באוגוסט 2019

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

‫8 באוגוסט 2019

תאריך פרסום: 8 באוגוסט 2019
תאריך עדכון: 8 באוגוסט 2019

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

‫5 באוגוסט 2019

תאריך פרסום: 5 באוגוסט 2019
תאריך עדכון: 9 באוגוסט 2019

תיאור	רמת סיכון	הערות
העדכנו את העלון הזה מאז הפרסום המקורי שלו. לאחרונה התגלתה ב-Kubernetes נקודת חולשה, CVE-2019-11247,‏ שמאפשרת לבצע פעולות על מופעים של משאבים מותאמים אישית ברמת האשכול כאילו הם אובייקטים במרחב שמות שקיימים בכל מרחבי השמות. המשמעות היא שמשתמשים וחשבונות שירות עם הרשאות RBAC ברמת מרחב השמות בלבד יכולים לבצע פעולות במשאבים מותאמים אישית בהיקף האשכול. כדי לנצל את נקודת החולשה הזו, התוקף צריך הרשאות גישה למשאב בכל מרחב שמות. מה לעשות? מומלץ לשדרג את האשכול לגרסת התיקון האחרונה, שמכילה את הפתרון לנקודת החולשה הזו, ברגע שהן תהיינה זמינות. אנחנו צופים שהם יהיו זמינים בכל האזורים עם הגרסה הבאה של GKE. גרסאות התיקון שבהן יוטמעו אמצעי ההגנה מפורטות בהמשך: 1.11.10-gke.6 1.12.9-gke.13 1.13.7-gke.19 ‫1.14.3-gke.10 (ערוץ מהיר) אילו נקודות חולשה טופלו במסגרת התיקון הזה? התיקון טיפל בנקודת החולשה הבאה: CVE-2019-11247.	בינוני	CVE-2019-11247

תיאור

רמת סיכון

הערות

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

לאחרונה התגלתה ב-Kubernetes נקודת חולשה, CVE-2019-11247,‏ שמאפשרת לבצע פעולות על מופעים של משאבים מותאמים אישית ברמת האשכול כאילו הם אובייקטים במרחב שמות שקיימים בכל מרחבי השמות. המשמעות היא שמשתמשים וחשבונות שירות עם הרשאות RBAC ברמת מרחב השמות בלבד יכולים לבצע פעולות במשאבים מותאמים אישית בהיקף האשכול. כדי לנצל את נקודת החולשה הזו, התוקף צריך הרשאות גישה למשאב בכל מרחב שמות.

מה לעשות?

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

1.11.10-gke.6
1.12.9-gke.13
1.13.7-gke.19
‫1.14.3-gke.10 (ערוץ מהיר)

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

התיקון טיפל בנקודת החולשה הבאה: CVE-2019-11247.

בינוני

CVE-2019-11247

‫3 ביולי 2019

תאריך פרסום: 3 ביולי 2019
תאריך עדכון: 3 ביולי 2019

תיאור רמת סיכון הערות

תיאור	רמת סיכון	הערות
גרסה עם תיקון של `kubectl` לטיפול ב-CVE-2019-11246 זמינה עכשיו עם `gcloud` 253.0.0. מידע נוסף זמין בעדכון האבטחה הדחוף מ-25 ביוני 2019. הערה: הטלאי לא זמין בגרסה `kubectl` 1.11.10.	גבוהה	CVE-2019-11246

גרסה עם תיקון של kubectl לטיפול ב-CVE-2019-11246 זמינה עכשיו עם gcloud 253.0.0. מידע נוסף זמין בעדכון האבטחה הדחוף מ-25 ביוני 2019.

הערה: הטלאי לא זמין בגרסה kubectl 1.11.10.

גבוהה

CVE-2019-11246

‫3 ביולי 2019

תאריך פרסום: 25 ביוני 2019
תאריך עדכון: 3 ביולי 2019

תיאור רמת סיכון הערות

תיאור	רמת סיכון	הערות
עדכון מ-3 ביולי 2019 בזמן העדכון האחרון שלנו, תיקוני האבטחה לגרסאות 1.11.9 ו-1.11.10 עדיין לא היו זמינים. השקנו עכשיו את גרסה 1.11.10-gke.5 כיעד לשדרוג של שתי גרסאות 1.11. נכון לעכשיו, תיקנו את הבעיה בשרתי הניהול של GKE, ותשתית Google שמריצה את Kubernetes Engine תוקנה ומוגנת מפני נקודת החולשה הזו. גרסאות 1.11 של שרתים ראשיים יוצאו משימוש בקרוב, והן מתוזמנות לשדרוג אוטומטי לגרסה 1.12 בשבוע שמתחיל ב-8 ביולי 2019. אתם יכולים לבחור באחת מהפעולות הבאות כדי להעביר את הצמתים לגרסה עם תיקון: צריך לבצע את שדרוג הצומת לגרסה ‎1.11.10-gke.5 עד 8 ביולי 2019. אחרי התאריך הזה, נתחיל להסיר את גרסאות 1.11 מהרשימה הזמינה של גרסאות שאפשר לשדרג אליהן. מפעילים שדרוגים אוטומטיים בצמתים 1.11 ומאפשרים לשדרג אותם כשהצמתים הראשיים משודרגים ל-1.12. משדרגים באופן ידני את כל המאסטרים והצמתים לגרסה קבועה 1.12. ההודעה המקורית מ-24 ביוני 2019 מופיעה בהמשך: עדכון מ-24 ביוני 2019 החל מ-22 ביוני 2019 בשעה 21:40 UTC, גרסאות Kubernetes מתוקנות זמינות: ‫Masters בין גרסאות Kubernetes‏ 1.11.0 ל-1.13.6 יעודכנו אוטומטית לגרסה עם תיקון. אם אתם לא מריצים גרסה שתואמת לתיקון הזה, אתם צריכים לשדרג לגרסת מאסטר תואמת (שמפורטת בהמשך) לפני שאתם משדרגים את הצמתים. בגלל חומרת נקודות החולשה האלה, מומלץ לשדרג באופן ידני את הצמתים ואת הצמתים הראשיים לאחת מהגרסאות האלה בהקדם האפשרי, גם אם הפעלתם שדרוג אוטומטי של הצמתים. הגרסאות המתוקנות: 1.11.8-gke.10 1.12.7-gke.24 1.12.8-gke.10 1.13.6-gke.13 ההודעה המקורית מ-18 ביוני 2019 מופיעה בהמשך: לאחרונה, Netflix חשפה שלוש נקודות חולשה ב-TCP בליבות של Linux: CVE-2019-11477 CVE-2019-11478 CVE-2019-11479 ה-CVE האלה נקראים ביחד NFLX-2019-001. ליבות Linux שלא עודכנו עלולות להיות חשופות להתקפת מניעת שירות (DoS) שמופעלת מרחוק. צמתים של Google Kubernetes Engine ששולחים או מקבלים תנועה ברשת לא מהימנה מושפעים מהבעיה הזו, ומומלץ לפעול לפי השלבים הבאים כדי להגן על עומסי העבודה. שרתי מאסטר של Kubernetes לא מושפעים מאסטרים של Kubernetes שמשתמשים ברשתות מורשות כדי להגביל את התנועה לרשתות מהימנות. התיקון יבוצע באופן אוטומטי בימים הקרובים בשרתים הראשיים של אשכולות GKE שמנוהלים על ידי Google. לא נדרשת פעולה מצד הלקוחות. צמתים של Kubernetes ההגדרה הזו לא משפיעה על צמתים שמגבילים את התנועה לרשתות מהימנות. זה יהיה אשכול עם המאפיינים הבאים: צמתים שמוגנים על ידי חומת אש מרשתות לא מהימנות או ללא כתובות IP ציבוריות (אשכולות פרטיים) קלאסטרים ללא שירותי LoadBalancer ציבוריים Google מכינה פתרון קבוע לנקודות החולשה האלה, שיהיה זמין כגרסה חדשה של הצומת. אנחנו נעדכן את העלון הזה ונשלח אימייל לכל לקוחות GKE כשהתיקון הקבוע יהיה זמין. עד שהתיקון הקבוע יהיה זמין, יצרנו Kubernetes DaemonSet שמטמיע אמצעי הגנה על ידי שינוי ההגדרה של המארח `iptables`. מה לעשות? מריצים את הפקודה הבאה כדי להחיל את Kubernetes DaemonSet על כל הצמתים באשכול. הפעולה הזו מוסיפה כלל `iptables` לכללי `iptables` הקיימים בצומת כדי לצמצם את הסיכון שנובע מנקודת החולשה. מריצים את הפקודה פעם אחת לכל אשכול לכל פרויקט. Google Cloud kubectl apply -f \ https://raw.githubusercontent.com/GoogleCloudPlatform\ /k8s-node-tools/master/drop-small-mss/drop-small-mss.yaml מכיוון ש-IPv6 לא נתמך ב-GKE, לא נדרש כלל ip6tables. אחרי שגרסת Node עם תיקון זמינה ושדרגתם את כל הצמתים שעשויים להיות מושפעים, תוכלו להסיר את DaemonSet באמצעות הפקודה הבאה. מריצים את הפקודה פעם אחת לכל אשכול לכל פרויקט Google Cloud . kubectl delete -f \ https://raw.githubusercontent.com/GoogleCloudPlatform\ /k8s-node-tools/master/drop-small-mss/drop-small-mss.yaml	גבוהה בינונית בינונית	CVE-2019-11477 CVE-2019-11478 CVE-2019-11479

עדכון מ-3 ביולי 2019

בזמן העדכון האחרון שלנו, תיקוני האבטחה לגרסאות 1.11.9 ו-1.11.10 עדיין לא היו זמינים. השקנו עכשיו את גרסה 1.11.10-gke.5 כיעד לשדרוג של שתי גרסאות 1.11.

נכון לעכשיו, תיקנו את הבעיה בשרתי הניהול של GKE, ותשתית Google שמריצה את Kubernetes Engine תוקנה ומוגנת מפני נקודת החולשה הזו.

גרסאות 1.11 של שרתים ראשיים יוצאו משימוש בקרוב, והן מתוזמנות לשדרוג אוטומטי לגרסה 1.12 בשבוע שמתחיל ב-8 ביולי 2019. אתם יכולים לבחור באחת מהפעולות הבאות כדי להעביר את הצמתים לגרסה עם תיקון:

צריך לבצע את שדרוג הצומת לגרסה ‎1.11.10-gke.5 עד 8 ביולי 2019. אחרי התאריך הזה, נתחיל להסיר את גרסאות 1.11 מהרשימה הזמינה של גרסאות שאפשר לשדרג אליהן.
מפעילים שדרוגים אוטומטיים בצמתים 1.11 ומאפשרים לשדרג אותם כשהצמתים הראשיים משודרגים ל-1.12.
משדרגים באופן ידני את כל המאסטרים והצמתים לגרסה קבועה 1.12.

ההודעה המקורית מ-24 ביוני 2019 מופיעה בהמשך:

עדכון מ-24 ביוני 2019

החל מ-22 ביוני 2019 בשעה 21:40 UTC, גרסאות Kubernetes מתוקנות זמינות: ‫Masters בין גרסאות Kubernetes‏ 1.11.0 ל-1.13.6 יעודכנו אוטומטית לגרסה עם תיקון. אם אתם לא מריצים גרסה שתואמת לתיקון הזה, אתם צריכים לשדרג לגרסת מאסטר תואמת (שמפורטת בהמשך) לפני שאתם משדרגים את הצמתים.

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

הגרסאות המתוקנות:

1.11.8-gke.10
1.12.7-gke.24
1.12.8-gke.10
1.13.6-gke.13

ההודעה המקורית מ-18 ביוני 2019 מופיעה בהמשך:

לאחרונה, Netflix חשפה שלוש נקודות חולשה ב-TCP בליבות של Linux:

ה-CVE האלה נקראים ביחד NFLX-2019-001.

ליבות Linux שלא עודכנו עלולות להיות חשופות להתקפת מניעת שירות (DoS) שמופעלת מרחוק. צמתים של Google Kubernetes Engine ששולחים או מקבלים תנועה ברשת לא מהימנה מושפעים מהבעיה הזו, ומומלץ לפעול לפי השלבים הבאים כדי להגן על עומסי העבודה.

שרתי מאסטר של Kubernetes

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

צמתים של Kubernetes

ההגדרה הזו לא משפיעה על צמתים שמגבילים את התנועה לרשתות מהימנות. זה יהיה אשכול עם המאפיינים הבאים:

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

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

עד שהתיקון הקבוע יהיה זמין, יצרנו Kubernetes DaemonSet שמטמיע אמצעי הגנה על ידי שינוי ההגדרה של המארח iptables.

מה לעשות?

מריצים את הפקודה הבאה כדי להחיל את Kubernetes DaemonSet על כל הצמתים באשכול. הפעולה הזו מוסיפה כלל iptables לכללי iptables הקיימים בצומת כדי לצמצם את הסיכון שנובע מנקודת החולשה. מריצים את הפקודה פעם אחת לכל אשכול לכל פרויקט. Google Cloud

kubectl apply -f \
https://raw.githubusercontent.com/GoogleCloudPlatform\
/k8s-node-tools/master/drop-small-mss/drop-small-mss.yaml

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

kubectl delete -f \
https://raw.githubusercontent.com/GoogleCloudPlatform\
/k8s-node-tools/master/drop-small-mss/drop-small-mss.yaml

גבוהה
בינונית
בינונית

CVE-2019-11477
CVE-2019-11478
CVE-2019-11479

‫25 ביוני 2019

תיאור רמת סיכון הערות

תיאור	רמת סיכון	הערות
עדכון מ-3 ביולי 2019: התיקון הזה זמין בגרסה `gcloud` 253.0.0 של `kubectl`, לגרסאות 1.12.9, 1.13.6, 1.14.2 ולגרסאות חדשות יותר. הערה: הפאץ' לא זמין בגרסה 1.11.10. לאחרונה התגלתה ב-Kubernetes נקודת חולשה, CVE-2019-11246, שמאפשרת לתוקף עם גישה לפעולה `kubectl cp` ולביצוע קוד בתוך קונטיינר לשנות קבצים במארח. הפרצה הזו מאפשרת לתוקף להחליף או ליצור קובץ במערכת הקבצים של המארח. פרטים נוספים זמינים בגילוי הנאות בנושא Kubernetes. כל הגרסאות של Google Kubernetes Engine‏ (GKE) `gcloud` מושפעות מנקודת החולשה הזו, ומומלץ לשדרג לגרסה האחרונה עם התיקון של `gcloud` כשהיא תהיה זמינה. גרסת תיקון שתצא בקרוב תכלול אמצעי להפחתת הסיכון לניצול נקודת החולשה הזו. מה לעשות? גרסה עם תיקון של `kubectl` תהיה זמינה בגרסה הקרובה של `gcloud`. אפשר גם לשדרג את `kubectl` ישירות בעצמכם. אפשר לעקוב אחרי הזמינות של הטלאי הזה ב`gcloud`הערות המוצר. אילו נקודות חולשה טופלו במסגרת התיקון הזה? נקודת החולשה CVE-2019-11246 מאפשרת לתוקף עם גישה לפעולת `kubectl cp` ולהפעלת קוד בתוך קונטיינר לשנות קבצים במארח. הניצול הזה מאפשר לתוקף להחליף או ליצור קובץ במערכת הקבצים של המארח	גבוהה	CVE-2019-11246

עדכון מ-3 ביולי 2019: התיקון הזה זמין בגרסה gcloud 253.0.0 של kubectl, לגרסאות 1.12.9, 1.13.6, 1.14.2 ולגרסאות חדשות יותר.

הערה: הפאץ' לא זמין בגרסה 1.11.10.

לאחרונה התגלתה ב-Kubernetes נקודת חולשה, CVE-2019-11246, שמאפשרת לתוקף עם גישה לפעולה kubectl cp ולביצוע קוד בתוך קונטיינר לשנות קבצים במארח. הפרצה הזו מאפשרת לתוקף להחליף או ליצור קובץ במערכת הקבצים של המארח. פרטים נוספים זמינים בגילוי הנאות בנושא Kubernetes.

כל הגרסאות של Google Kubernetes Engine‏ (GKE) gcloud מושפעות מנקודת החולשה הזו, ומומלץ לשדרג לגרסה האחרונה עם התיקון של gcloud כשהיא תהיה זמינה. גרסת תיקון שתצא בקרוב תכלול אמצעי להפחתת הסיכון לניצול נקודת החולשה הזו.

מה לעשות?

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

אפשר לעקוב אחרי הזמינות של הטלאי הזה בgcloudהערות המוצר.

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

נקודת החולשה CVE-2019-11246 מאפשרת לתוקף עם גישה לפעולת kubectl cp ולהפעלת קוד בתוך קונטיינר לשנות קבצים במארח. הניצול הזה מאפשר לתוקף להחליף או ליצור קובץ במערכת הקבצים של המארח

גבוהה

CVE-2019-11246

‫18 ביוני 2019

תיאור רמת סיכון הערות

תיאור	רמת סיכון	הערות
לאחרונה התגלתה ב-Docker נקודת חולשה, CVE-2018-15664, שמאפשרת לתוקף שיכול להריץ קוד בתוך קונטיינר לחטוף פעולת `docker cp` שהופעלה מבחוץ. הניצול הזה מאפשר לתוקף לשנות את המיקום שבו קובץ נכתב, למיקום שרירותי במערכת הקבצים של המארח. כל הצמתים של Google Kubernetes Engine‏ (GKE) שמריצים Docker מושפעים מנקודת החולשה הזו, ומומלץ לשדרג אותם לגרסה האחרונה עם התיקון ברגע שהיא תהיה זמינה. גרסת תיקון באגים שתצא בקרוב תכלול אמצעי להפחתת הסיכון לניצול נקודת החולשה הזו. כל המאסטרים של Google Kubernetes Engine‏ (GKE) בגרסה ישנה יותר מ-1.12.7 מריצים Docker ומושפעים מנקודת החולשה הזו. ב-GKE, למשתמשים אין גישה אל `docker cp` ב-master, ולכן הסיכון לנקודת החולשה הזו מוגבל ב-GKE masters. מה לעשות? הבעיה משפיעה רק על צמתים שמופעל בהם Docker, ורק כשמופעלת פקודה `docker cp` (או פקודה מקבילה של API) שאפשר לחטוף. התנהגות כזו צפויה להיות די חריגה בסביבת Kubernetes. אין השפעה על צמתים שמופעל בהם COS עם containerd. כדי לשדרג את הצמתים, קודם צריך לשדרג את הצומת הראשי לגרסה המתוקנת. כשהתיקון יהיה זמין, תוכלו להתחיל בשדרוג של ה-master או לחכות ש-Google תשדרג אותו באופן אוטומטי. התיקון יהיה זמין ב-Docker 18.09.7, והוא ייכלל בתיקון GKE שיפורסם בקרוב. התיקון הזה יהיה זמין רק ב-GKE מגרסה 1.13 ואילך. נשדרג את ה-cluster masters לגרסה המתוקנת באופן אוטומטי, בקצב השדרוג הרגיל. אפשר גם להתחיל שדרוג ראשי בעצמכם אחרי שהגרסה עם התיקון תהיה זמינה. כשהגרסאות שמכילות תיקון יהיו זמינות, נעדכן את העלון הזה. אפשר לעקוב אחרי הזמינות של הטלאים האלה בהערות המוצר. אילו נקודות חולשה טופלו במסגרת התיקון הזה? התיקון טיפל בנקודת החולשה הבאה: נקודת התורפה CVE-2018-15664 מאפשרת לתוקף שיכול להריץ קוד בתוך קונטיינר לחטוף פעולה של `docker cp` שהופעלה מבחוץ. הניצול הזה מאפשר לתוקף לשנות את המיקום שבו קובץ נכתב, למיקום שרירותי במערכת הקבצים של המארח.	גבוהה

לאחרונה התגלתה ב-Docker נקודת חולשה, CVE-2018-15664, שמאפשרת לתוקף שיכול להריץ קוד בתוך קונטיינר לחטוף פעולת docker cp שהופעלה מבחוץ. הניצול הזה מאפשר לתוקף לשנות את המיקום שבו קובץ נכתב, למיקום שרירותי במערכת הקבצים של המארח.

כל הצמתים של Google Kubernetes Engine‏ (GKE) שמריצים Docker מושפעים מנקודת החולשה הזו, ומומלץ לשדרג אותם לגרסה האחרונה עם התיקון ברגע שהיא תהיה זמינה. גרסת תיקון באגים שתצא בקרוב תכלול אמצעי להפחתת הסיכון לניצול נקודת החולשה הזו.

כל המאסטרים של Google Kubernetes Engine‏ (GKE) בגרסה ישנה יותר מ-1.12.7 מריצים Docker ומושפעים מנקודת החולשה הזו. ב-GKE, למשתמשים אין גישה אל docker cp ב-master, ולכן הסיכון לנקודת החולשה הזו מוגבל ב-GKE masters.

מה לעשות?

הבעיה משפיעה רק על צמתים שמופעל בהם Docker, ורק כשמופעלת פקודה docker cp (או פקודה מקבילה של API) שאפשר לחטוף. התנהגות כזו צפויה להיות די חריגה בסביבת Kubernetes. אין השפעה על צמתים שמופעל בהם COS עם containerd.

כדי לשדרג את הצמתים, קודם צריך לשדרג את הצומת הראשי לגרסה המתוקנת. כשהתיקון יהיה זמין, תוכלו להתחיל בשדרוג של ה-master או לחכות ש-Google תשדרג אותו באופן אוטומטי. התיקון יהיה זמין ב-Docker 18.09.7, והוא ייכלל בתיקון GKE שיפורסם בקרוב. התיקון הזה יהיה זמין רק ב-GKE מגרסה 1.13 ואילך.

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

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

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

התיקון טיפל בנקודת החולשה הבאה:

נקודת התורפה CVE-2018-15664 מאפשרת לתוקף שיכול להריץ קוד בתוך קונטיינר לחטוף פעולה של docker cp שהופעלה מבחוץ. הניצול הזה מאפשר לתוקף לשנות את המיקום שבו קובץ נכתב, למיקום שרירותי במערכת הקבצים של המארח.

גבוהה

31 במאי 2019

תיאור רמת סיכון הערות

תיאור	רמת סיכון	הערות
העדכנו את העלון הזה מאז הפרסום המקורי שלו. עדכון מ-2 באוגוסט 2019 בזמן פרסום העלון המקורי, הבעיה השפיעה רק על גרסאות 1.13.6-gke.0 עד 1.13.6-gke.5. בגלל רגרסיה, כל הגרסאות 1.13.6.x מושפעות עכשיו. אם אתם משתמשים בגרסה 1.13.6, עליכם לשדרג לגרסה 1.13.7 בהקדם האפשרי. בפרויקט Kubernetes פורסם CVE-2019-11245 ב-kubelet v1.13.6 וב-v1.14.2, שיכול לגרום לקונטיינרים לפעול כ-UID 0 (בדרך כלל ממופה למשתמש `root`), גם אם משתמש אחר מצוין בקובץ אימג' של קונטיינר. אם הקונטיינרים שלכם פועלים כמשתמשים לא מסוג root, ואתם מריצים את node בגירסה 1.13.6-gke.0 עד 1.13.6-gke.6, מומלץ להגדיר את `RunAsUser` בכל ה-Pods באשכול שהקונטיינרים שלהם לא אמורים לפעול כ-UID 0. אם מציינים ערך שאינו root `USER` (לדוגמה, על ידי הגדרת הערך של `USER` בקובץ Dockerfile), מתרחשת התנהגות לא צפויה. כשמאגר תגים מופעל בפעם הראשונה בצומת, הוא מכבד את ה-UID שצוין. עם זאת, בגלל הפגם הזה, בהפעלה השנייה (ובכל ההפעלות הבאות) הקונטיינר פועל כמזהה משתמש 0, ללא קשר למזהה המשתמש שצוין. בדרך כלל מדובר בהרשאת גישה לא רצויה ברמה גבוהה יותר, וזה עלול להוביל להתנהגות לא צפויה של האפליקציה. איך אפשר לדעת אם משתמשים בגרסה מושפעת? מריצים את הפקודה הבאה כדי להציג את כל הצמתים ואת הגרסה של kubelet: kubectl get nodes -o=jsonpath='{range .items[*]}'\ '{.status.nodeInfo.machineID}'\ '{"\t"}{.status.nodeInfo.kubeletVersion}{"\n"}{end}' אם הפלט כולל את הגרסאות של kubelet שמופיעות בהמשך, המשמעות היא שהצמתים מושפעים: v1.13.6 v1.14.2 איך אפשר לדעת אם ההגדרה הספציפית שלי מושפעת? אם הקונטיינרים שלכם פועלים כמשתמשים לא-root, ואתם מריצים את node בגרסה 1.13.6-gke.0 עד 1.13.6-gke.6, אתם מושפעים מהבעיה, למעט במקרים הבאים: לא מושפעים פודים שצוין בהם ערך תקין שאינו root עבור `runAsUser` PodSecurityContext, והם ממשיכים לפעול כצפוי. גם מדיניות PodSecurityPolicies שמחילה הגדרה של `runAsUser` לא מושפעת וממשיכה לפעול כצפוי. פודים שמציינים `mustRunAsNonRoot:true` לא יתחילו כ-UID 0, אלא יכשלו בהתחלה אם הם מושפעים מהבעיה הזו. מה לעשות? מגדירים את הקשר האבטחתי של RunAsUser בכל ה-Pods באשכול שלא אמורים לפעול כמזהה משתמש 0. אפשר להחיל את ההגדרה הזו באמצעות PodSecurityPolicy.	בינוני	CVE-2019-11245

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

עדכון מ-2 באוגוסט 2019

בזמן פרסום העלון המקורי, הבעיה השפיעה רק על גרסאות 1.13.6-gke.0 עד 1.13.6-gke.5. בגלל רגרסיה, כל הגרסאות 1.13.6.x מושפעות עכשיו. אם אתם משתמשים בגרסה 1.13.6, עליכם לשדרג לגרסה 1.13.7 בהקדם האפשרי.

בפרויקט Kubernetes פורסם CVE-2019-11245 ב-kubelet v1.13.6 וב-v1.14.2, שיכול לגרום לקונטיינרים לפעול כ-UID 0 (בדרך כלל ממופה למשתמש root), גם אם משתמש אחר מצוין בקובץ אימג' של קונטיינר. אם הקונטיינרים שלכם פועלים כמשתמשים לא מסוג root, ואתם מריצים את node בגירסה 1.13.6-gke.0 עד 1.13.6-gke.6, מומלץ להגדיר את RunAsUser בכל ה-Pods באשכול שהקונטיינרים שלהם לא אמורים לפעול כ-UID 0.

אם מציינים ערך שאינו root USER (לדוגמה, על ידי הגדרת הערך של USER בקובץ Dockerfile), מתרחשת התנהגות לא צפויה. כשמאגר תגים מופעל בפעם הראשונה בצומת, הוא מכבד את ה-UID שצוין. עם זאת, בגלל הפגם הזה, בהפעלה השנייה (ובכל ההפעלות הבאות) הקונטיינר פועל כמזהה משתמש 0, ללא קשר למזהה המשתמש שצוין. בדרך כלל מדובר בהרשאת גישה לא רצויה ברמה גבוהה יותר, וזה עלול להוביל להתנהגות לא צפויה של האפליקציה.

איך אפשר לדעת אם משתמשים בגרסה מושפעת?

מריצים את הפקודה הבאה כדי להציג את כל הצמתים ואת הגרסה של kubelet:

kubectl get nodes -o=jsonpath='{range .items[*]}'\
'{.status.nodeInfo.machineID}'\
'{"\t"}{.status.nodeInfo.kubeletVersion}{"\n"}{end}'

אם הפלט כולל את הגרסאות של kubelet שמופיעות בהמשך, המשמעות היא שהצמתים מושפעים:

v1.13.6
v1.14.2

איך אפשר לדעת אם ההגדרה הספציפית שלי מושפעת?

אם הקונטיינרים שלכם פועלים כמשתמשים לא-root, ואתם מריצים את node בגרסה 1.13.6-gke.0 עד 1.13.6-gke.6, אתם מושפעים מהבעיה, למעט במקרים הבאים:

לא מושפעים פודים שצוין בהם ערך תקין שאינו root עבור runAsUser PodSecurityContext, והם ממשיכים לפעול כצפוי.
גם מדיניות PodSecurityPolicies שמחילה הגדרה של runAsUser לא מושפעת וממשיכה לפעול כצפוי.
פודים שמציינים mustRunAsNonRoot:true לא יתחילו כ-UID 0, אלא יכשלו בהתחלה אם הם מושפעים מהבעיה הזו.

מה לעשות?

מגדירים את הקשר האבטחתי של RunAsUser בכל ה-Pods באשכול שלא אמורים לפעול כמזהה משתמש 0. אפשר להחיל את ההגדרה הזו באמצעות PodSecurityPolicy.

בינוני

CVE-2019-11245

‫14 במאי 2019

תיאור רמת סיכון הערות

תיאור	רמת סיכון	הערות
עדכון מ-11 ביוני 2019: התיקון זמין בגרסאות ‎1.11.10-gke.4,‏ ‎1.12.8-gke.6 ו-‎1.13.6-gke.5 שפורסמו בשבוע שמתחיל ב-28 במאי 2019, ובגרסאות חדשות יותר. ‫Intel דיווחה על עדכוני ה-CVE הבאים: CVE-2018-12126 CVE-2018-12127 CVE-2018-12130 CVE-2019-11091 נקודות החולשה האלה נקראות יחד Microarchitectural Data Sampling (דגימת נתונים של מיקרו-ארכיטקטורה, MDS). פרצות האבטחה האלה עלולות לאפשר חשיפה של נתונים דרך האינטראקציה של ביצוע ספקולטיבי עם מצב המיקרו-ארכיטקטורה. פרטים נוספים זמינים בדיווח של Intel. תשתית המארח שמריצה את Kubernetes Engine מבודדת בין עומסי העבודה של הלקוחות. אם אתם לא מריצים קוד לא מהימן בתוך אשכולות GKE מרובי-דיירים, אתם לא מושפעים. זו נקודת חולשה חמורה במיוחד ללקוחות שמריצים קודים לא מהימנים בשירותים מרובי-דיירים משלהם בתוך Kubernetes Engine. כדי לצמצם את הסיכון ב-Kubernetes Engine, משביתים את Hyper-Threading בצמתים. רק צמתים של Google Kubernetes Engine‏ (GKE) שמשתמשים בכמה מעבדים מושפעים מנקודות החולשה האלה. שימו לב: מכונות וירטואליות מסוג n1-standard-1 (ברירת המחדל של GKE),‏ g1-small ו-f1-micro חושפות רק ליבת CPU וירטואלית אחת לסביבת האורח, ולכן אין צורך להשבית את Hyper-Threading. אמצעי הגנה נוספים שיאפשרו את הפונקציונליות של ניקוי הנתונים ייכללו בגרסת תיקון שתצא בקרוב. בשבועות הקרובים נשדרג את המאסטרים והצמתים באמצעות שדרוג אוטומטי לגרסה המתוקנת, בקצב השדרוג הרגיל. הטלאי לבדו לא מספיק כדי לצמצם את החשיפה לנקודת החולשה הזו. בהמשך מפורטות פעולות מומלצות. אם אתם מריצים GKE on prem, יכול להיות שהבעיה תשפיע עליכם בהתאם לחומרה שבה אתם משתמשים. מידע נוסף זמין בדיווח של Intel. מה לעשות? אם אתם לא מריצים קוד לא מהימן בתוך אשכולות GKE מרובי-דיירים משלכם, לא תהיה לכך השפעה עליכם. בצמתים ב-Kubernetes Engine, יוצרים מאגרי צמתים חדשים עם השבתה של Hyper-Threading ומתזמנים מחדש את עומסי העבודה בצמתים החדשים. שימו לב: מכונות וירטואליות מסוג n1-standard-1, ‏ g1-small ו-f1-micro חושפות רק ליבת CPU וירטואלית אחת לסביבת האורח, ולכן אין צורך להשבית את ה-Hyper-Threading. אזהרה: השבתה של Hyper-Threading עלולה להשפיע באופן משמעותי על הביצועים של האשכולות והאפליקציה. חשוב לוודא שההגדרה הזו מקובלת לפני שפורסים אותה באשכולות הייצור. אפשר להשבית את Hyper-threading ברמת מאגר הצמתים של GKE באמצעות פריסה של DaemonSet. עם זאת, פריסת ה-DaemonSet הזה תגרום להפעלה מחדש של כל הצמתים במאגר הצמתים בו-זמנית. לכן מומלץ ליצור מאגר צמתים חדש באשכול, לפרוס את DaemonSet כדי להשבית את Hyper-Threading במאגר הצמתים הזה, ואז להעביר את עומסי העבודה למאגר הצמתים החדש. כדי ליצור מאגר צמתים חדש עם Hyper-Threading מושבת: יוצרים מאגר צמתים חדש באשכול עם תווית הצומת `cloud.google.com/gke-smt-disabled=true`: gcloud container node-pools create smt-disabled --cluster=[CLUSTER_NAME] \ --node-labels=cloud.google.com/gke-smt-disabled=true פורסים את DaemonSet למאגר הצמתים החדש הזה. ה-DaemonSet יפעל רק בצמתים עם התווית `cloud.google.com/gke-smt-disabled=true`. היא תשבית את Hyper-Threading ואז תפעיל מחדש את הצומת. kubectl create -f \ https://raw.githubusercontent.com/GoogleCloudPlatform/\ k8s-node-tools/master/disable-smt/gke/disable-smt.yaml מוודאים שהפודים של DaemonSet נמצאים במצב פעיל. kubectl get pods --selector=name=disable-smt -n kube-system אמורה להתקבל תגובה שדומה לזו: NAME READY STATUS RESTARTS AGE disable-smt-2xnnc 1/1 Running 0 6m בודקים אם ההודעה 'SMT הושבת' מופיעה ביומנים של הפודים. kubectl logs disable-smt-2xnnc disable-smt -n kube-system הערה: אי אפשר לשנות את אפשרויות האתחול אם התכונה Secure Boot מופעלת בצומת. אם Secure Boot מופעל, צריך להשבית אותו לפני שיוצרים את DaemonSet. צריך להשאיר את DaemonSet פועל ב-nodepools כדי שהשינויים יחולו באופן אוטומטי על צמתים חדשים שנוצרו במאגר. יצירת צמתים יכולה להיות מופעלת על ידי תיקון אוטומטי של צמתים, שדרוג ידני או אוטומטי והתאמה אוטומטית לעומס. כדי להפעיל מחדש את Hyper-Threading, צריך ליצור מחדש את מאגר הצמתים בלי לפרוס את DaemonSet שסופק, ולהעביר את עומסי העבודה למאגר הצמתים החדש. מומלץ גם לשדרג את הצמתים באופן ידני ברגע שהתיקון יהיה זמין. כדי לשדרג, קודם צריך לשדרג את המאסטר לגרסה החדשה ביותר. השדרוג של GKE masters יתבצע אוטומטית במרווחי הזמן הקבועים לשדרוג. כשהגרסאות שמכילות תיקון יהיו זמינות, נעדכן את העלון הזה. אילו נקודות חולשה טופלו במסגרת התיקון הזה? התיקון טיפל בנקודות החולשה הבאות: ‫CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, CVE-2019-11091: These vulnerabilities exploit speculative execution. אנחנו מתייחסים ל-CVE האלה יחד כאל דגימת נתונים של מיקרו-ארכיטקטורה. פרצות האבטחה האלה עלולות לאפשר חשיפה של נתונים דרך האינטראקציה של ביצוע ספקולטיבי עם מצב המיקרו-ארכיטקטורה.	בינוני	CVE-2018-12126 CVE-2018-12127 CVE-2018-12130 CVE-2018-11091

עדכון מ-11 ביוני 2019: התיקון זמין בגרסאות ‎1.11.10-gke.4,‏ ‎1.12.8-gke.6 ו-‎1.13.6-gke.5 שפורסמו בשבוע שמתחיל ב-28 במאי 2019, ובגרסאות חדשות יותר.

‫Intel דיווחה על עדכוני ה-CVE הבאים:

נקודות החולשה האלה נקראות יחד Microarchitectural Data Sampling (דגימת נתונים של מיקרו-ארכיטקטורה, MDS). פרצות האבטחה האלה עלולות לאפשר חשיפה של נתונים דרך האינטראקציה של ביצוע ספקולטיבי עם מצב המיקרו-ארכיטקטורה. פרטים נוספים זמינים בדיווח של Intel.

תשתית המארח שמריצה את Kubernetes Engine מבודדת בין עומסי העבודה של הלקוחות. אם אתם לא מריצים קוד לא מהימן בתוך אשכולות GKE מרובי-דיירים, אתם לא מושפעים.

זו נקודת חולשה חמורה במיוחד ללקוחות שמריצים קודים לא מהימנים בשירותים מרובי-דיירים משלהם בתוך Kubernetes Engine. כדי לצמצם את הסיכון ב-Kubernetes Engine, משביתים את Hyper-Threading בצמתים. רק צמתים של Google Kubernetes Engine‏ (GKE) שמשתמשים בכמה מעבדים מושפעים מנקודות החולשה האלה. שימו לב: מכונות וירטואליות מסוג n1-standard-1 (ברירת המחדל של GKE),‏ g1-small ו-f1-micro חושפות רק ליבת CPU וירטואלית אחת לסביבת האורח, ולכן אין צורך להשבית את Hyper-Threading.

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

אם אתם מריצים GKE on prem, יכול להיות שהבעיה תשפיע עליכם בהתאם לחומרה שבה אתם משתמשים. מידע נוסף זמין בדיווח של Intel.

מה לעשות?

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

בצמתים ב-Kubernetes Engine, יוצרים מאגרי צמתים חדשים עם השבתה של Hyper-Threading ומתזמנים מחדש את עומסי העבודה בצמתים החדשים.

שימו לב: מכונות וירטואליות מסוג n1-standard-1, ‏ g1-small ו-f1-micro חושפות רק ליבת CPU וירטואלית אחת לסביבת האורח, ולכן אין צורך להשבית את ה-Hyper-Threading.

אזהרה:

השבתה של Hyper-Threading עלולה להשפיע באופן משמעותי על הביצועים של האשכולות והאפליקציה. חשוב לוודא שההגדרה הזו מקובלת לפני שפורסים אותה באשכולות הייצור.
אפשר להשבית את Hyper-threading ברמת מאגר הצמתים של GKE באמצעות פריסה של DaemonSet. עם זאת, פריסת ה-DaemonSet הזה תגרום להפעלה מחדש של כל הצמתים במאגר הצמתים בו-זמנית. לכן מומלץ ליצור מאגר צמתים חדש באשכול, לפרוס את DaemonSet כדי להשבית את Hyper-Threading במאגר הצמתים הזה, ואז להעביר את עומסי העבודה למאגר הצמתים החדש.

כדי ליצור מאגר צמתים חדש עם Hyper-Threading מושבת:

יוצרים מאגר צמתים חדש באשכול עם תווית הצומת cloud.google.com/gke-smt-disabled=true:

gcloud container node-pools create smt-disabled --cluster=[CLUSTER_NAME] \
    --node-labels=cloud.google.com/gke-smt-disabled=true

פורסים את DaemonSet למאגר הצמתים החדש הזה. ה-DaemonSet יפעל רק בצמתים עם התווית cloud.google.com/gke-smt-disabled=true. היא תשבית את Hyper-Threading ואז תפעיל מחדש את הצומת.
```
kubectl create -f \
https://raw.githubusercontent.com/GoogleCloudPlatform/\
k8s-node-tools/master/disable-smt/gke/disable-smt.yaml
```

מוודאים שהפודים של DaemonSet נמצאים במצב פעיל.

kubectl get pods --selector=name=disable-smt -n kube-system

אמורה להתקבל תגובה שדומה לזו:

NAME                READY     STATUS    RESTARTS   AGE

disable-smt-2xnnc   1/1       Running   0          6m

בודקים אם ההודעה 'SMT הושבת' מופיעה ביומנים של הפודים.
```
kubectl logs disable-smt-2xnnc disable-smt -n kube-system
```

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

כדי להפעיל מחדש את Hyper-Threading, צריך ליצור מחדש את מאגר הצמתים בלי לפרוס את DaemonSet שסופק, ולהעביר את עומסי העבודה למאגר הצמתים החדש.

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

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

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

התיקון טיפל בנקודות החולשה הבאות:

‫CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, CVE-2019-11091: These vulnerabilities exploit speculative execution. אנחנו מתייחסים ל-CVE האלה יחד כאל דגימת נתונים של מיקרו-ארכיטקטורה. פרצות האבטחה האלה עלולות לאפשר חשיפה של נתונים דרך האינטראקציה של ביצוע ספקולטיבי עם מצב המיקרו-ארכיטקטורה.

בינוני

5 באפריל 2019

תיאור	רמת סיכון	הערות
לאחרונה התגלו נקודות החולשה באבטחה CVE-2019-9900 ו-CVE-2019-9901. זוהו ב-Envoy. ‫Istio מטמיע את Envoy, והפגיעויות האלה מאפשרות לעקוף את מדיניות Istio במקרים מסוימים. אם הפעלתם את Istio ב-Google Kubernetes Engine‏ (GKE), יכול להיות שנקודות החולשה האלה ישפיעו עליכם. מומלץ לשדרג את האשכולות המושפעים לגרסה האחרונה עם התיקון בהקדם האפשרי, ולשדרג את Istio sidecars (הוראות בהמשך). מה לעשות? בגלל חומרת הפגיעות האלה, בין אם הפעלתם שדרוגים אוטומטיים של צמתים ובין אם לא, מומלץ: משדרגים ידנית את האשכול ברגע שהתיקון הופך לזמין. כדי לשדרג את ה-sidecars, פועלים לפי המסמכים בנושא שדרוג sidecar. הגרסאות המתוקנות יהיו זמינות לכל הפרויקטים של GKE לפני השעה 19:00 PDT היום. התיקון הזה יהיה זמין בגרסאות GKE שמופיעות בהמשך. אשכולות חדשים ישתמשו בגרסה המתוקנת כברירת מחדל כשהיא תפורסם בדף של עלוני האבטחה של GKE, הצפוי ב-15 באפריל 2019. אם תיצרו אשכול חדש לפני כן, תצטרכו לציין את הגרסה המתוקנת כדי שהאשכול ישתמש בה. לקוחות GKE שהפעילו שדרוגים אוטומטיים של צמתים ולא ישדרגו באופן ידני, יקבלו שדרוג אוטומטי של הצמתים לגרסאות עם תיקונים בשבוע הבא. גרסאות עם תיקון: 1.10.12-gke.14 1.11.6-gke.16 1.11.7-gke.18 1.11.8-gke.6 1.12.6-gke.10 1.13.4-gke.10 אילו נקודות חולשה טופלו במסגרת התיקון הזה? התיקון טיפל בנקודות החולשה הבאות: ‫CVE-2019-9900 ו- CVE-2019-9901. מידע נוסף על התכונות האלה זמין בבלוג של Istio.	גבוהה	CVE-2019-9900 CVE-2019-9901.

תיאור

רמת סיכון

הערות

לאחרונה התגלו נקודות החולשה באבטחה CVE-2019-9900 ו-CVE-2019-9901. זוהו ב-Envoy.

‫Istio מטמיע את Envoy, והפגיעויות האלה מאפשרות לעקוף את מדיניות Istio במקרים מסוימים.

אם הפעלתם את Istio ב-Google Kubernetes Engine‏ (GKE), יכול להיות שנקודות החולשה האלה ישפיעו עליכם. מומלץ לשדרג את האשכולות המושפעים לגרסה האחרונה עם התיקון בהקדם האפשרי, ולשדרג את Istio sidecars (הוראות בהמשך).

מה לעשות?

בגלל חומרת הפגיעות האלה, בין אם הפעלתם שדרוגים אוטומטיים של צמתים ובין אם לא, מומלץ:

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

הגרסאות המתוקנות יהיו זמינות לכל הפרויקטים של GKE לפני השעה 19:00 PDT היום.

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

גרסאות עם תיקון:

1.10.12-gke.14
1.11.6-gke.16
1.11.7-gke.18
1.11.8-gke.6
1.12.6-gke.10
1.13.4-gke.10

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

התיקון טיפל בנקודות החולשה הבאות:

‫CVE-2019-9900 ו- CVE-2019-9901. מידע נוסף על התכונות האלה זמין בבלוג של Istio.

גבוהה

‫1 במרץ 2019

תיאור	רמת סיכון	הערות
עדכון מ-22 במרץ 2019: התיקון הזה זמין ב-Kubernetes בגרסאות ‎1.11.8-gke.4,‏ ‎1.13.4-gke.1 ובגרסאות חדשות יותר. התיקון עדיין לא זמין בגרסה 1.12. אפשר לעקוב אחרי הזמינות של הטלאים האלה בהערות המוצר. לאחרונה התגלתה ב-Kubernetes נקודת חולשה חדשה של מניעת שירות (DoS) CVE-2019-1002100, שמאפשרת למשתמש מורשה לשלוח בקשות תיקון ליצור בקשת json-patch זדונית שצורכת כמויות מוגזמות של CPU וזיכרון בשרת Kubernetes API, ועלולה להפחית את הזמינות של רמת הבקרה של האשכול. פרטים נוספים זמינים בגילוי הנאות בנושא Kubernetes. כל המאסטרים של Google Kubernetes Engine‏ (GKE) מושפעים מנקודות החולשה האלה. גרסת תיקון שתצא בקרוב תכלול פתרון לנקודת החולשה הזו. נשדרג את ה-master של האשכול לגרסה המתוקנת באופן אוטומטי בשבועות הקרובים, במרווחי הזמן הקבועים של השדרוגים. מה לעשות? לא נדרשת שום פעולה. השדרוג של GKE masters יתבצע אוטומטית במרווחי הזמן הרגילים לשדרוג. אם רוצים לשדרג את המאסטר מוקדם יותר, אפשר להתחיל שדרוג מאסטר באופן ידני. אנחנו נעדכן את העלון הזה עם הגרסאות שמכילות תיקון. הערה התיקון יהיה זמין רק בגרסאות 1.11 ואילך, ולא בגרסה 1.10. אילו נקודות חולשה טופלו במסגרת התיקון הזה? התיקון טיפל בנקודת החולשה הבאה: נקודת החולשה CVE-2019-1002100 מאפשרת למשתמש ליצור תיקון מסוג json-patch שצורכת כמויות מוגזמות של CPU בשרת Kubernetes API, ועלולה לצמצם את הזמינות של מישור הבקרה של האשכול.	בינוני	CVE-2019-1002100

תיאור

רמת סיכון

הערות

עדכון מ-22 במרץ 2019: התיקון הזה זמין ב-Kubernetes בגרסאות ‎1.11.8-gke.4,‏ ‎1.13.4-gke.1 ובגרסאות חדשות יותר. התיקון עדיין לא זמין בגרסה 1.12. אפשר לעקוב אחרי הזמינות של הטלאים האלה בהערות המוצר.

לאחרונה התגלתה ב-Kubernetes נקודת חולשה חדשה של מניעת שירות (DoS) CVE-2019-1002100, שמאפשרת למשתמש מורשה לשלוח בקשות תיקון ליצור בקשת json-patch זדונית שצורכת כמויות מוגזמות של CPU וזיכרון בשרת Kubernetes API, ועלולה להפחית את הזמינות של רמת הבקרה של האשכול. פרטים נוספים זמינים בגילוי הנאות בנושא Kubernetes. כל המאסטרים של Google Kubernetes Engine‏ (GKE) מושפעים מנקודות החולשה האלה. גרסת תיקון שתצא בקרוב תכלול פתרון לנקודת החולשה הזו. נשדרג את ה-master של האשכול לגרסה המתוקנת באופן אוטומטי בשבועות הקרובים, במרווחי הזמן הקבועים של השדרוגים.

מה לעשות?

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

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

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

התיקון טיפל בנקודת החולשה הבאה:

נקודת החולשה CVE-2019-1002100 מאפשרת למשתמש ליצור תיקון מסוג json-patch שצורכת כמויות מוגזמות של CPU בשרת Kubernetes API, ועלולה לצמצם את הזמינות של מישור הבקרה של האשכול.

בינוני

CVE-2019-1002100

‫11 בפברואר 2019 (runc)

תיאור	רמת סיכון	הערות
התגלתה נקודת חולשה חדשה באבטחה, CVE-2019-5736, ב-runc, שמאפשרת לנתיבי בריחה מהקונטיינר לקבל הרשאות root בצומת המארח. צמתי Ubuntu של Google Kubernetes Engine‏ (GKE) מושפעים מנקודות החולשה האלה, ומומלץ לשדרג לגרסה האחרונה עם התיקון בהקדם האפשרי, כמו שמפורט בהמשך. מה לעשות? כדי לשדרג את הצמתים, קודם צריך לשדרג את הצומת הראשי לגרסה החדשה ביותר. התיקון הזה זמין ב-Kubernetes 1.10.12-gke.7, 1.11.6-gke.11, 1.11.7-gke.4, 1.12.5-gke.5 ובגרסאות חדשות יותר. אפשר לעקוב אחרי הזמינות של הטלאים האלה בהערות המוצר. חשוב לדעת שההשפעה היא רק על צומתי Ubuntu ב-GKE. אין השפעה על צמתים שמריצים COS. שימו לב שבגרסה החדשה של runc יש שימוש מוגבר בזיכרון, ויכול להיות שתצטרכו לעדכן את הזיכרון שהוקצה למאגרי נתונים אם הגדרתם מגבלות זיכרון נמוכות (פחות מ-16MB). אילו נקודות חולשה טופלו במסגרת התיקון הזה? התיקון טיפל בנקודת החולשה הבאה: ‫CVE-2019-5736 מתאר נקודת חולשה ב-runc שמאפשרת לקונטיינר זדוני (עם אינטראקציה מינימלית של המשתמש בצורה של הרצה) לדרוס את קובץ ה-runc הבינארי של המארח, וכך לקבל הרשאות root להרצת קוד בצומת המארח. אין השפעה על קונטיינרים שלא פועלים כבסיס. נקודת החולשה הזו היא ברמת סיכון גבוהה.	גבוהה	CVE-2019-5736

תיאור

רמת סיכון

הערות

התגלתה נקודת חולשה חדשה באבטחה, CVE-2019-5736, ב-runc, שמאפשרת לנתיבי בריחה מהקונטיינר לקבל הרשאות root בצומת המארח.

צמתי Ubuntu של Google Kubernetes Engine‏ (GKE) מושפעים מנקודות החולשה האלה, ומומלץ לשדרג לגרסה האחרונה עם התיקון בהקדם האפשרי, כמו שמפורט בהמשך.

מה לעשות?

כדי לשדרג את הצמתים, קודם צריך לשדרג את הצומת הראשי לגרסה החדשה ביותר. התיקון הזה זמין ב-Kubernetes 1.10.12-gke.7, 1.11.6-gke.11, 1.11.7-gke.4, 1.12.5-gke.5 ובגרסאות חדשות יותר. אפשר לעקוב אחרי הזמינות של הטלאים האלה בהערות המוצר.

חשוב לדעת שההשפעה היא רק על צומתי Ubuntu ב-GKE. אין השפעה על צמתים שמריצים COS.

שימו לב שבגרסה החדשה של runc יש שימוש מוגבר בזיכרון, ויכול להיות שתצטרכו לעדכן את הזיכרון שהוקצה למאגרי נתונים אם הגדרתם מגבלות זיכרון נמוכות (פחות מ-16MB).

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

התיקון טיפל בנקודת החולשה הבאה:

‫CVE-2019-5736 מתאר נקודת חולשה ב-runc שמאפשרת לקונטיינר זדוני (עם אינטראקציה מינימלית של המשתמש בצורה של הרצה) לדרוס את קובץ ה-runc הבינארי של המארח, וכך לקבל הרשאות root להרצת קוד בצומת המארח. אין השפעה על קונטיינרים שלא פועלים כבסיס. נקודת החולשה הזו היא ברמת סיכון גבוהה.

גבוהה

CVE-2019-5736

‫11 בפברואר 2019 (Go)

תיאור	רמת סיכון	הערות
עדכון מ-25 בפברואר 2019: התיקון לא זמין בגרסה 1.11.7-gke.4 כפי שצוין קודם. אם אתם משתמשים בגרסה 1.11.7, אתם יכולים: לשנמך לגרסה 1.11.6, לשדרג לגרסה 1.12 או לחכות עד לתיקון הבא של גרסה 1.11.7 שיהיה זמין בשבוע של 2019-03-04. לאחרונה התגלתה בשפת התכנות Go נקודת חולשה חדשה באבטחה CVE-2019-6486, שהיא נקודת חולשה של התקפת מניעת שירות (DoS) בהטמעות של crypto/elliptic של עקומות אליפטיות P-521 ו-P-384. ב-Google Kubernetes Engine‏ (GKE), נקודת החולשה הזו עלולה לאפשר למשתמש ליצור בקשות זדוניות שצורכות כמויות מוגזמות של CPU בשרת ה-API של Kubernetes, וכך להפחית את הזמינות של רמת הבקרה של האשכול. פרטים נוספים זמינים בגילוי הנאות בנוגע לשפת התכנות Go. כל המאסטרים של Google Kubernetes Engine‏ (GKE) מושפעים מנקודות החולשה האלה. גרסת התיקון האחרונה כוללת פתרון לנקודת החולשה הזו. בשבועות הקרובים נשדרג את המאסטרים של האשכולות לגרסה עם התיקון באופן אוטומטי, בקצב השדרוג הרגיל. מה לעשות? לא נדרשת שום פעולה. השדרוג של GKE masters יתבצע אוטומטית במרווחי הזמן הקבועים לשדרוגים. אם רוצים לשדרג את המאסטר מוקדם יותר, אפשר להתחיל שדרוג מאסטר באופן ידני. התיקון הזה זמין בגרסאות GKE 1.10.12-gke.7,‏ 1.11.6-gke.11,‏ 1.11.7-gke.4,‏ 1.12.5-gke.5 ובגרסאות חדשות יותר. אילו נקודות חולשה טופלו במסגרת התיקון הזה? התיקון טיפל בנקודת החולשה הבאה: ‫CVE-2019-6486 היא נקודת חולשה בהטמעות של crypto/elliptic של העקומים האליפטיים P-521 ו-P-384. כך משתמש יכול ליצור קלט שצורך כמות מוגזמת של מעבד.	גבוהה	CVE-2019-6486

תיאור

רמת סיכון

הערות

עדכון מ-25 בפברואר 2019: התיקון לא זמין בגרסה 1.11.7-gke.4 כפי שצוין קודם. אם אתם משתמשים בגרסה 1.11.7, אתם יכולים: לשנמך לגרסה 1.11.6, לשדרג לגרסה 1.12 או לחכות עד לתיקון הבא של גרסה 1.11.7 שיהיה זמין בשבוע של 2019-03-04.

לאחרונה התגלתה בשפת התכנות Go נקודת חולשה חדשה באבטחה CVE-2019-6486, שהיא נקודת חולשה של התקפת מניעת שירות (DoS) בהטמעות של crypto/elliptic של עקומות אליפטיות P-521 ו-P-384. ב-Google Kubernetes Engine‏ (GKE), נקודת החולשה הזו עלולה לאפשר למשתמש ליצור בקשות זדוניות שצורכות כמויות מוגזמות של CPU בשרת ה-API של Kubernetes, וכך להפחית את הזמינות של רמת הבקרה של האשכול. פרטים נוספים זמינים בגילוי הנאות בנוגע לשפת התכנות Go.

כל המאסטרים של Google Kubernetes Engine‏ (GKE) מושפעים מנקודות החולשה האלה. גרסת התיקון האחרונה כוללת פתרון לנקודת החולשה הזו. בשבועות הקרובים נשדרג את המאסטרים של האשכולות לגרסה עם התיקון באופן אוטומטי, בקצב השדרוג הרגיל.

מה לעשות?

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

התיקון הזה זמין בגרסאות GKE 1.10.12-gke.7,‏ 1.11.6-gke.11,‏ 1.11.7-gke.4,‏ 1.12.5-gke.5 ובגרסאות חדשות יותר.

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

התיקון טיפל בנקודת החולשה הבאה:

‫CVE-2019-6486 היא נקודת חולשה בהטמעות של crypto/elliptic של העקומים האליפטיים P-521 ו-P-384. כך משתמש יכול ליצור קלט שצורך כמות מוגזמת של מעבד.

גבוהה

CVE-2019-6486

‫3 בדצמבר 2018

תיאור	רמת סיכון	הערות
לאחרונה התגלתה ב-Kubernetes נקודת חולשה חדשה באבטחה, CVE-2018-1002105, שמאפשרת למשתמש עם הרשאות נמוכות יחסית לעקוף את ההרשאה לממשקי ה-API של kubelet, וכך לבצע פעולות שרירותיות בכל Pod בכל צומת באשכול. פרטים נוספים זמינים בגילוי הנאות בנושא Kubernetes. כל המאסטרים של Google Kubernetes Engine‏ (GKE) הושפעו מנקודות החולשה האלה, וכבר שדרגנו את האשכולות לגרסאות האחרונות עם התיקון. לא צריך לעשות שום דבר. מה לעשות? לא נדרשת שום פעולה. השדרוג של GKE masters כבר בוצע. התיקון הזה זמין ב-GKE 1.9.7-gke.11,‏ 1.10.6-gke.11,‏ 1.10.7-gke.11,‏ 1.10.9-gke.5 ובגרסאות חדשות יותר. אילו נקודות חולשה טופלו במסגרת התיקון הזה? התיקון טיפל בנקודת החולשה הבאה: נקודת החולשה CVE-2018-1002105 מאפשרת למשתמש עם הרשאות נמוכות יחסית לעקוף את ההרשאה ל-APIs של kubelet. כך משתמש שמורשה לשלוח בקשות שניתן לשדרג, יכול לשדרג את הבקשות ולבצע קריאות שרירותיות ל-API של kubelet. נקודת החולשה הזו היא ברמת סיכון קריטית ב-Kubernetes. בהתחשב בפרטים מסוימים בהטמעה של GKE שמנעו את נתיב ההרשאה ללא אימות, נקודת החולשה הזו היא ברמת סיכון גבוהה.	גבוהה	CVE-2018-1002105

תיאור

רמת סיכון

הערות

לאחרונה התגלתה ב-Kubernetes נקודת חולשה חדשה באבטחה, CVE-2018-1002105, שמאפשרת למשתמש עם הרשאות נמוכות יחסית לעקוף את ההרשאה לממשקי ה-API של kubelet, וכך לבצע פעולות שרירותיות בכל Pod בכל צומת באשכול. פרטים נוספים זמינים בגילוי הנאות בנושא Kubernetes. כל המאסטרים של Google Kubernetes Engine‏ (GKE) הושפעו מנקודות החולשה האלה, וכבר שדרגנו את האשכולות לגרסאות האחרונות עם התיקון. לא צריך לעשות שום דבר.

מה לעשות?

לא נדרשת שום פעולה. השדרוג של GKE masters כבר בוצע.

התיקון הזה זמין ב-GKE 1.9.7-gke.11,‏ 1.10.6-gke.11,‏ 1.10.7-gke.11,‏ 1.10.9-gke.5 ובגרסאות חדשות יותר.

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

התיקון טיפל בנקודת החולשה הבאה:

נקודת החולשה CVE-2018-1002105 מאפשרת למשתמש עם הרשאות נמוכות יחסית לעקוף את ההרשאה ל-APIs של kubelet. כך משתמש שמורשה לשלוח בקשות שניתן לשדרג, יכול לשדרג את הבקשות ולבצע קריאות שרירותיות ל-API של kubelet. נקודת החולשה הזו היא ברמת סיכון קריטית ב-Kubernetes. בהתחשב בפרטים מסוימים בהטמעה של GKE שמנעו את נתיב ההרשאה ללא אימות, נקודת החולשה הזו היא ברמת סיכון גבוהה.

גבוהה

CVE-2018-1002105

‫13 בנובמבר 2018

תיאור
עדכון מ-16 בנובמבר 2018: ביטול הטוקנים ושינוי שלהם הושלמו עבור כל הטוקנים שאולי הושפעו. אין צורך לבצע פעולה נוספת. לאחרונה Google גילתה בעיה בתוסף Calico Container Network Interface‏ (CNI), שיכולה, בהגדרות מסוימות, לרשום ביומן מידע רגיש. הבעיה הזו מתועדת בייעוץ הטכני של Tigera TTA-2018-001. כשמריצים את הפלאגין Calico CNI עם רישום ביומן ברמת ניפוי הבאגים, הוא כותב את ההגדרה של לקוח Kubernetes API ביומנים. בנוסף, אם השדה k8s_auth_token מוגדר בהגדרת הרשת של CNI,‏ Calico CNI יכתוב את טוקן ה-API של Kubernetes ליומנים ברמת המידע. בנוסף, כשמריצים עם רישום ברמת ניפוי הבאגים, אם האסימון של חשבון השירות מוגדר באופן מפורש, בקובץ התצורה של Calico שנקרא על ידי Calico, או כמשתני סביבה שמשמשים את Calico, רכיבי Calico (calico/node, felix, CNI) יכתבו את המידע הזה לקובצי היומן. ל-tokens האלה יש את ההרשאות הבאות:

תיאור

עדכון מ-16 בנובמבר 2018: ביטול הטוקנים ושינוי שלהם הושלמו עבור כל הטוקנים שאולי הושפעו. אין צורך לבצע פעולה נוספת.

לאחרונה Google גילתה בעיה בתוסף Calico Container Network Interface‏ (CNI), שיכולה, בהגדרות מסוימות, לרשום ביומן מידע רגיש. הבעיה הזו מתועדת בייעוץ הטכני של Tigera TTA-2018-001.

כשמריצים את הפלאגין Calico CNI עם רישום ביומן ברמת ניפוי הבאגים, הוא כותב את ההגדרה של לקוח Kubernetes API ביומנים.
בנוסף, אם השדה k8s_auth_token מוגדר בהגדרת הרשת של CNI,‏ Calico CNI יכתוב את טוקן ה-API של Kubernetes ליומנים ברמת המידע.
בנוסף, כשמריצים עם רישום ברמת ניפוי הבאגים, אם האסימון של חשבון השירות מוגדר באופן מפורש, בקובץ התצורה של Calico שנקרא על ידי Calico, או כמשתני סביבה שמשמשים את Calico, רכיבי Calico (calico/node, felix, CNI) יכתבו את המידע הזה לקובצי היומן.

ל-tokens האלה יש את ההרשאות הבאות:

bgpconfigurations.crd.projectcalico.org     [create get list update watch]
bgppeers.crd.projectcalico.org              [create get list update watch]
clusterinformations.crd.projectcalico.org   [create get list update watch]
felixconfigurations.crd.projectcalico.org   [create get list update watch]
globalbgpconfigs.crd.projectcalico.org      [create get list update watch]
globalfelixconfigs.crd.projectcalico.org    [create get list update watch]
globalnetworkpolicies.crd.projectcalico.org [create get list update watch]
globalnetworksets.crd.projectcalico.org     [create get list update watch]
hostendpoints.crd.projectcalico.org         [create get list update watch]
ippools.crd.projectcalico.org               [create get list update watch]
networkpolicies.crd.projectcalico.org       [create get list update watch]
nodes                                       [get list update watch]
pods                                        [get list watch patch]
namespaces                                  [get list watch]
networkpolicies.extensions                  [get list watch]
endpoints                                   [get]
services                                    [get]
pods/status                                 [update]
networkpolicies.networking.k8s.io           [watch list]

אשכולות Google Kubernetes Engine עם מדיניות רשת של אשכולות ו-Stackdriver Logging מופעלים, נרשמו ביומן אסימוני חשבון שירות של Calico ב-Stackdriver. האפשרות הזו לא משפיעה על אשכולות שבהם לא מופעלת מדיניות רשת.

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

במהלך השבוע הקרוב נבצע ביטול הדרגתי של כל האסימונים שעשויים להיות מושפעים. העדכון הזה יתפרסם אחרי שהביטול יושלם. לא נדרשת כל פעולה נוספת מצידך. (הסבב הזה הושלם בתאריך 2018-11-16)

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

kubectl get sa --namespace kube-system calico -o template --template '{{(index .secrets 0).name}}' | xargs kubectl delete secret --namespace kube-system

זיהוי

‫GKE מתעד ביומן את כל הגישה לשרת ה-API. כדי לבדוק אם נעשה שימוש באסימון Calico מחוץ לטווח כתובות ה-IP הצפוי של Google Cloud, אפשר להריץ את שאילתת Stackdriver הבאה. שימו לב: הפעולה הזו תחזיר רק רשומות של שיחות שבוצעו מחוץ לרשת של GCP. כדאי להתאים אותו אישית לפי הצורך לסביבה הספציפית שלכם.

resource.type="k8s_cluster"
protoPayload.authenticationInfo.principalEmail="system:serviceaccount:kube-system:calico"
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "8.34.208.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "8.35.192.0/21")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "8.35.200.0/23")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "108.59.80.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "108.170.192.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "108.170.208.0/21")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "108.170.216.0/22")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "108.170.220.0/23")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "108.170.222.0/24")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.224.0.0/13")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "162.216.148.0/22")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "162.222.176.0/21")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "173.255.112.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "192.158.28.0/22")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "199.192.112.0/22")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "199.223.232.0/22")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "199.223.236.0/23")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "23.236.48.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "23.251.128.0/19")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.204.0.0/14")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.208.0.0/13")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "107.167.160.0/19")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "107.178.192.0/18")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "146.148.2.0/23")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "146.148.4.0/22")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "146.148.8.0/21")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "146.148.16.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "146.148.32.0/19")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "146.148.64.0/18")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.203.0.0/17")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.203.128.0/18")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.203.192.0/19")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.203.240.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "130.211.8.0/21")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "130.211.16.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "130.211.32.0/19")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "130.211.64.0/18")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "130.211.128.0/17")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "104.154.0.0/15")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "104.196.0.0/14")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "208.68.108.0/23")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.184.0.0/14")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.188.0.0/15")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.202.0.0/16")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.190.0.0/17")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.190.128.0/18")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.190.192.0/19")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.235.224.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.192.0.0/14")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.196.0.0/15")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.198.0.0/16")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.199.0.0/17")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.199.128.0/18")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.200.0.0/15")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "2600:1900::/35")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.190.224.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.232.0.0/15")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.234.0.0/16")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.235.0.0/17")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.235.192.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.236.0.0/14")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.240.0.0/15")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.203.232.0/21")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "130.211.4.0/22")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.220.0.0/14")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.242.0.0/15")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.244.0.0/14")

‫14 באוגוסט 2018

תיאור	רמת סיכון	הערות
‫Intel דיווחה על עדכוני ה-CVE הבאים: ‫CVE-2018-3615 (ל-SGX) ‫CVE-2018-3620 (למערכות הפעלה ול-SMT) ‫CVE-2018-3646 (למקרים של וירטואליזציה) ה-CVE האלה נקראים ביחד 'תקלה בטרמינל L1 (L1TF)'. נקודות החולשה האלה של L1TF מנצלות ביצוע ספקולטיבי על ידי תקיפת ההגדרה של מבני נתונים ברמת המעבד. ‫L1 מתייחס למטמון נתונים ברמה 1 (L1D), משאב קטן בתוך הליבה שמשמש להאצת הגישה לזיכרון. קראו את הפוסט בבלוג של Google Cloud לפרטים נוספים על נקודות החולשה האלה ועל אמצעי ההגנה של Compute Engine. ההשפעה של Google Kubernetes Engine התשתית שעליה מריצים את Kubernetes Engine ומבודדים את האשכולות והצמתים של הלקוחות זה מזה מוגנת מפני מתקפות מוכרות. מאגרי צמתים של Kubernetes Engine שמשתמשים בתמונת מערכת ההפעלה שמותאמת לקונטיינרים של Google, ושמופעלת בהם שדרוג אוטומטי, יעודכנו אוטומטית לגרסאות מתוקנות של תמונת COS שלנו כשהן יהיו זמינות, החל מהשבוע של 2018-08-20. מאגרי צמתים של Kubernetes Engine שבהם לא מופעל שדרוג אוטומטי חייבים לעבור שדרוג ידני כשהגרסאות המתוקנות של תמונת COS שלנו זמינות.	גבוהה	CVE-2018-3615 CVE-2018-3620 CVE-2018-3646

תיאור

רמת סיכון

הערות

‫Intel דיווחה על עדכוני ה-CVE הבאים:

‫CVE-2018-3615 (ל-SGX)
‫CVE-2018-3620 (למערכות הפעלה ול-SMT)
‫CVE-2018-3646 (למקרים של וירטואליזציה)

ה-CVE האלה נקראים ביחד 'תקלה בטרמינל L1 (L1TF)'.

נקודות החולשה האלה של L1TF מנצלות ביצוע ספקולטיבי על ידי תקיפת ההגדרה של מבני נתונים ברמת המעבד. ‫L1 מתייחס למטמון נתונים ברמה 1 (L1D), משאב קטן בתוך הליבה שמשמש להאצת הגישה לזיכרון.

קראו את הפוסט בבלוג של Google Cloud לפרטים נוספים על נקודות החולשה האלה ועל אמצעי ההגנה של Compute Engine.

ההשפעה של Google Kubernetes Engine

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

מאגרי צמתים של Kubernetes Engine שמשתמשים בתמונת מערכת ההפעלה שמותאמת לקונטיינרים של Google, ושמופעלת בהם שדרוג אוטומטי, יעודכנו אוטומטית לגרסאות מתוקנות של תמונת COS שלנו כשהן יהיו זמינות, החל מהשבוע של 2018-08-20.

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

גבוהה

‫6 באוגוסט 2018; עדכון אחרון: 5 בספטמבר 2018

תיאור	רמת סיכון	הערות
עדכון מ-2018-09-05 CVE-2018-5391 נחשף לאחרונה. בדומה ל-CVE-2018-5390, זוהי נקודת חולשה ברשת ברמת הליבה, שמגדילה את היעילות של התקפות מניעת שירות (DoS) נגד מערכות פגיעות. ההבדל העיקרי הוא שאפשר לנצל את CVE-2018-5391 דרך חיבורי IP. עדכנו את העלון הזה כדי לכלול את שתי נקודות החולשה האלה. תיאור ‫CVE-2018-5390 (SegmentSmack) מתאר נקודת חולשה ברשת ברמת הליבה, שמגבירה את היעילות של התקפות מניעת שירות (DoS) נגד מערכות פגיעות בחיבורי TCP. ‫CVE-2018-5391 (FragmentSmack) מתאר נקודת חולשה ברשת ברמת הליבה שמגבירה את היעילות של התקפות מניעת שירות (DoS) נגד מערכות פגיעות דרך חיבורי IP. ההשפעה של Google Kubernetes Engine החל מ-11 באוגוסט 2018, כל השרתים הראשיים של Kubernetes Engine מוגנים מפני שתי נקודות החולשה. בנוסף, כל האשכולות של Kubernetes Engine שהוגדר להם שדרוג אוטומטי מוגנים גם מפני שתי נקודות החולשה. מאגרי צמתים של Kubernetes Engine שלא הוגדרו לשדרוג אוטומטי, ושודרגו ידנית לאחרונה לפני 11 באוגוסט 2018, מושפעים משתי נקודות החולשה. גרסאות עם תיקון בגלל חומרת נקודת החולשה הזו, מומלץ לשדרג ידנית את הצמתים ברגע שהתיקון יהיה זמין.	גבוהה	CVE-2018-5390 CVE-2018-5391

תיאור

רמת סיכון

הערות

עדכון מ-2018-09-05

CVE-2018-5391 נחשף לאחרונה. בדומה ל-CVE-2018-5390, זוהי נקודת חולשה ברשת ברמת הליבה, שמגדילה את היעילות של התקפות מניעת שירות (DoS) נגד מערכות פגיעות. ההבדל העיקרי הוא שאפשר לנצל את CVE-2018-5391 דרך חיבורי IP. עדכנו את העלון הזה כדי לכלול את שתי נקודות החולשה האלה.

תיאור

‫CVE-2018-5390 (SegmentSmack) מתאר נקודת חולשה ברשת ברמת הליבה, שמגבירה את היעילות של התקפות מניעת שירות (DoS) נגד מערכות פגיעות בחיבורי TCP.

‫CVE-2018-5391 (FragmentSmack) מתאר נקודת חולשה ברשת ברמת הליבה שמגבירה את היעילות של התקפות מניעת שירות (DoS) נגד מערכות פגיעות דרך חיבורי IP.

ההשפעה של Google Kubernetes Engine

החל מ-11 באוגוסט 2018, כל השרתים הראשיים של Kubernetes Engine מוגנים מפני שתי נקודות החולשה. בנוסף, כל האשכולות של Kubernetes Engine שהוגדר להם שדרוג אוטומטי מוגנים גם מפני שתי נקודות החולשה. מאגרי צמתים של Kubernetes Engine שלא הוגדרו לשדרוג אוטומטי, ושודרגו ידנית לאחרונה לפני 11 באוגוסט 2018, מושפעים משתי נקודות החולשה.

גרסאות עם תיקון

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

גבוהה

‫30 במאי 2018

תיאור רמת סיכון הערות

תיאור	רמת סיכון	הערות
לאחרונה התגלתה נקודת חולשה ב-Git, שיכולה לאפשר הסלמת הרשאות ב-Kubernetes אם משתמשים לא מורשים יכולים ליצור נפחי gitRepo של Pod. ה-CVE מזוהה באמצעות התג CVE-2018-11235. האם השינוי הזה ישפיע עליי? נקודת החולשה באבטחה משפיעה עליכם אם מתקיימים כל התנאים הבאים: משתמשים לא מהימנים יכולים ליצור Pods (או להפעיל יצירה של Pods). לפודים שנוצרו על ידי משתמשים לא מהימנים יש הגבלות שמונעות גישת root למארח (לדוגמה, באמצעות PodSecurityPolicy). לפודים שנוצרו על ידי משתמשים לא מהימנים מותר להשתמש בסוג הווליום gitRepo. כל הצמתים של Kubernetes Engine פגיעים. מה לעשות? אסור להשתמש בסוג הנפח gitRepo. כדי לאסור שימוש בנפחי gitRepo באמצעות PodSecurityPolicy, צריך להשמיט את `gitRepo` מהרשימה הלבנה `volumes` ב-PodSecurityPolicy. אפשר להשיג התנהגות נפח gitRepo שוות ערך על ידי שכפול מאגר git לנפח EmptyDir מ-initContainer: apiVersion: v1 kind: Pod metadata: name: git-repo-example spec: initContainers: # This container clones the desired git repo to the EmptyDir volume. - name: git-clone image: alpine/git # Any image with git will do args: - clone - --single-branch - -- - https://github.com/kubernetes/kubernetes # Your repo - /repo # Put it in the volume securityContext: runAsUser: 1 # Any non-root user will do. Match to the workload. allowPrivilegeEscalation: false readOnlyRootFilesystem: true volumeMounts: - name: git-repo mountPath: /repo containers: ... volumes: - name: git-repo emptyDir: {} איזה תיקון מטפל בנקודת החולשה הזו? תיקון יכלל בגרסה הקרובה של Kubernetes Engine. כדאי לחזור לכאן ולבדוק אם יש פרטים נוספים.	בינוני	CVE-2018-11235

לאחרונה התגלתה נקודת חולשה ב-Git, שיכולה לאפשר הסלמת הרשאות ב-Kubernetes אם משתמשים לא מורשים יכולים ליצור נפחי gitRepo של Pod. ה-CVE מזוהה באמצעות התג CVE-2018-11235.

האם השינוי הזה ישפיע עליי?

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

משתמשים לא מהימנים יכולים ליצור Pods (או להפעיל יצירה של Pods).
לפודים שנוצרו על ידי משתמשים לא מהימנים יש הגבלות שמונעות גישת root למארח (לדוגמה, באמצעות PodSecurityPolicy).
לפודים שנוצרו על ידי משתמשים לא מהימנים מותר להשתמש בסוג הווליום gitRepo.

כל הצמתים של Kubernetes Engine פגיעים.

מה לעשות?

אסור להשתמש בסוג הנפח gitRepo. כדי לאסור שימוש בנפחי gitRepo באמצעות PodSecurityPolicy, צריך להשמיט את gitRepo מהרשימה הלבנה volumes ב-PodSecurityPolicy.

אפשר להשיג התנהגות נפח gitRepo שוות ערך על ידי שכפול מאגר git לנפח EmptyDir מ-initContainer:

apiVersion: v1
kind: Pod
metadata:
  name: git-repo-example
spec:
  initContainers:
    # This container clones the desired git repo to the EmptyDir volume.
    - name: git-clone
      image: alpine/git # Any image with git will do
      args:
        - clone
        - --single-branch
        - --
        - https://github.com/kubernetes/kubernetes # Your repo
        - /repo # Put it in the volume
      securityContext:
        runAsUser: 1 # Any non-root user will do. Match to the workload.
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
      volumeMounts:
        - name: git-repo
          mountPath: /repo
  containers:
    ...
  volumes:
    - name: git-repo
      emptyDir: {}

איזה תיקון מטפל בנקודת החולשה הזו?

תיקון יכלל בגרסה הקרובה של Kubernetes Engine. כדאי לחזור לכאן ולבדוק אם יש פרטים נוספים.

בינוני

CVE-2018-11235

‫21 במאי 2018

תיאור	רמת סיכון	הערות
לאחרונה התגלו מספר נקודות חולשה בליבה של Linux, שעלולות לאפשר הסלמת הרשאות או התקפת מניעת שירות (DoS) (באמצעות קריסה של הליבה) מתהליך לא מורשה. מספרי ה-CVE האלה הם CVE-2018-1000199,‏ CVE-2018-8897 ו-CVE-2018-1087. כל הצמתים של Kubernetes Engine מושפעים מנקודות החולשה האלה, ומומלץ לשדרג לגרסה האחרונה עם התיקון, כמו שמפורט בהמשך. מה לעשות? כדי לשדרג, קודם צריך לשדרג את המאסטר לגרסה החדשה ביותר. התיקון הזה זמין ב-Kubernetes Engine 1.8.12-gke.1,‏ Kubernetes Engine 1.9.7-gke.1 ו-Kubernetes Engine 1.10.2-gke.1. הגרסאות האלה כוללות תיקונים לקובצי אימג' של מערכת הפעלה שמותאמת לקונטיינרים ושל Ubuntu. אם יוצרים אשכול חדש לפני כן, צריך לציין את הגרסה המתוקנת כדי להשתמש בה. לקוחות שהפעילו שדרוגים אוטומטיים של צמתים ולא ישדרגו ידנית את הצמתים שלהם, יקבלו בשבועות הקרובים שדרוג של הצמתים לגרסאות עם תיקוני אבטחה. אילו נקודות חולשה טופלו במסגרת התיקון הזה? התיקון טיפל בנקודות החולשה הבאות: ‫CVE-2018-1000199: נקודת החולשה הזו משפיעה על ליבת Linux. היא מאפשרת למשתמש או לתהליך לא מורשים להפיל את ליבת המערכת, מה שמוביל למתקפת מניעת שירות (DoS) או להסלמת הרשאות. נקודת החולשה הזו היא ברמת סיכון גבוהה, עם ציון CVSS של 7.8. ‫CVE-2018-8897: נקודת החולשה הזו משפיעה על ליבת Linux. היא מאפשרת למשתמש או לתהליך ללא הרשאות להפיל את ליבת המערכת, מה שמוביל למתקפת מניעת שירות (DoS). נקודת החולשה הזו היא ברמת סיכון בינונית, עם ציון CVSS של 6.5. ‫CVE-2018-1087: נקודת החולשה הזו משפיעה על hypervisor של KVM בליבת Linux. היא מאפשרת לתהליך ללא הרשאות להפיל את ליבת האורח או לקבל הרשאות. נקודת החולשה הזו תוקנה בתשתית שעליה מריצים את Kubernetes Engine, ולכן אין השפעה על Kubernetes Engine. זו נקודת חולשה ברמת סיכון גבוהה, עם ציון CVSS של 8.0.	גבוהה	CVE-2018-1000199 CVE-2018-8897 CVE-2018-1087

תיאור

רמת סיכון

הערות

לאחרונה התגלו מספר נקודות חולשה בליבה של Linux, שעלולות לאפשר הסלמת הרשאות או התקפת מניעת שירות (DoS) (באמצעות קריסה של הליבה) מתהליך לא מורשה. מספרי ה-CVE האלה הם CVE-2018-1000199,‏ CVE-2018-8897 ו-CVE-2018-1087. כל הצמתים של Kubernetes Engine מושפעים מנקודות החולשה האלה, ומומלץ לשדרג לגרסה האחרונה עם התיקון, כמו שמפורט בהמשך.

מה לעשות?

כדי לשדרג, קודם צריך לשדרג את המאסטר לגרסה החדשה ביותר. התיקון הזה זמין ב-Kubernetes Engine 1.8.12-gke.1,‏ Kubernetes Engine 1.9.7-gke.1 ו-Kubernetes Engine 1.10.2-gke.1. הגרסאות האלה כוללות תיקונים לקובצי אימג' של מערכת הפעלה שמותאמת לקונטיינרים ושל Ubuntu.

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

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

התיקון טיפל בנקודות החולשה הבאות:

‫CVE-2018-1000199: נקודת החולשה הזו משפיעה על ליבת Linux. היא מאפשרת למשתמש או לתהליך לא מורשים להפיל את ליבת המערכת, מה שמוביל למתקפת מניעת שירות (DoS) או להסלמת הרשאות. נקודת החולשה הזו היא ברמת סיכון גבוהה, עם ציון CVSS של 7.8.

‫CVE-2018-8897: נקודת החולשה הזו משפיעה על ליבת Linux. היא מאפשרת למשתמש או לתהליך ללא הרשאות להפיל את ליבת המערכת, מה שמוביל למתקפת מניעת שירות (DoS). נקודת החולשה הזו היא ברמת סיכון בינונית, עם ציון CVSS של 6.5.

‫CVE-2018-1087: נקודת החולשה הזו משפיעה על hypervisor של KVM בליבת Linux. היא מאפשרת לתהליך ללא הרשאות להפיל את ליבת האורח או לקבל הרשאות. נקודת החולשה הזו תוקנה בתשתית שעליה מריצים את Kubernetes Engine, ולכן אין השפעה על Kubernetes Engine. זו נקודת חולשה ברמת סיכון גבוהה, עם ציון CVSS של 8.0.

גבוהה

‫12 במרץ 2018

תיאור	רמת סיכון	הערות
בפרויקט Kubernetes חשפו לאחרונה נקודות חולשה חדשות באבטחה, CVE-2017-1002101 ו-CVE-2017-1002102, שמאפשרות לקונטיינרים לגשת לקבצים מחוץ לקונטיינר. כל הצמתים של Kubernetes Engine מושפעים מנקודות החולשה האלה, ומומלץ לשדרג אותם לגרסה האחרונה עם התיקון בהקדם האפשרי, כמו שמפורט בהמשך. מה לעשות? בגלל חומרת נקודות החולשה האלה, מומלץ לשדרג ידנית את הצמתים ברגע שהתיקון יהיה זמין, גם אם הפעלתם שדרוגים אוטומטיים של צמתים. התיקון יהיה זמין לכל הלקוחות עד 16 במרץ, אבל יכול להיות שהוא יהיה זמין לכם מוקדם יותר בהתאם לאזור שבו האשכול שלכם נמצא, לפי לוח הזמנים של ההפצה. כדי לשדרג, קודם צריך לשדרג את המאסטר לגרסה החדשה ביותר. התיקון הזה יהיה זמין ב-Kubernetes 1.9.4-gke.1, Kubernetes 1.8.9-gke.1 וב-Kubernetes 1.7.14-gke.1. עד 30 במרץ, אשכולות חדשים ישתמשו בגרסה המתוקנת כברירת מחדל. אם תיצרו אשכול חדש לפני התאריך הזה, תצטרכו לציין את הגרסה המתוקנת כדי שהמערכת תשתמש בה. לקוחות Kubernetes Engine שהפעילו שדרוגים אוטומטיים של הצמתים ולא ישדרגו את הצמתים באופן ידני, הצמתים שלהם ישודרגו לגרסאות עם תיקוני אבטחה עד 23 באפריל. עם זאת, בגלל אופי נקודת החולשה, מומלץ לשדרג את הצמתים באופן ידני ברגע שהתיקון יהיה זמין. אילו נקודות חולשה טופלו במסגרת התיקון הזה? התיקון טיפל בשתי נקודות החולשה הבאות: נקודת החולשה CVE-2017-1002101 מאפשרת לקונטיינרים שמשתמשים בתושבות של נפח אחסון בנתיב משני לגשת לקבצים מחוץ לנפח האחסון. המשמעות היא שאם אתם חוסמים גישה של קונטיינרים לנפחי hostpath באמצעות PodSecurityPolicy, תוקף עם יכולת לעדכן או ליצור פודים יכול להטמיע כל hostpath באמצעות כל סוג נפח אחר. נקודת החולשה CVE-2017-1002102 מאפשרת לקונטיינרים שמשתמשים בסוגים מסוימים של נפח אחסון – כולל סודות, מפות הגדרות, נפחי אחסון מוקרנים או נפחי אחסון של API כלפי מטה – למחוק קבצים מחוץ לנפח האחסון. המשמעות היא שאם קונטיינר שמשתמש באחד מסוגי נפח האחסון האלה נפרץ, או אם אתם מאפשרים למשתמשים לא מהימנים ליצור פודים, תוקף יכול להשתמש בקונטיינר הזה כדי למחוק קבצים שרירותיים במארח. מידע נוסף על התיקון זמין בפוסט בבלוג של Kubernetes.	גבוהה	CVE-2017-1002101 CVE-2017-1002102

תיאור

רמת סיכון

הערות

בפרויקט Kubernetes חשפו לאחרונה נקודות חולשה חדשות באבטחה, CVE-2017-1002101 ו-CVE-2017-1002102, שמאפשרות לקונטיינרים לגשת לקבצים מחוץ לקונטיינר. כל הצמתים של Kubernetes Engine מושפעים מנקודות החולשה האלה, ומומלץ לשדרג אותם לגרסה האחרונה עם התיקון בהקדם האפשרי, כמו שמפורט בהמשך.

מה לעשות?

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

כדי לשדרג, קודם צריך לשדרג את המאסטר לגרסה החדשה ביותר. התיקון הזה יהיה זמין ב-Kubernetes 1.9.4-gke.1, Kubernetes 1.8.9-gke.1 וב-Kubernetes 1.7.14-gke.1. עד 30 במרץ, אשכולות חדשים ישתמשו בגרסה המתוקנת כברירת מחדל. אם תיצרו אשכול חדש לפני התאריך הזה, תצטרכו לציין את הגרסה המתוקנת כדי שהמערכת תשתמש בה.

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

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

התיקון טיפל בשתי נקודות החולשה הבאות:

נקודת החולשה CVE-2017-1002101 מאפשרת לקונטיינרים שמשתמשים בתושבות של נפח אחסון בנתיב משני לגשת לקבצים מחוץ לנפח האחסון. המשמעות היא שאם אתם חוסמים גישה של קונטיינרים לנפחי hostpath באמצעות PodSecurityPolicy, תוקף עם יכולת לעדכן או ליצור פודים יכול להטמיע כל hostpath באמצעות כל סוג נפח אחר.

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

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

גבוהה

עדכוני אבטחה דחופים של Google Distributed Cloud

‫16 באוקטובר 2019

תיאור	רמת סיכון	הערות
לאחרונה התגלתה ב-Kubernetes נקודת חולשה שמתוארת ב-CVE-2019-11253, שמאפשרת לכל משתמש שמורשה לשלוח בקשות POST להריץ התקפה מסוג מניעת שירות (DoS) מרחוק על שרת Kubernetes API. ועדת אבטחת המוצר (PSC) של Kubernetes פרסמה מידע נוסף על נקודת החולשה הזו. המידע זמין כאן. כדי לצמצם את הסיכון לניצול נקודת החולשה הזו, אפשר להגביל את הגישה של לקוחות לשרתי ה-API של Kubernetes. מה לעשות? מומלץ לשדרג את האשכולות לגרסה עם תיקון ברגע שהיא תהיה זמינה. גרסאות התיקון שבהן יופיע התיקון מפורטות בהמשך: ‫GKE Enterprise 1.1.1, שפועל על Kubernetes בגרסה ‎1.13.7-gke.30 אילו נקודות חולשה טופלו במסגרת התיקון הזה? התיקון טיפל בנקודת החולשה הבאה: CVE-2019-11253.	גבוהה	CVE-2019-11253

תיאור

רמת סיכון

הערות

לאחרונה התגלתה ב-Kubernetes נקודת חולשה שמתוארת ב-CVE-2019-11253, שמאפשרת לכל משתמש שמורשה לשלוח בקשות POST להריץ התקפה מסוג מניעת שירות (DoS) מרחוק על שרת Kubernetes API. ועדת אבטחת המוצר (PSC) של Kubernetes פרסמה מידע נוסף על נקודת החולשה הזו. המידע זמין כאן.

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

מה לעשות?

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

גרסאות התיקון שבהן יופיע התיקון מפורטות בהמשך:

‫GKE Enterprise 1.1.1, שפועל על Kubernetes בגרסה ‎1.13.7-gke.30

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

התיקון טיפל בנקודת החולשה הבאה: CVE-2019-11253.

גבוהה

CVE-2019-11253

‫23 באוגוסט 2019

תיאור רמת סיכון הערות

תיאור	רמת סיכון	הערות
לאחרונה גילינו פגיעות וצמצמנו אותה. הפגיעות הייתה ב-RBAC proxy שמשמש לאבטחת נקודות קצה של ניטור, ולא אישר למשתמשים גישה בצורה תקינה. כתוצאה מכך, מדדים מרכיבים מסוימים זמינים למשתמשים לא מורשים מתוך רשת האשכול הפנימית. הרכיבים הבאים הושפעו: `etcd` `etcd-events` `kube-apiserver` `kube-controller-manager` `kube-scheduler` `node-exporter` `kube-state-metrics` `prometheus` `alertmanager` מה לעשות? מומלץ לשדרג את האשכולות לגרסה 1.0.2-gke.3 בהקדם האפשרי, כי היא כוללת את התיקון לנקודת החולשה הזו.	בינוני	מהדורות של Google Distributed Cloud

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

etcd
etcd-events
kube-apiserver
kube-controller-manager
kube-scheduler
node-exporter
kube-state-metrics
prometheus
alertmanager

מה לעשות?

מומלץ לשדרג את האשכולות לגרסה 1.0.2-gke.3 בהקדם האפשרי, כי היא כוללת את התיקון לנקודת החולשה הזו.

בינוני

מהדורות של Google Distributed Cloud

22 באוגוסט 2019

תיאור	רמת סיכון	הערות
לאחרונה התגלתה ב-Kubernetes נקודת חולשה, CVE-2019-11247,‏ שמאפשרת לבצע פעולות על מופעים של משאבים מותאמים אישית ברמת האשכול כאילו הם אובייקטים במרחב שמות שקיימים בכל מרחבי השמות. המשמעות היא שמשתמשים וחשבונות שירות עם הרשאות RBAC ברמת מרחב השמות בלבד יכולים לבצע פעולות במשאבים מותאמים אישית בהיקף האשכול. כדי לנצל את נקודת החולשה הזו, התוקף צריך הרשאות גישה למשאב בכל מרחב שמות. מה לעשות? מומלץ לשדרג את האשכולות לגרסה 1.0.2-gke.3 בהקדם האפשרי, כי היא כוללת את התיקון לנקודת החולשה הזו. אילו נקודות חולשה טופלו במסגרת התיקון הזה? התיקון טיפל בנקודת החולשה הבאה: CVE-2019-11247.	בינוני	CVE-2019-11247

תיאור

רמת סיכון

הערות

מה לעשות?

מומלץ לשדרג את האשכולות לגרסה 1.0.2-gke.3 בהקדם האפשרי, כי היא כוללת את התיקון לנקודת החולשה הזו.

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

התיקון טיפל בנקודת החולשה הבאה: CVE-2019-11247.

בינוני

CVE-2019-11247

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

עדכוני אבטחה דחופים ל-GKE

14 בנובמבר 2019

12 בנובמבר 2019

מה לעשות?

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

‫22 באוקטובר 2019

‫16 באוקטובר 2019

מה לעשות?

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

‫16 בספטמבר 2019

מה לעשות?

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

5 בספטמבר 2019

22 באוגוסט 2019

‫8 באוגוסט 2019

‫5 באוגוסט 2019

מה לעשות?

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

‫3 ביולי 2019

‫3 ביולי 2019

עדכון מ-3 ביולי 2019

עדכון מ-24 ביוני 2019

שרתי מאסטר של Kubernetes

צמתים של Kubernetes

מה לעשות?

‫25 ביוני 2019

מה לעשות?

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

‫18 ביוני 2019

מה לעשות?

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

31 במאי 2019

עדכון מ-2 באוגוסט 2019

איך אפשר לדעת אם משתמשים בגרסה מושפעת?

איך אפשר לדעת אם ההגדרה הספציפית שלי מושפעת?

מה לעשות?

‫14 במאי 2019

מה לעשות?

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

5 באפריל 2019

מה לעשות?

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

‫1 במרץ 2019

מה לעשות?

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

‫11 בפברואר 2019 (runc)

מה לעשות?

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

‫11 בפברואר 2019 (Go)

מה לעשות?

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

‫3 בדצמבר 2018

מה לעשות?

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

‫13 בנובמבר 2018

זיהוי

‫14 באוגוסט 2018

ההשפעה של Google Kubernetes Engine

‫6 באוגוסט 2018; עדכון אחרון: 5 בספטמבר 2018

עדכון מ-2018-09-05

תיאור

ההשפעה של Google Kubernetes Engine

גרסאות עם תיקון

‫30 במאי 2018

האם השינוי הזה ישפיע עליי?

מה לעשות?

איזה תיקון מטפל בנקודת החולשה הזו?

‫21 במאי 2018

מה לעשות?

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

‫12 במרץ 2018

מה לעשות?

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

עדכוני אבטחה דחופים של Google Distributed Cloud

‫16 באוקטובר 2019

מה לעשות?

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

‫23 באוגוסט 2019

מה לעשות?

ארכיון עדכוני אבטחה דחופים