Config Connector הוא אופרטור (operator) של Kubernetes המאפשר לארגונים לנהל משאבי GCP – כמו אחסון ענן, מסדי נתונים ומדיניות IAM (Identity and Access Management) – באמצעות פקודות Kubernetes . הוא נועד לאחד כלים: ניתן ליצור, לעדכן ולמחוק משאבי ענן באמצעות
kubectl, כלי שורת הפקודה המוכר של Kubernetes .
אולירי גילה שלגישה המאוחדת הזו יש תופעת לוואי מסוכנת. הפרצה מאפשרת לכל משתמש ב-namespace של Kubernetes לעקוף את בקרות ה-IAM של Google Cloud Platform. מפתח עם גישה בסיסית ל-namespace בודד של Kubernetes יכול לנצל זאת כדי להשיג שליטה מלאה (administrative) על סביבת ה-GCP של ארגון שלם – כלומר, להשתלט על כל חשבון הענן . אולירי אמר ל-The Register שניתן לבצע את הניצול בכחמש שניות, ללא השארת עקבות ביקורת (audit trail)
.
למרות שגוגל לא פרסמה תיאור טכני מפורט, מקורות רבים והדיווח של אולירי מצביעים על כך שהפגיעות נעוצה באופן שבו Config Connector מטפל בהרשאות IAM בין namespaces שונים של Kubernetes .
באשכול GKE (Google Kubernetes Engine) מרובה-דיירים (multi-tenant) המוגדר כראוי, namespaces שונים אמורים להיות מבודדים – משתמש ב-namespace A לא אמור להיות מסוגל לנהל משאבים ב-namespace B או להעניק לעצמו תפקידי GCP מוגברים. התגלית של אולירי מראה שסוגי המשאבים IAM של Config Connector אינם אוכפים את גבולות ה-namespace הללו . על ידי יצירה או שינוי של משאב מדיניות IAM דרך Config Connector מתוך namespace יחיד, משתמש עם הרשאות Kubernetes מינימליות יכול להעניק לעצמו את התפקיד
roles/owner בפרויקט GCP – או בארגון כולו .
זוהי הפרה של עקרון ההרשאות המינימליות (principle of least privilege) ועקיפה ישירה של שכבת ההרשאות של GCP (IAM). לא מדובר בתצורה שגויה שמנהל יכול לתקן; מדובר בפגם ברמת התכנון (design-level flaw) באופן שבו Config Connector מאציל סמכויות IAM .
לפי דיווח בלעדי של The Register מיום 18 ביוני 2026 ומקורות תומכים, ציר הזמן התפתח כך:
גוגל לא הסבירה בפומבי את ההיפוך בעמדתה, אך מספר גורמים עשויים לשחק תפקיד, בהתבסס על כללי Cloud VRP וההקשר הרחב יותר של השינויים בתוכניות התגמולים של גוגל לשנת 2026.
הכללים הרשמיים של Cloud VRP קובעים: "דוחות פגיעות של Google Cloud שבהם נבדקו משאבים שבבעלות הלקוח אינם זכאים לתגמולים." היקף התוכנית מוגבל במפורש לפגיעות בתשתיות ובשירותים שבבעלות גוגל, ולא ברכיבים שניתנים להגדרה על ידי הלקוח . אם גוגל ראתה בהתנהגות Config Connector עניין של תצורת לקוח ולא פגיעות מוצר, היא יכלה לסרב טכנית לתגמול תחת לשון זו – גם אם ההתנהגות עוקפת בקרות IAM מצופות.
אפשרות נוספת: כללי Cloud VRP קובעים שהתוכנית מכסה "ליקויי אימות או הרשאה" בפריטים שבתחומה, מה שאמור לכסות את הממצא של אולירי . אבל גוגל טענה בעבר בהקשרים אחרים שהסלמות הרשאות מסוימות אינן באגים אם הן דורשות הרשאות ספציפיות כדי להפעיל אותן – עמדה שספגה ביקורת מצד חוקרים
. במקרה של אולירי, ההרשאה הראשונית הנדרשת (גישה ברמת namespace למשאבי Config Connector) היא מינימלית ומוענקת בדרך כלל למפתחים, מה שהופך את ההסלמה לאמיתית ומסוכנת כאחד
.
גורם שלישי קשור לארגון מחדש של תוכניות תגמולי הבאגים לשנת 2026 של גוגל עבור Chrome ואנדרואיד. בסוף אפריל ותחילת מאי 2026, גוגל הודיעה שהיא קוצצת תשלומי Chrome ומבצעת ארגון מחדש של תגמולים, תוך ציטוט של גל דיווחים באיכות נמוכה שנוצרו על ידי בינה מלאכותית . החברה הצהירה שהיא "מפחיתה חלק מסכומי התגמולים והבונוסים ברחבי אנדרואיד ו-Chrome" כדי להתמקד ב*"איכות והשפעה בעולם האמיתי על פני כמויות גרידא"*
. בעוד שהמקרה של אולירי נופל תחת Cloud VRP הנפרד, ולא תחת תוכניות Chrome או אנדרואיד, העמדה הפומבית של החברה לגבי הידוק התשלומים עשויה הייתה להשפיע על ההחלטה – במיוחד אם גוגל ראתה בסוגיית Config Connector בחירה עיצובית ולא באג
.
התקרית עוררה ביקורת מצד קהילת חוקרי האבטחה, כאשר חלקם טוענים שגוגל משתמשת בנרטיב הדיווחים מבוססי הבינה המלאכותית ככיסוי לשלילת תגמולים לגיטימיים שהתגלו באופן ידני . פרשנות של PC Perspective כינתה את ההחלטה "להיות קמצנים לגבי תגמולי באגים" וציינה את הפער בין השבח הראשוני של גוגל לסירוב הסופי
. Cyber News Live הדגיש שהפרצה עלולה לאפשר השתלטות בת חמש שניות ללא השארת עקבות
.
המקרה מתרחש גם בתקופה שבה גוגל במקביל מגדילה תגמולים עליונים עבור קטגוריות מסוימות של באגי אנדרואיד – עד 1.5 מיליון דולר עבור ניצול Titan M zero-click מתמשך . גישה דו-כיוונית זו – תגמול נדיב על ניצולי חומרה עמוקים תוך סירוב אפילו להכרה בהסלמת הרשאות ענן חמורה – הזינה תפיסות לפיהן תוכניות תגמולי הבאגים של גוגל מקצות משאבים באופן אסטרטגי ולא מעריכות סיכונים בכנות
.
ארגונים המפעילים Config Connector באשכולות GKE מרובי-דיירים או משותפים צריכים להתייחס לכך כאל סיכון דחוף שלא תוקן. ללא תיקון רשמי מגוגל, ניתן להפחית את החשיפה באמצעים הבאים:
iam* ברמת ה-namespace באמצעות מדיניות Kubernetes RBAC. אל תעניק הרשאות create, update או Delete על משאבים מותאמים אישית (Custom Resources) מסוג IAMPolicy, IAMPolicyMember או IAMPartialPolicy ל-namespaces לא מהימנים.setIamPolicy שמקורן באשכול GKE שלך.התיעוד הרשמי של גוגל בנושא אבטחת גישה למשאבים עם IAM מתאר תצורות מומלצות אך אינו מתייחס לווקטור העקיפה בין namespaces שבלב הדיווח של אולירי . ארגונים צריכים להניח שהפריסות שלהם של Config Connector עלולות להיות פגיעות.
Comments
0 comments