שיטות מומלצות להקשחת האבטחה באשכול

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

סקירה מרוכזת של כל השיטות המומלצות ל-GKE זמינה במאמר שיטות מומלצות ל-GKE.

חשוב לוודא שאתם כבר מכירים את הנושאים הבאים:

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

כדי ליישם את השיטות המומלצות שמתוארות במסמך הזה בארגון שלכם, כדאי להשתמש בשירותים הבאים:

  • ‫Security Command Center: בודק באופן אוטומטי אם באשכולות שלכם מיושמות רבות מהשיטות המומלצות האלה, וגם בודק אם יש טעויות נפוצות אחרות בהגדרות.
  • שירות מדיניות הארגון: מאפשר לאכוף שיטות מומלצות ספציפיות במשאבי GKE בארגון, בתיקייה או בפרויקט. במסמך הזה יש קטעים ספציפיים עם קישורים למסוף Cloud de Confiance , שדרכם אפשר להחיל אילוצים מנוהלים על ההמלצות האלה.

Cloud de Confiance עיצוב סביבה

בקטעים הבאים מתוארים אמצעי אבטחה שכדאי לקחת בחשבון כשמתכננים ומעצבים את המשאבים ב- Cloud de Confiance. אדריכלי ענן צריכים להשתמש בהמלצות האלה כשהם מתכננים ומגדירים Cloud de Confiance ארכיטקטורה.

שיטות מומלצות

תכנון של Cloud de Confiance מבנה המשאבים

מומלץ: להטמיע את תוכנית הבסיס של Enterprise, שהיא בסיס מלא לסביבת ה-Enterprise שלכם על סמך שיטות העבודה המומלצות שלנו.

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

תכנון סביבות Multi-tenant

מומלץ: להטמיע את Cloud de Confiance השיטות המומלצות ל-GKE ולפלטפורמות ארגוניות עם ריבוי דיירים.

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

מידע נוסף זמין במאמרים הבאים:

שימוש בתגים לקיבוץ Cloud de Confiance משאבים

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

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

מידע נוסף זמין במאמרים הבאים:

תכנון רשתות VPC

מומלץ: להטמיע את Cloud de Confiance השיטות המומלצות של GKE לתכנון רשת VPC.

העיצוב של רשת ה-VPC והתכונות שבהן אתם משתמשים משפיעים על אבטחת הרשת. תכננו את הרשתות בהתאם להיררכיית המשאבים וליעדי האבטחה. Cloud de Confianceמידע נוסף זמין במאמרים הבאים:

תכנון תוכנית לתגובה לתקריות

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

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

Cloud de Confiance אבטחת רשת

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

שיטות מומלצות

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

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

‫GKE יוצר כללי חומת אש של VPC שמוגדרים כברירת מחדל כדי לאפשר פונקציונליות של המערכת ולאכוף שיטות מומלצות לאבטחה. אם יוצרים כללים מתירים לחומת אש עם עדיפות גבוהה יותר מכלל ברירת מחדל לחומת אש (לדוגמה, כלל לחומת אש שמאפשר את כל תעבורת הנתונים הנכנסת (ingress) לצורך ניפוי באגים), קיים סיכון לגישה לא מכוונת לאשכול.

שימוש ב-VPC משותף לתעבורה בין פרויקטים

מומלץ: להשתמש ב-VPC משותף כדי לאפשר למשאבים בכמה פרויקטים לתקשר ביניהם באמצעות כתובות IP פנימיות.

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

מידע נוסף זמין במאמרים הבאים:

שימוש ברשתות נפרדות כדי לבודד סביבות

מומלץ: להשתמש ברשתות VPC משותפות נפרדות לסביבות Staging, בדיקה וייצור.

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

הגדרות אבטחה שלא ניתן לשנות

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

שימוש בחשבונות שירות של צמתים ב-IAM עם הרשאות מינימליות

מומלץ: להשתמש בחשבון שירות מותאם אישית של IAM עבור אגני הצמתים ואשכולות GKE, במקום להשתמש בחשבון השירות שמוגדר כברירת מחדל של Compute Engine.

ב-GKE נעשה שימוש בחשבונות שירות של IAM שמצורפים לצמתים כדי להריץ משימות מערכת כמו רישום ביומן ומעקב. לפחות, חשבונות השירות של הצמתים צריכים לקבל את התפקיד Kubernetes Engine Default Node Service Account ‏(roles/container.defaultNodeServiceAccount) בפרויקט. כברירת מחדל, GKE משתמש בחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine, שנוצר באופן אוטומטי בפרויקט, כחשבון השירות של הצומת.

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

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

כדי לאכוף את ההמלצה הזו בארגון, צריך להשתמש בconstraints/container.managed.disallowDefaultComputeServiceAccount אילוץ מנוהל של מדיניות הארגון. כדי לבדוק את ההגבלה המנוהלת הזו במסוף Cloud de Confiance , עוברים לדף פרטי המדיניות.

מעבר אל פרטי המדיניות

שימוש בתמונה של צומת של מערכת הפעלה שמותאמת לקונטיינרים

מומלץ: אלא אם יש לכם דרישה ספציפית להשתמש ב-Ubuntu או ב-Windows, כדאי להשתמש בקובץ אימג' של צומת של מערכת הפעלה שמותאמת לקונטיינרים עבור הצמתים שלכם.

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

מידע נוסף זמין במאמרים הבאים:

הגדרת אבטחה של צומת

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

שיטות מומלצות

שימוש בצומתי GKE מוגנים

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

צומתי GKE מוגנים מספקים זהות ניתנת לאימות ובדיקות תקינות שמשפרות את האבטחה של הצמתים. צומתי GKE מוגנים ותכונות כמו ניטור של תקינות הצמתים והפעלה מאובטחת מופעלים תמיד באשכולות Autopilot. ב-Standard clusters, מבצעים את הפעולות הבאות:

  • אל תשביתו את צומתי GKE המוגנים באשכולות.
  • מומלץ להפעיל את האתחול המאובטח בכל מאגרי הצמתים.
  • אל תשביתו את המעקב אחר תקינות במאגרי הצמתים.

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

כדי לאכוף את ההמלצה הזו בארגון, צריך להשתמש בconstraints/container.managed.enableShieldedNodes אילוץ מנוהל של מדיניות הארגון. כדי לבדוק את ההגבלה המנוהלת הזו במסוף Cloud de Confiance , עוברים לדף Policy details.

מעבר אל פרטי המדיניות

השבתה של יציאת kubelet לקריאה בלבד שאינה מאובטחת

מומלץ: להשבית את יציאת kubelet לקריאה בלבד ולהעביר את כל עומסי העבודה שמשתמשים ביציאה 10255 לשימוש ביציאה 10250 המאובטחת יותר.

תהליך kubelet שפועל בצמתים משרת API לקריאה בלבד באמצעות יציאה לא מאובטחת 10255. ‫Kubernetes לא מבצעת ביציאה הזו בדיקות אימות או הרשאה. ‫kubelet משרת את אותן נקודות קצה ביציאה המאומתת והמאובטחת יותר 10250.

מידע נוסף זמין במאמר השבתת יציאת הקריאה בלבד kubelet באשכולות GKE.

כדי לאכוף את ההמלצה הזו בארגון, צריך להשתמש בconstraints/container.managed.disableInsecureKubeletReadOnlyPort אילוץ מנוהל של מדיניות הארגון. כדי לבדוק את ההגבלה המנוהלת הזו במסוף Cloud de Confiance , עוברים לדף Policy details.

מעבר אל פרטי המדיניות

השבתת רישום עצמי של צמתים

מומלץ: להשתמש ברכיב מהימן של מישור הבקרה כדי ליצור אובייקטים של Node במקום kubelet.

כברירת מחדל, תהליך kubelet בצומת GKE חדש רושם את הצומת במישור הבקרה אחרי שמישור הבקרה מחזיר בקשה מאושרת לחתימה על אישור (CertificateSigningRequest). תהליך ההרשמה העצמית הזה יוצר סיכון אבטחה שבו kubelet שנפרץ יכול לרשום צמתים חדשים עם תיוגים או תוויות זדוניים, כמו ב-CVE-2025-5187.

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

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

בקרת גישה

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

שיטות מומלצות

הגבלת הגישה לגילוי API של אשכול

מומלץ: להגביל את הגישה למישור הבקרה ולצמתים מהאינטרנט כדי למנוע גישה לא מכוונת לנקודות קצה של גילוי Cluster API.

כברירת מחדל, Kubernetes יוצר אשכולות עם קבוצה מתירה של תפקידים של גילוי API כברירת מחדל. התפקידים האלה שמוגדרים כברירת מחדל מעניקים גישה רחבה למידע על ממשקי API של אשכול לקבוצות שונות שמוגדרות כברירת מחדל, כמו system:authenticated. תפקידי ברירת המחדל האלה לא מייצגים רמת אבטחה משמעותית עבור אשכולות GKE. לדוגמה, הקבוצה system:authenticated, שיכולה לקרוא מידע על ממשקי API כמו CustomResources, מוקצית לכל משתמש מאומת (כולל כל מי שיש לו חשבון Google).

כדי להגביל את הגישה לממשקי API של גילוי אשכולות, מבצעים את הפעולות הבאות:

  • הגבלת הגישה למישור הבקרה: שימוש רק בנקודת הקצה שמבוססת על DNS לגישה למישור הבקרה. אם אתם משתמשים בנקודות קצה מבוססות-IP, אתם יכולים להגביל את הגישה לסט של טווחי כתובות ידועים על ידי הגדרת רשתות מורשות.
  • הגדרת צמתים פרטיים: משביתים את כתובות ה-IP החיצוניות של הצמתים, כדי שללקוחות מחוץ לרשת לא תהיה גישה לצמתים.

מידע נוסף זמין במאמר מידע על בידוד רשת.

אם לא מפעילים את התכונות האלה של בידוד הרשת, צריך להתייחס לכל המידע על גילוי API (במיוחד הסכימה של CustomResources, ההגדרות של APIService והמידע על גילוי שמתארח בשרתים של API של תוספים) כאל מידע שגלוי לציבור.

הצבת צוותים וסביבות במרחבי שמות או באשכולות נפרדים

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

אתם יכולים להשתמש בהרשאות IAM ו-RBAC יחד עם מרחבי שמות כדי להגביל את האינטראקציות של המשתמשים עם משאבי האשכול במסוף Cloud de Confiance . מידע נוסף זמין במאמר הפעלת גישה למשאבי אשכולות והצגתם לפי מרחב שמות.

שימוש בעיקרון של הרשאות מינימליות במדיניות גישה

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

ב-GKE, אפשר להשתמש ב-IAM ובבקרת גישה מבוססת-תפקידים (RBAC) של Kubernetes כדי לתת הרשאות למשאבים. מנגנוני בקרת הגישה האלה פועלים יחד. כדי לפשט את ניהול הגישה, מומלץ:

  • כדי לתת גישה לפרויקט או ל Cloud de Confiance משאבים, משתמשים בתפקידי IAM.

  • כדי לתת גישה למשאבי Kubernetes באשכול, כמו מרחבי שמות, צריך להשתמש ב-RBAC.

מידע נוסף על תכנון ועיצוב של מדיניות IAM ו-RBAC זמין במאמרים הבאים:

שימוש באיחוד זהויות של עומסי עבודה ל-GKE כדי לגשת ל-APIs Cloud de Confiance

מומלץ: כדי לגשת למשאבי Cloud de Confiance מעומסי העבודה של GKE, משתמשים באיחוד זהויות של עומסי עבודה ל-GKE.

איחוד זהויות של עומסי עבודה ל-GKE היא הדרך המומלצת לאימות ל-Cloud de Confiance APIs. אתם יכולים להקצות תפקידי IAM למשתמשים שונים באשכול, כמו חשבונות שירות ספציפיים של Kubernetes או Pods. איחוד שירותי אימות הזהות של עומסי עבודה ל-GKE גם מגן על מטא-נתונים רגישים בצמתים ומספק תהליך עבודה מאובטח יותר לאימות בהשוואה לחלופות כמו קובצי טוקנים סטטיים.

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

  • אם אתם משתמשים בספריות לקוח בקוד האפליקציה, אל תפיצו פרטי כניסה לעומסי העבודה. Cloud de Confiance Cloud de Confiance קוד שמשתמש בספריות לקוח מאחזר באופן אוטומטי פרטי כניסה לאיחוד זהויות של עומסי עבודה ל-GKE.
  • צריך להשתמש במרחב שמות נפרד וב-ServiceAccount לכל עומס עבודה שזקוק לזהות נפרדת. מתן הרשאות IAM לחשבונות שירות ספציפיים.

מידע נוסף זמין במאמר בנושא אימות של ממשקי API מעומסי עבודה ב-GKE. Cloud de Confiance

כדי לאכוף את ההמלצה הזו בארגון, צריך להשתמש בconstraints/container.managed.enableWorkloadIdentityFederation אילוץ מנוהל של מדיניות הארגון. כדי לבדוק את ההגבלה המנוהלת הזו במסוף Cloud de Confiance , עוברים לדף Policy details.

מעבר אל פרטי המדיניות

שימוש בקבוצות לניהול הגישה

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

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

אתם יכולים לציין קבוצות ב-Google במדיניות IAM או RBAC. מידע נוסף זמין במאמרים הבאים:

כדי לאכוף את ההמלצה הזו בארגון, צריך להשתמש בconstraints/container.managed.enableGoogleGroupsRBAC אילוץ מנוהל של מדיניות הארגון. כדי לבדוק את ההגבלה המנוהלת הזו במסוף Cloud de Confiance , עוברים לדף Policy details.

מעבר אל פרטי המדיניות

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

מומלץ: מניעת בקשות אנונימיות לכל נקודות הקצה של האשכול, למעט נקודות קצה של בדיקות תקינות, בכל האשכולות של Autopilot ושל Standard.

כברירת מחדל, Kubernetes מקצה את המשתמש system:anonymous ואת הקבוצה system:unauthenticated לבקשות אנונימיות לנקודות קצה של אשכולות. אם מדיניות ה-RBAC שלכם מעניקה למשתמש או לקבוצה האלה הרשאות נוספות, משתמש לא רשום עלול לסכן את האבטחה של שירות או של האשכול עצמו.

ב-GKE מגרסה 1.32.2-gke.1234000 ואילך, אפשר להגביל את קבוצת נקודות הקצה שאליהן בקשות אנונימיות יכולות להגיע רק לנקודות הקצה של בדיקת תקינות של שרת ה-API של Kubernetes‏ /healthz,‏ /livez ו-/readyz. נדרשת גישה אנונימית לנקודות הקצה האלה של בדיקת תקינות כדי לוודא שקלאסטר פועל בצורה תקינה.

כדי להגביל גישה אנונימית לנקודות קצה של אשכולות, צריך לציין LIMITED לדגל --anonymous-authentication-config כשמשתמשים ב-CLI של gcloud או ב-GKE API כדי ליצור או לעדכן אשכולות במצב Standard או במצב Autopilot. ‫GKE דוחה בקשות אנונימיות לנקודות קצה (endpoints) של אשכולות שאינן נקודות הקצה של בדיקת תקינות במהלך האימות. בקשות אנונימיות לא מגיעות לנקודות הקצה, גם אם מדיניות RBAC מעניקה גישה למשתמשים ולקבוצות אנונימיים. בקשות שנדחות מחזירות סטטוס HTTP של 401.

בגרסה 1.35.0-gke.1171000 ואילך של GKE, גישה אנונימית לנקודות קצה שאינן בדיקות תקינות נחסמת כברירת מחדל רק באשכולות שנוצרו לאחרונה.

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

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

אבטחת רשת ב-GKE

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

שיטות מומלצות

הגבלת הגישה למישור הבקרה

מומלץ: להפעיל את נקודת הקצה שמבוססת על DNS לגישה למישור הבקרה ולהשבית את כל נקודות הקצה של מישור הבקרה שמבוססות על כתובת IP.

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

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

  • שימוש רק בנקודת הקצה מבוססת ה-DNS (מומלץ): מפעילים את נקודת הקצה מבוססת ה-DNS למישור הבקרה ומשביתים את נקודות הקצה מבוססות ה-IP הפנימיות והחיצוניות. כל הגישה למישור הבקרה חייבת להיות דרך נקודת הקצה שמבוססת על DNS. אתם יכולים להשתמש ב-VPC Service Controls כדי לקבוע למי תהיה גישה לנקודת הקצה שמבוססת על DNS.

    כדי לאכוף את ההמלצה הזו בארגון, צריך להשתמש בconstraints/container.managed.enableControlPlaneDNSOnlyAccess אילוץ מנוהל של מדיניות הארגון. כדי לבדוק את ההגבלה המנוהלת הזו במסוף Cloud de Confiance , עוברים לדף Policy details.

    מעבר אל פרטי המדיניות

  • משביתים את נקודת הקצה שמבוססת על כתובת IP חיצונית: מסירים את כתובת ה-IP החיצונית של מישור הבקרה. לקוחות שנמצאים מחוץ לרשת ה-VPC לא יכולים להשתמש בכתובת ה-IP החיצונית כדי לגשת למישור הבקרה.

    האפשרות הזו מתאימה אם אתם משתמשים בטכנולוגיות כמו Cloud Interconnect ו-Cloud VPN כדי לחבר את הרשת של החברה לרשת ה-VPC.

  • שימוש ברשתות מורשות עם נקודת הקצה שמבוססת על כתובת IP חיצונית: הגבלת הגישה לנקודת הקצה שמבוססת על כתובת IP חיצונית רק לטווח מהימן של כתובות IP חיצוניות של מקורות.

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

ברוב התרחישים, כדאי להשתמש רק בנקודת הקצה שמבוססת על DNS לגישה למישור הבקרה. אם אתם צריכים להפעיל את נקודת הקצה שמבוססת על כתובת IP, אתם יכולים להשתמש ברשתות מורשות כדי להגביל את הגישה למישור הבקרה לישויות הבאות:

  • טווח כתובות ה-IP שאתם מציינים.
  • צמתי GKE באותה רשת VPC כמו האשכול.
  • כתובות IP שמורות של Google לצורכי ניהול אשכולות.

בידוד הצמתים מהאינטרנט

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

כדי לאכוף את ההמלצה הזו בארגון, צריך להשתמש בconstraints/container.managed.enablePrivateNodes אילוץ מנוהל של מדיניות הארגון. כדי לבדוק את ההגבלה המנוהלת הזו במסוף Cloud de Confiance , עוברים לדף Policy details.

מעבר אל פרטי המדיניות

הגבלת תעבורת נתונים ברשת בין קבוצות Pod

מומלץ: לשלוט בתעבורת הנתונים ברשת בין Podים באמצעות NetworkPolicies, Service mesh או שניהם.

כברירת מחדל, כל Pod באשכול יכול לתקשר עם כל Pod אחר. הגבלת הגישה לרשת בין השירותים מקשה מאוד על תוקפים לנוע לרוחב באשכול. השירותים שלכם מקבלים גם הגנה מסוימת מפני אירועים של מניעת שירות (DoS) שנגרמים בטעות או בכוונה. בהתאם לדרישות שלכם, תוכלו להשתמש באחת מהשיטות הבאות או בשתיהן כדי להגביל את התנועה בין הפודים:

Sensitive data protection

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

שיטות מומלצות

הצפנת נתוני עומס עבודה בשימוש

אפשר להשתמש בהצפנת זיכרון מבוססת-חומרה כדי להגן על נתונים שנמצאים בשימוש בעומסי העבודה באמצעות Confidential GKE Nodes. אתם יכולים לבחור טכנולוגיית Confidential Computing בהתאם לדרישות שלכם. מידע נוסף זמין במאמר הצפנת נתונים בשימוש בעומסי עבודה באמצעות Confidential GKE Nodes.

שמירת סודות מחוץ לאשכול

מומלץ: להשתמש בכלי חיצוני לניהול סודות כמו Secret Manager כדי לאחסן נתונים רגישים, כמו מפתחות API, מחוץ לאשכול.

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

  • כל מי שיכול ליצור Pod במרחב שמות יכול לקרוא את הנתונים של כל סוד במרחב השמות הזה.
  • כל מי שיש לו גישת RBAC או IAM לקריאת כל האובייקטים של Kubernetes API יכול לקרוא סודות.

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

  • ספריות לקוח של Secret Manager: גישה פרוגרמטית לסודות מקוד האפליקציה באמצעות Secret Manager API עם איחוד שירותי אימות הזהות של עומסי עבודה ב-GKE. מידע נוסף זמין במאמר גישה לסודות שמאוחסנים מחוץ לאשכולות GKE באמצעות ספריות לקוח.
  • נתונים מ-Secret Manager כנפחי אחסון מוצמדים: אפשר לספק מידע אישי רגיש ל-Pods כנפחי אחסון מוצמדים באמצעות התוסף Secret Manager ל-GKE. השיטה הזו שימושית אם אי אפשר לשנות את קוד האפליקציה כדי להשתמש בספריות הלקוח של Secret Manager. מידע נוסף זמין במאמר בנושא שימוש בתוסף Secret Manager עם Google Kubernetes Engine.

  • כלים של צד שלישי לניהול סודות: כלים של צד שלישי כמו HashiCorp Vault מספקים יכולות לניהול סודות בעומסי עבודה של Kubernetes. הכלים האלה דורשים יותר הגדרות ראשוניות מאשר Secret Manager, אבל הם מאובטחים יותר מאשר יצירת סודות באשכול. כדי להגדיר כלי של צד שלישי לניהול סודות, אפשר לעיין במסמכי התיעוד של הספק. בנוסף, כדאי לשקול את ההמלצות הבאות:

    • אם הכלי של הצד השלישי פועל באשכול, צריך להשתמש באשכול אחר ולא באשכול שבו פועלות עומסי העבודה.
    • להשתמש ב-Cloud Storage או ב-Spanner כדי לאחסן את הנתונים של הכלי.
    • משתמשים במאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי כדי לחשוף את כלי ניהול הסודות של הצד השלישי ל-Pods שפועלים ברשת ה-VPC.

  • שימוש ב-Kubernetes Secrets (לא מומלץ): אם אף אחת מהאפשרויות הקודמות לא מתאימה לתרחיש השימוש שלכם, אתם יכולים לאחסן את הנתונים כ-Kubernetes Secrets. ‫Cloud de Confiance הצפנת נתונים בשכבת האחסון כברירת מחדל. ההצפנה הזו בשכבת האחסון כוללת את מסד הנתונים שבו נשמר המצב של האשכול, שמבוסס על etcd או על Spanner. בנוסף, אתם יכולים להצפין את הסודות האלה בשכבת האפליקציה באמצעות מפתח שאתם מנהלים. מידע נוסף זמין במאמר בנושא הצפנת סודות בשכבת האפליקציה.

אבטחת עומסי עבודה

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

שיטות מומלצות

בידוד עומסי עבודה באמצעות GKE Sandbox

מומלץ: להשתמש ב-GKE Sandbox כדי למנוע מקוד זדוני להשפיע על ליבת המארח בצמתי האשכול.

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

אפשר להשתמש ב-GKE Sandbox בתרחישים כמו:

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

מידע נוסף זמין במאמר הקשחת הבידוד של עומסי עבודה באמצעות GKE Sandbox.

הגבלת הגישה לעומסי עבודה באמצעות RBAC

מומלץ: לתכנן ולהטמיע כללי מדיניות טובים של RBAC כדי לצמצם את הסיכון לגישה לא מורשית לעומסי עבודה.

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

אכיפה מבוססת-מדיניות

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

שיטות מומלצות

אכיפת כללי מדיניות בהיררכיית המשאבים Cloud de Confiance

מומלץ: כדי לאכוף שיטות אבטחה בארגון, בתיקייה או בפרויקט, כדאי להשתמש בOrganization Policy Service.

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

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

אכיפת מדיניות במהלך קבלת עומסי עבודה

מומלץ: להשתמש בבקר אישור בקשות כמו Policy Controller או בבקר אישור הבקשות PodSecurity כדי לבדוק בקשות API נכנסות ולאכוף מדיניות על הבקשות האלה.

בקרי קבלה מיירטים בקשות מאומתות ומורשות ל-Kubernetes API כדי לבצע משימות אימות או שינוי לפני שמאפשרים למשאב להישמר ב-API.

אפשר להשתמש בשיטות הבאות כדי לשלוט בגישה לאשכולות GKE:

ניהול אשכולות

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

שיטות מומלצות

שדרוג תשתית GKE באופן קבוע

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

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

כדי לוודא שבאשכול GKE שלכם פועלת גרסה עדכנית, צריך לבצע את הפעולות הבאות:

  • מצרפים את האשכולות לערוץ הפצה. אשכולות במצב Autopilot תמיד רשומים בערוץ הפצה.
  • לשם כך, אם האשכולות נמצאים בערוץ הפצה, צריך להפעיל שדרוגים אוטומטיים מואצים של תיקוני אבטחה כדי לקבל גרסאות של תיקוני אבטחה ברגע שהן זמינות בערוץ ההפצה.
  • לגבי אשכולות רגילים שלא נמצאים בערוץ הפצה, מפעילים שדרוגים אוטומטיים של צמתים. השדרוג האוטומטי של הצמתים מופעל כברירת מחדל באשכולות שנוצרו באמצעותCloud de Confiance המסוף מאז יוני 2019, ובאשכולות שנוצרו באמצעות GKE API החל מ-11 בנובמבר 2019.
  • אם אתם משתמשים במדיניות תחזוקה, כדאי להשתמש בחלון זמן לתחזוקה כדי לאפשר ל-GKE לשדרג אוטומטית את הצמתים לפחות פעם בחודש.
  • במאגרי צמתים שלא מוגדרים בהם שדרוגים אוטומטיים של צמתים, צריך לשדרג את מאגרי הצמתים לפחות פעם בחודש לפי לוח הזמנים שלכם.
  • כדי לקבל מידע על תיקוני אבטחה, כדאי לעקוב אחרי עדכוני האבטחה הדחופים ל-GKE והערות הגרסה של GKE.

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

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

כשעלונים בנושא אבטחה זמינים ורלוונטיים לאשכול, GKE מפרסם הודעות על האירועים האלה כהודעות בנושאים של Pub/Sub שאתם מגדירים. אפשר לקבל את ההתראות האלה במינוי Pub/Sub, לשלב אותן עם שירותים של צד שלישי ולקבל התראות ב-Cloud Logging.

כדי לאכוף את ההמלצה הזו בארגון, צריך להשתמש בconstraints/container.managed.enableSecurityBulletinNotifications אילוץ מנוהל של מדיניות הארגון. כדי לבדוק את ההגבלה המנוהלת הזו במסוף Cloud de Confiance , עוברים לדף פרטי המדיניות.

מעבר אל פרטי המדיניות

הגדרה של איסוף יומנים

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

אשכולות GKE שולחים יומנים ספציפיים ל-Google Cloud Observability. אפשר גם להגדיר איסוף של סוגים נוספים של יומנים. בנוסף ליומני המערכת והעומס, כל אשכולות GKE שולחים את יומני הביקורת הבאים אל Logging:

  • יומני ביקורת של Kubernetes: רשומה כרונולוגית של קריאות שבוצעו לשרת Kubernetes API. רשומות ביומן ביקורת של Kubernetes שימושיות לחקירת בקשות חשודות ל-API, לאיסוף נתונים סטטיסטיים או ליצירת התראות למעקב אחרי קריאות לא רצויות ל-API.
  • יומני ביקורת של GKE: תיעוד של פעילויות אדמין ופעילויות גישה ל-GKE API.

מידע נוסף זמין במאמרים הבאים:

כדי לאכוף את ההמלצה הזו בארגון, צריך להשתמש בconstraints/container.managed.enableCloudLogging אילוץ מנוהל של מדיניות הארגון. כדי לבדוק את ההגבלה המנוהלת הזו במסוף Cloud de Confiance , עוברים לדף Policy details.

מעבר אל פרטי המדיניות

מעקב אחרי מקורות מידע כדי לאתר בעיות אבטחה

כדי לעקוב אחרי האשכולות ועומסי העבודה (workloads) שלכם ולזהות בעיות פוטנציאליות, אפשר להשתמש בלוח הבקרה של מצב האבטחה ב-GKE וב-Security Command Center. אתם יכולים להשתמש בשירותים האלה כדי לבדוק אם יש נקודות חולשה פעילות, איומים ועדכוני אבטחה שמשפיעים על התשתית של GKE.

הגדרות אבטחה שמוגדרות כברירת מחדל

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

שיטות מומלצות

השארת שיטות אימות לקוח מדור קודם מושבתות

מומלץ: להשבית שיטות אימות קודמות של שרת API, כמו אישורים סטטיים וסיסמאות.

יש כמה שיטות לאימות בשרת Kubernetes API. ב-GKE, השיטות הנתמכות הן אסימוני bearer של חשבון שירות, אסימוני OAuth ואישורי לקוח מסוג X.509. ה-CLI של gcloud משתמש בטוקנים של OAuth כדי לאמת משתמשים ב-GKE.

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

כדי לבצע אימות לשרת Kubernetes API, אפשר להשתמש באחת מהשיטות הבאות:

  • משתמשים: משתמשים ב-CLI של gcloud כדי לאפשר ל-GKE לאמת משתמשים, ליצור אסימוני גישה מסוג OAuth לאשכול ולעדכן את האסימונים.
  • אפליקציות: משתמשים באיחוד שירותי אימות הזהות של עומסי עבודה כדי לאפשר לאפליקציות ב-Cloud de Confiance או בסביבות אחרות לבצע אימות מול האשכול.

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

כדי לאכוף את ההמלצה הזו בארגון, צריך להשתמש בconstraints/container.managed.disableLegacyClientCertificateIssuance אילוץ מנוהל של מדיניות הארגון. כדי לבדוק את ההגבלה המנוהלת הזו במסוף Cloud de Confiance , עוברים לדף Policy details.

מעבר אל פרטי המדיניות

השארת ABAC מושבת

מומלץ: שימוש ב-IAM וב-RBAC כדי לשלוט בגישה ב-GKE. לא להפעיל בקרת גישה מבוססת-מאפיינים (ABAC).

ABAC היא שיטת הרשאה מדור קודם שמושבתת כברירת מחדל בכל אשכולות GKE, ואי אפשר להפעיל אותה באשכולות Autopilot.

כדי לאכוף את ההמלצה הזו בארגון, צריך להשתמש בconstraints/container.managed.disableABAC אילוץ מנוהל של מדיניות הארגון. כדי לבדוק את ההגבלה המנוהלת הזו במסוף Cloud de Confiance , עוברים לדף Policy details.

מעבר אל פרטי המדיניות

השארת אמצעי אישור הבקשות DenyServiceExternalIPs מופעל

מומלץ: לא להשבית את DenyServiceExternalIPs admission controller.

אמצעי אישור הבקשות הזה חוסם שירותים משימוש בכתובות IP חיצוניות ומצמצם את הסיכון לניצול לרעה של GCP-2020-015. אמצעי אישור הבקשות הזה מופעל כברירת מחדל באשכולות שנוצרו ב-GKE בגרסה 1.21 ואילך. באשכולות שנוצרו במקור בגרסה קודמת של GKE, צריך להפעיל את אמצעי אישור הבקשות:

gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --no-enable-service-externalips
כדי לאכוף את ההמלצה הזו בארגון, צריך להשתמש בconstraints/container.managed.denyServiceExternalIPs אילוץ מנוהל של מדיניות הארגון. כדי לבדוק את ההגבלה המנוהלת הזו במסוף Cloud de Confiance , עוברים לדף Policy details.

מעבר אל פרטי המדיניות

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