במאמר הזה מוסבר איך 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, ספקי אירוח אתרים או ארגונים אחרים שמאפשרים למשתמשים שלהם להעלות ולהריץ קוד. פגם בזמן הריצה של המאגר או בקרנל של המארח עלול לאפשר לתהליך שפועל בתוך מאגר 'לברוח' מהמאגר ולהשפיע על הקרנל של הצומת, מה שעלול לגרום להשבתת הצומת.
בנוסף, יכול להיות שדייר זדוני ינצל את הפגם הזה כדי לקבל גישה לנתונים של דייר אחר בזיכרון או בדיסק, ולשלוף אותם.
לבסוף, עומס עבודה לא מהימן עלול לגשת לשירותים אחרים או למטא-נתונים של האשכול. 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.
יחידות GPU ב-GKE Sandbox
ב-GKE גרסה 1.29.2-gke.1108000 ואילך, GKE Sandbox תומך בשימוש ביחידות GPU של NVIDIA.
GKE Sandbox לא מצליח לצמצם את כל נקודות החולשה של מנהלי ההתקנים (דרייברים) של NVIDIA, אבל הוא עדיין מספק הגנה מפני נקודות חולשה בליבת Linux. כשמשתמשים ב-GKE Sandbox, לא מומלץ להשתמש בשיתוף זמן של GPU כי ה-GPU לא מבודד באופן מלא בין ה-Pods. לפרטים על האופן שבו פרויקט gVisor מגן על עומסי עבודה של GPU, ראו מדריך התמיכה ב-GPU.
ההגבלות הבאות חלות על עומסי עבודה של GPU ב-GKE Sandbox:
- יש תמיכה רק בעומסי עבודה של CUDA.
- קבוצת משנה של מעבדי GPU שנתמכים ב-GKE נתמכים ב-GKE Sandbox. פרטים נוספים זמינים בטבלת התמיכה.
- gVisor תומך רק בגרסאות נבחרות של דרייברים של NVIDIA. GKE Sandbox מוודא שמנהל ההתקן
latestומנהל ההתקןdefaultשל כל GPU נתמך בכל גרסה של GKE תואמים. אין ערובה לכך שדרייברים אחרים יפעלו. - לא כל התכונות של ה-GPU יפעלו באופן טבעי (למשל RDMA או IMEX). תכונות GPU ייתמכו על בסיס כל מקרה לגופו, בהתאם לצורך של הלקוח. שליחת בקשת תמיכה או דיווח על באג ב-GitHub Issues של gVisor.
אפשר להשתמש ב-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 ולאשכולות רגילים
- צמתים שמריצים Pods בסביבת ארגז חול לא יכולים לגשת למטא-נתונים של האשכול ברמת מערכת ההפעלה בצומת.
- ב-GKE Standard, אפשר להריץ Pods רגילים בצומת עם GKE Sandbox מופעל. עם זאת, כברירת מחדל, ל-Pods רגילים אין גישה לשירותי Google Cloud או למטא-נתונים של האשכול.
- משתמשים ב-איחוד זהויות של עומסי עבודה ל-GKE כדי להעניק לקבוצות Pod גישה לשירותים של Google Cloud .
יכול להיות ש-SMT מושבת
רלוונטי לאשכולות במצב Autopilot ולאשכולות רגילים
הגדרות של ריבוי נימים סימולטני (SMT) משמשות לצמצום נקודות חולשה בערוצים צדדיים שמנצלות נימים שמשתפים מצב ליבה, כמו נקודות חולשה של דגימת נתונים של מיקרו-ארכיטקטורה (MDS).
בגרסאות GKE 1.25.5-gke.2500 ואילך ו-1.26.0-gke.2500 ואילך, gVisor מוגדר להשתמש ב-Linux Core Scheduling כדי לצמצם את הסיכון למתקפות ערוץ צדדי. הגדרות ה-SMT לא השתנו מברירת המחדל. תזמון ליבה משמש רק לעומסי עבודה שפועלים עם 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מוודאים שה-pods של 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מופיע ביומנים של ה-pods.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 ולאשכולות רגילים
יכול להיות שקוד לא מהימן שפועל בתוך ארגז החול יקבל הרשאה להגיע לשירותים חיצוניים כמו שרתים של מסדי נתונים, ממשקי API, מאגרי קונטיינרים אחרים ומנהלי התקנים של CSI. השירותים האלה פועלים מחוץ לגבולות של ארגז החול, ולכן צריך להגן עליהם בנפרד. תוקף יכול לנסות לנצל חולשות בשירותים האלה כדי לצאת מארגז החול. חשוב לקחת בחשבון את הסיכון וההשפעה של שירותים שאפשר להגיע אליהם באמצעות הקוד שפועל בארגז החול, וליישם את האמצעים הנדרשים כדי לאבטח אותם.
זה כולל הטמעות של מערכת קבצים עבור נפחי אחסון של קונטיינרים, כמו ext4 ומנהלי התקנים של CSI. מנהלי התקנים של CSI פועלים מחוץ לבידוד של ארגז החול, ויכולה להיות להם גישה עם הרשאות למארח ולשירותים. ניצול לרעה של מנהלי ההתקנים האלה עלול להשפיע על ליבת המארח ולפגוע בכל הצומת. מומלץ להריץ את מנהל ההתקן של CSI בתוך קונטיינר עם כמות ההרשאות המינימלית הנדרשת, כדי לצמצם את החשיפה במקרה של ניצול לרעה. GKE Sandbox תומך בשימוש במנהל ההתקן של ה-CSI של אחסון מתמיד (persistent disk) ב-Compute Engine.
תכונות לא תואמות
אי אפשר להשתמש ב-GKE Sandbox עם התכונות הבאות של Kubernetes:
- מדדי שימוש בזיכרון ברמת הקונטיינר. עם זאת, יש תמיכה בשימוש בזיכרון של Pod.
- אחסון בנתיב המארח
- הגבלות על מעבד וזיכרון חלות רק על 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 ולאשכולות רגילים
הוספת שכבת הפניה עקיפה לגישה לליבת הצומת כרוכה בפשרות בנוגע לביצועים. היתרון המוחשי ביותר של GKE Sandbox הוא באשכולות גדולים עם מספר דיירים שבהם הבידוד חשוב. כשבודקים את עומסי העבודה באמצעות GKE Sandbox, חשוב לזכור את ההנחיות הבאות.
שיחות מערכת
רלוונטי לאשכולות במצב Autopilot ולאשכולות רגילים
עומסי עבודה שמייצרים נפח גדול של קריאות מערכת עם תקורה נמוכה, כמו מספר גדול של פעולות קלט/פלט קטנות, עשויים לדרוש יותר משאבי מערכת כשהם פועלים בארגז חול. לכן, יכול להיות שתצטרכו להשתמש בצמתים חזקים יותר או להוסיף צמתים נוספים לאשכול.
גישה ישירה לחומרה או לווירטואליזציה
רלוונטי לאשכולות במצב Autopilot ולאשכולות רגילים
אם עומס העבודה שלכם צריך את אחד מהדברים הבאים, יכול להיות ש-GKE Sandbox לא מתאים לכם כי הוא מונע גישה ישירה לליבת המארח בצומת:
- גישה ישירה לחומרה של הצומת
- תכונות וירטואליזציה ברמת הליבה
- מאגרי תגים עם הרשאות מיוחדות