במאמר הזה מוסבר איך GKE Sandbox מגן על ליבת המארח בצמתים כשקונטיינרים ב-Pod מריצים קוד לא מוכר או לא מהימן. במסמך הזה אנחנו יוצאים מנקודת הנחה שאתם מכירים את הנושאים הבאים:
- gVisor, פרויקט הקוד הפתוח שמשמש את GKE Sandbox.
המסמך הזה מיועד למומחי אבטחה שרוצים ללמוד על היתרונות של GKE Sandbox. מידע נוסף על תפקידים נפוצים ומשימות לדוגמה שאנחנו מתייחסים אליהם ב Google Cloud תוכן, זמין במאמר תפקידים נפוצים של משתמשים ומשימות ב-GKE.
אתם יכולים להשתמש ב-GKE Sandbox כשאתם מריצים אשכולות מרובי דיירים, כי ספקי תוכנה כשירות (SaaS) מריצים לעיתים קרובות קוד לא מוכר שנשלח על ידי המשתמשים שלהם. GKE Sandbox הוא גם אמצעי הגנה שימושי להפעלת קונטיינרים בעלי ערך גבוה.
במאמר הגדרת GKE Sandbox מוסבר איך להפעיל את GKE Sandbox ואיך להשתמש בו.
סקירה כללית
GKE Sandbox מספק שכבת אבטחה נוספת כדי למנוע מקוד לא מהימן להשפיע על ליבת המארח בצמתי האשכול. לפני שנסביר איך פועל GKE Sandbox, כדאי להבין את האופי של הסיכונים הפוטנציאליים שהוא עוזר לצמצם.
זמן ריצה של קונטיינר, כמו containerd, מספק מידה מסוימת של בידוד בין התהליכים של הקונטיינר לבין ליבת המערכת שפועלת בצומת.
עם זאת, זמן הריצה של הקונטיינר פועל לעיתים קרובות כמשתמש עם הרשאות בצומת, ויש לו גישה לרוב קריאות המערכת לליבת המארח.
איומים פוטנציאליים
מקבצי מולטי-דיירים ומקבצים שהקונטיינרים שלהם מריצים עומסי עבודה לא מהימנים חשופים יותר לנקודות חולשה באבטחה בהשוואה למקבצים אחרים. דוגמאות: ספקי SaaS, ספקי אירוח אתרים או ארגונים אחרים שמאפשרים למשתמשים שלהם להעלות ולהריץ קוד. פגם בזמן הריצה של המאגר או בקרנל של המארח עלול לאפשר לתהליך שפועל בתוך מאגר 'לברוח' מהמאגר ולהשפיע על הליבה (kernel) של הצומת, מה שעלול לגרום להשבתת הצומת.
בנוסף, יכול להיות שדייר זדוני ינצל את הפגם הזה כדי לקבל גישה לנתונים של דייר אחר בזיכרון או בדיסק, ולשלוף אותם.
לבסוף, עומס עבודה לא מהימן עלול לגשת לשירותים אחרים או למטא-נתונים של האשכול. Google Cloud
איך GKE Sandbox מצמצם איומים פוטנציאליים
gVisor הוא הטמעה מחדש של Linux kernel API במרחב המשתמש, שלא דורשת הרשאות מורחבות. בנוסף לזמן ריצה של קונטיינר כמו containerd , ליבת מרחב המשתמשים מטמיעה מחדש את רוב קריאות המערכת ומטפלת בהן בשם ליבת המארח. הגישה הישירה לליבת המארח מוגבלת. במדריך לארכיטקטורה של gVisor מוסבר איך זה עובד. מנקודת המבט של הקונטיינר, gVisor כמעט שקוף ולא דורש שינויים באפליקציה בקונטיינרים.
כשמבקשים GKE Sandbox ב-Pod באשכולות Autopilot, GKE מפעיל את ה-Pod הזה בארגז חול. ב-GKE Standard, אם מפעילים את GKE Sandbox בצמתים, כל ה-Pods שפועלים בצמתים האלה פועלים בארגזי חול.
כל ארגז חול משתמש בקרנל משלו במרחב המשתמש. בהתאם לכך, אתם יכולים להחליט איך לקבץ את הקונטיינרים שלכם ל-Pods, על סמך רמת הבידוד שאתם צריכים והמאפיינים של האפליקציות שלכם.
GKE Sandbox מתאים במיוחד לסוגי האפליקציות הבאים. מידע נוסף שיעזור לכם להחליט אילו אפליקציות להפעיל בסביבת ארגז חול זמין במאמר מגבלות.
- אפליקציות לא מהימנות או אפליקציות של צד שלישי שמשתמשות בסביבות זמן ריצה כמו Rust, Java, Python, PHP, Node.js או Golang
- חזיתות קצה, מטמונים או שרתי proxy של שרתי אינטרנט
- אפליקציות שמעבדות מדיה או נתונים חיצוניים באמצעות מעבדים
- עומסי עבודה של למידת מכונה באמצעות מעבדים
- אפליקציות שדורשות הרבה משאבי מעבד או זיכרון
עומסי עבודה או שירותים של AI/ML דורשים לעיתים קרובות פריסה מהירה יותר בסביבת ייצור. gVisor נועד להגן מפני סוגים שלמים של נקודות חולשה נפוצות ב-Linux. עם GKE Sandbox, אתם יכולים לשפר את רמת האבטחה של עומסי עבודה עתירי GPU ו-TPU בלי לבצע שינויים משמעותיים בקוד. תרחישי שימוש מרכזיים שבהם GKE Sandbox מתאים במיוחד הם תרחישים שמשותפים לעומסי עבודה של AI/ML:
- עומסי עבודה שדורשים שימוש אינטנסיבי במעבדי GPU ו-TPU.
- שירותים שמקבלים ומריצים קוד משתמש לא מהימן.
- שירותים שמבצעים עיבוד של קלט שרירותי מהמשתמשים.
- עומסי עבודה שמעבדים מערכי נתונים ומודלים גדולים של צד שלישי.
- אפליקציות שמשתמשות בספריות של צד שלישי.
מידע נוסף על התכנון והאבטחה של גישה למאיצים זמין במדריכים בנושא GPU ו-TPU ב-gVisor.
המלצות נוספות בנושא אבטחה
כשמשתמשים ב-GKE Sandbox, מומלץ לפעול גם לפי ההמלצות הבאות:
מציינים מגבלות משאבים בכל הקונטיינרים שפועלים בסביבת ארגז חול. כך מתגוננים מפני הסיכון שאפליקציה פגומה או זדונית תגרום למחסור במשאבים בצומת ותשפיע באופן שלילי על אפליקציות אחרות או על תהליכי מערכת שפועלים בצומת.
אם אתם משתמשים באיחוד זהויות של עומסי עבודה ל-GKE, אתם יכולים לחסום גישה למטא-נתונים של האשכול באמצעות מדיניות רשת כדי לחסום גישה אל
169.254.169.254. ההגנה הזו מונעת את הסיכון שאפליקציה זדונית תגשת למידע, כולל נתונים פרטיים כמו מזהה פרויקט, שם צומת ואזור. איחוד זהויות של עומסי עבודה ל-GKE תמיד מופעל באשכולות GKE Autopilot.
מגבלות
GKE Sandbox פועל היטב עם הרבה אפליקציות, אבל לא עם כולן. בקטע הזה מופיע מידע נוסף על המגבלות הנוכחיות של GKE Sandbox.
יחידות GPU ב-GKE Sandbox
ב-GKE גרסה 1.29.2-gke.1108000 ואילך, GKE Sandbox תומך בשימוש ביחידות GPU של NVIDIA.
GKE Sandbox לא מצליח לצמצם את כל נקודות החולשה בדרייברים של NVIDIA, אבל הוא עדיין מספק הגנה מפני נקודות חולשה בליבת Linux. לפרטים על האופן שבו פרויקט gVisor מגן על עומסי עבודה של GPU, ראו מדריך התמיכה ב-GPU.
המגבלות הבאות חלות על עומסי עבודה של GPU ב-GKE Sandbox:
- יש תמיכה רק בעומסי עבודה של CUDA.
- קבוצת משנה של GPU שנתמכים ב-GKE נתמכים ב-GKE Sandbox. פרטים נוספים זמינים בטבלת התמיכה.
- gVisor תומך רק בגרסאות נבחרות של דרייברים של NVIDIA. GKE Sandbox מוודא שמנהל ההתקן
latestומנהל ההתקןdefaultשל כל GPU נתמך בכל גרסה של GKE תואמים. אין ערובה לכך שדרייברים אחרים יפעלו. - לא כל התכונות של ה-GPU יפעלו באופן טבעי (למשל RDMA או IMEX). תכונות GPU ייתמכו על בסיס כל מקרה לגופו, בהתאם לצורכי הלקוח. שליחת בקשת תמיכה או דיווח על באג ב-gVisor's GitHub Issues.
אפשר להשתמש ב-GKE Sandbox עם עומסי עבודה של GPU ללא עלות נוספת.
תמיכה בדגמי GPU ב-GKE Sandbox
בטבלה הבאה מתוארת התמיכה בדגמי GPU שונים ב-GKE Sandbox:
| דגם | תצוגה מקדימה | תמיכה ב-GA | הערות |
|---|---|---|---|
|
|
|
- | - |
|
|
|
- | - |
|
|
- |
|
נתמך מאז ההשקה הראשונית. |
|
|
לא נתמך | לא נתמך | הכרטיסים V100 ו-P100 משתמשים במנהלי התקנים קנייניים ולא נתמכים. |
|
|
- | - | GKE Sandbox לא תומך בסוגי צמתים של Windows או Ubuntu, שנדרשים לצמתים של תחנות עבודה וירטואליות. |
מעבדי TPU ב-GKE Sandbox
ב-GKE גרסה 1.31.3-gke.1111001 ואילך, GKE Sandbox תומך בשימוש ב-TPU.
GKE Sandbox לא מפחית את כל נקודות החולשה של מנהלי התקנים של TPU, אבל הוא עדיין מספק הגנה מפני נקודות חולשה של ליבת Linux. לפרטים על האופן שבו פרויקט gVisor מגן על עומסי עבודה של TPU, ראו מדריך התמיכה ב-TPU.
אלו גרסאות החומרה של TPU שנתמכות: V4pod, V4lite, V5litepod, V5pod ו-V6e.
אתם יכולים להשתמש ב-GKE Sandbox עם עומסי עבודה של TPU ללא עלות נוספת.
הגדרת מאגר צמתים
רלוונטי לאשכולות רגילים
- אי אפשר להשתמש ב-GKE Sandbox במאגרי צמתים של Windows Server.
- אי אפשר להפעיל את GKE Sandbox במאגר הצמתים שמוגדר כברירת מחדל כדי להפריד בין שירותי המערכת שפועלים במאגר הצמתים שמוגדר כברירת מחדל לבין עומסי עבודה לא מהימנים באמצעות GKE Sandbox.
- כשמשתמשים ב-GKE Sandbox, באשכול צריכים להיות לפחות שני מאגרי צמתים. תמיד צריך להיות לפחות מאגר צמתים אחד שבו GKE Sandbox מושבת. מאגר הצמתים הזה צריך להכיל לפחות צומת אחד, גם אם כל עומסי העבודה שלכם נמצאים בארגז חול.
- גרסאות GKE קודמות ל-1.24.2-gke.300 לא תומכות בסוגי המכונות e2-micro, e2-small ו-e2-medium. GKE גרסה 1.24.2-gke.300 ואילך תומכות בסוגי המכונות האלה.
- הצמתים צריכים להשתמש בתמונת הצומת מערכת הפעלה שמותאמת לקונטיינרים עם containerd (
cos_containerd).
גישה למטא-נתונים של האשכול
רלוונטי לאשכולות Autopilot ו-Standard
- לצמתים שמופעלים בהם Pods בתוך ארגז חול אין גישה למטא-נתונים של האשכול ברמת מערכת ההפעלה בצומת.
- ב-GKE Standard, אפשר להריץ Pods רגילים בצומת שבו מופעל GKE Sandbox. עם זאת, כברירת מחדל, ל-Pods רגילים אין גישה לשירותי Google Cloud או למטא-נתונים של האשכול.
- משתמשים ב-איחוד זהויות של עומסי עבודה ל-GKE כדי להעניק לקבוצות Pod גישה לשירותים של Google Cloud .
יכול להיות ש-SMT מושבת
רלוונטי לאשכולות Autopilot ו-Standard
הגדרות של ריבוי נימים סימולטני (SMT) משמשות לצמצום נקודות חולשה בערוצים צדדיים שמנצלות נימים שמשתפים מצב ליבה, כמו נקודות חולשה של דגימת נתונים של מיקרו-ארכיטקטורה (MDS).
בגרסאות GKE 1.25.5-gke.2500 ואילך ו-1.26.0-gke.2500 ואילך, gVisor מוגדר להשתמש ב-Linux Core Scheduling כדי לצמצם את הסיכון למתקפות בערוץ צדדי. הגדרות ה-SMTP לא השתנו מברירת המחדל. תזמון ליבה משמש רק לעומסי עבודה שפועלים עם gVisor.
החל מגרסה 1.24.2-gke.300 של GKE, SMT מוגדר לפי סוג המכונה, בהתאם למידת הפגיעות של המכונה ל-MDS, באופן הבא:
Pods של Autopilot שפועלים בסוג המחשוב
Scale-Out: התכונה SMT מושבתת.סוגי מכונות עם מעבדי Intel: ההגדרה SMT מושבתת כברירת מחדל.
סוגי מכונות ללא מעבדי Intel: SMT מופעל כברירת מחדל.
סוגי מכונות עם ת'רד אחד בלבד לכל ליבה: אין תמיכה ב-SMT. כל המעבדים הווירטואליים המבוקשים מוצגים.
לפני גרסה 1.24.2-gke.300, SMT מושבת בכל סוגי המכונות.
הפעלת SMT
רלוונטי לאשכולות רגילים
באשכולות GKE Standard, אפשר להפעיל SMT אם הוא מושבת בסוג המכונה שנבחר. אתם מחויבים על כל vCPU, בלי קשר להפעלה או להשבתה של SMT. למידע על תמחור, אפשר לעיין בתמחור של Compute Engine.
GKE גרסה 1.24.2-gke.300 ואילך
מגדירים את הדגל --threads-per-core כשיוצרים מאגר צמתים של GKE Sandbox:
gcloud container node-pools create smt-enabled \
--cluster=CLUSTER_NAME \
--location=LOCATION \
--machine-type=MACHINE_TYPE \
--threads-per-core=2 \
--sandbox type=gvisor
-
CLUSTER_NAME: השם של אשכול קיים שבו רוצים ליצור את מאגר הצמתים החדש. -
LOCATION: האזור או התחום של Compute Engine שבו נמצא האשכול. -
MACHINE_TYPE: סוג המכונה.
מידע נוסף על --threads-per-core זמין במאמר הגדרת מספר ה-threads לכל ליבה.
גרסאות GKE לפני 1.24.2-gke.300
יוצרים מאגר צמתים חדש באשכול עם תווית הצומת
cloud.google.com/gke-smt-disabled=false:gcloud container node-pools create smt-enabled \ --cluster=CLUSTER_NAME \ --location=LOCATION \ --machine-type=MACHINE_TYPE \ --node-labels=cloud.google.com/gke-smt-disabled=false \ --image-type=cos_containerd \ --sandbox type=gvisorמחליפים את מה שכתוב בשדות הבאים:
-
CLUSTER_NAME: השם של אשכול קיים שבו רוצים ליצור את מאגר הצמתים החדש. -
LOCATION: האזור או התחום של Compute Engine שבו נמצא האשכול. -
MACHINE_TYPE: סוג המכונה.
-
פורסים את DaemonSet למאגר הצמתים. ה-DaemonSet יפעל רק בצמתים עם התווית
cloud.google.com/gke-smt-disabled=false.kubectl create -f \ https://raw.githubusercontent.com/GoogleCloudPlatform/k8s-node-tools/master/disable-smt/gke/enable-smt.yamlמוודאים שהפודים של DaemonSet נמצאים במצב פעיל.
kubectl get pods --selector=name=enable-smt -n kube-systemהפלט אמור להיראות כך:
NAME READY STATUS RESTARTS AGE enable-smt-2xnnc 1/1 Running 0 6mבודקים אם
SMT has been enabledמופיע ביומנים של הפודים.kubectl logs enable-smt-2xnnc enable-smt -n kube-system
יכולות
רלוונטי לאשכולות רגילים
כברירת מחדל, המאגר לא יכול לפתוח שקעים גולמיים, כדי לצמצם את הפוטנציאל להתקפות זדוניות. כלים מסוימים שקשורים לרשת, כמו ping ו-tcpdump, יוצרים שקעי RAW כחלק מהפעולה הבסיסית שלהם. כדי להפעיל raw sockets, צריך להוסיף במפורש את היכולת NET_RAW להקשר האבטחה של הקונטיינר:
spec:
containers:
- name: my-container
securityContext:
capabilities:
add: ["NET_RAW"]
אם אתם משתמשים ב-GKE Autopilot, Google Cloud לא תוכלו להוסיף את ההרשאה NET_RAW לקונטיינרים בגלל ההשלכות על האבטחה של היכולת הזו.
יחסי תלות חיצוניים
רלוונטי לאשכולות Autopilot ו-Standard
יכול להיות שקוד לא מהימן שפועל בתוך ארגז החול יקבל הרשאה לגשת לשירותים חיצוניים כמו שרתים של מסדי נתונים, ממשקי API, קונטיינרים אחרים ומנהלי התקנים של CSI. השירותים האלה פועלים מחוץ לגבולות של ארגז החול, ולכן צריך להגן עליהם בנפרד. תוקף יכול לנסות לנצל חולשות בשירותים האלה כדי לפרוץ את ארגז החול. חשוב לקחת בחשבון את הסיכון וההשפעה של שירותים שאפשר להגיע אליהם באמצעות הקוד שפועל בארגז החול, וליישם את האמצעים הנדרשים כדי לאבטח אותם.
זה כולל יישומי מערכת קבצים לנפחי אחסון של קונטיינרים כמו ext4 ומנהלי התקנים של CSI. מנהלי התקנים של CSI פועלים מחוץ לבידוד של ארגז החול, ויכול להיות שיש להם גישה עם הרשאות למארח ולשירותים. ניצול לרעה של נקודת חולשה במנהלי ההתקנים האלה יכול להשפיע על ליבת המארח ולפגוע בכל הצומת. כדי לצמצם את החשיפה במקרה של ניצול לרעה, מומלץ להריץ את מנהל ההתקן של CSI בתוך קונטיינר עם כמות ההרשאות המינימלית הנדרשת. GKE Sandbox תומך בשימוש במנהל ההתקן של ה-CSI של אחסון מתמיד (persistent disk) ב-Compute Engine.
תכונות לא תואמות
אי אפשר להשתמש ב-GKE Sandbox עם התכונות הבאות של Kubernetes:
- מדדי השימוש בזיכרון ברמת הקונטיינר. עם זאת, יש תמיכה בשימוש בזיכרון של Pod.
- אחסון ב-Hostpath
- הגבלות על מעבד וזיכרון חלות רק על Guaranteed Pods ו-Burstable Pods, ורק אם מציינים הגבלות על מעבד וזיכרון לכל הקונטיינרים שפועלים ב-Pod.
- קונטיינרים שפועלים במצב הרשאות
- VolumeDevices
- Portforward
- מודולי אבטחה של ליבת Linux, כמו Seccomp, Apparmor או Selinux, Sysctl,
NoNewPrivileges, bidirectional MountPropagation או ProcMount. FSGroup נתמך ב-GKE מגרסה 1.22 ואילך.
אין תמיכה ב-Cloud Service Mesh עבור Pods של GKE Sandbox באשכולות Autopilot.
מאפיינים של עומס העבודה
רלוונטי לאשכולות Autopilot ו-Standard
הוספה של שכבת הפניה עקיפה נוספת לגישה לליבת הצומת כרוכה בפשרות בנוגע לביצועים. היתרון המוחשי ביותר של GKE Sandbox הוא באשכולות גדולים עם מספר דיירים שבהם הבידוד חשוב. כשבודקים את עומסי העבודה באמצעות GKE Sandbox, חשוב לזכור את ההנחיות הבאות.
שיחות מערכת
רלוונטי לאשכולות Autopilot ו-Standard
עומסי עבודה שמייצרים נפח גדול של קריאות מערכת עם תקורה נמוכה, כמו מספר גדול של פעולות קלט/פלט קטנות, עשויים לדרוש יותר משאבי מערכת כשהם פועלים בארגז חול. לכן, יכול להיות שתצטרכו להשתמש בצמתים חזקים יותר או להוסיף צמתים נוספים לאשכול.
גישה ישירה לחומרה או לווירטואליזציה
רלוונטי לאשכולות Autopilot ו-Standard
אם עומס העבודה שלכם צריך את אחד מהדברים הבאים, יכול להיות ש-GKE Sandbox לא מתאים לכם כי הוא מונע גישה ישירה לליבת המארח בצומת:
- גישה ישירה לחומרה של הצומת
- תכונות וירטואליזציה ברמת הליבה
- מאגרי תגים עם הרשאות מיוחדות