GKE Sandbox

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

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

מידע על הרצה בארגז חול (sandboxing) ב-GKE

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

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

איומים פוטנציאליים

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

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

טכנולוגיות ארגז החול שבהן נעשה שימוש ב-GKE Sandbox עוזרות לצמצם את ההשפעה הפוטנציאלית הבאה של יציאה מקונטיינר:

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

טכנולוגיות של ארגז חול ב-GKE

ב-GKE Sandbox יש תמיכה בטכנולוגיות הבאות של ארגזי חול, שכל אחת מהן משתמשת בגישה שונה לבידוד עומסי עבודה ומתאימה לתרחישי שימוש שונים:

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

  • MicroVMs מכונות וירטואליות קלות משקל שמריצות ליבת Linux מלאה ומערכת הפעלה. כל Pod פועל ב-microVM משלו, שמספק בידוד קפדני מ-Pods אחרים ומצומת המארח. ב-GKE Sandbox נעשה שימוש בתוכנת הקוד הפתוח Kata Containers ובצג המכונה הווירטואלית (VMM) של Cloud Hypervisor כדי ליצור ולנהל מכונות microVM.

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

gVisor MicroVMs
גישה לליבה קבוצת משנה של קריאות מערכת (syscalls) של ליבת Linux ליבת Linux מלאה
רמת הבידוד יירוט של קריאות מערכת בקרנל של מרחב משתמש וירטואליזציה מלאה של החומרה עם ליבת אורח ייעודית
תקורה של מעבד (CPU) וזיכרון תקורה דינמית עם זיכרון בסיסי נמוך לליבת מרחב המשתמש תקורה קבועה של 250 mCPU ו-130 MiB של זיכרון לכל Pod
שעת התחלה פחות מ-200 אלפיות השנייה בערך שנייה אחת עד שתי שניות
הגדרת צומת ב-GKE זמין בכל מאגרי הצמתים הרגילים ובצמתים של Autopilot. מופעל כברירת מחדל באשכולות Autopilot. האפשרות הזו זמינה רק בצמתים שמאפשרים וירטואליזציה בתצורה מקוננת.
תמיכה בתמונות של צמתים מערכת הפעלה שמותאמת לקונטיינרים בלבד מערכת הפעלה שמותאמת לקונטיינרים או Ubuntu
תאימות לסוג המכונה נתמך על ידי רוב המעבדים, ארכיטקטורת Arm וסוגי מכונות להאצת למידת מכונה. התכונה נתמכת רק בסוגי מכונות שתומכים בווירטואליזציה מקוננת.
תמיכה במאיצים תמיכה בדגמי GPU ספציפיים ובגרסאות TPU. אין תמיכה במעבדי GPU או TPU.
מאגרי תגים עם הרשאות מיוחדות לא נתמך. יש תמיכה. קונטיינרים עם הרשאות מקבלים גישת root רק למערכת ההפעלה של האורח ב-microVM, ולא למארח.
תרחישים לדוגמה
  • אפליקציות לא מהימנות או אפליקציות של צד שלישי שמשתמשות בסביבות זמן ריצה כמו Rust,‏ Java,‏ Python,‏ PHP,‏ Node.js או Golang
  • חזיתות, מטמונים או שרתי proxy של שרתי אינטרנט
  • אפליקציות שמעבדות מדיה או נתונים חיצוניים באמצעות מעבדי CPU
  • עומסי עבודה שדורשים הרבה משאבי GPU ו-TPU
  • עומסי עבודה של הסקת מסקנות באמצעות AI שמעבדים קלט שרירותי או מריצים קוד
  • עומסי עבודה של אימון שמעבדים מערכי נתונים ומודלים גדולים של צד שלישי
  • סוכני AI שמייצרים ומריצים קוד ללא פיקוח
  • קוד אוטונומי שפועל בדפדפנים, כמו Puppeteer
  • עומסי עבודה שזקוקים לגישה לליבת Linux מלאה
  • עומסי עבודה (workloads) שמייצרים נפח גבוה של קריאות למערכת עם תקורה נמוכה, כמו מספר גדול של פעולות קלט/פלט קטנות

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

איך שולחים בקשות לארגזי חול

כדי להריץ אפליקציה בסביבת ארגז חול:

  1. מפעילים טכנולוגיית ארגז חול בצמתים באמצעות ComputeClasses כדי ליצור את הצמתים באופן אוטומטי, או באמצעות יצירה ידנית של מאגרי צמתים.
  2. מבקשים ארגז חול לפודים באמצעות ה-RuntimeClass המתאים לסוג ארגז החול, כמו gvisor או microvm. מידע נוסף זמין במאמר הגברת הבידוד של עומסי עבודה באמצעות GKE Sandbox.

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

המלצות נוספות בנושא אבטחה

כשמשתמשים ב-GKE Sandbox, מומלץ גם לפעול לפי ההמלצות הבאות:

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

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

מגבלות

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

מעבדי GPU ב-GKE Sandbox

אפשר להריץ עומסי עבודה של GPU בארגזי חול באמצעות gVisor. ‏gVisor לא מפחית את כל נקודות החולשה של מנהלי ההתקנים (דרייברים) של NVIDIA, אבל הוא שומר על ההגנה מפני נקודות חולשה של ליבת Linux. אל תשתמשו בשיתוף זמן של GPU בתרמילי Pods בסביבת ארגז חול, כי ה-GPU לא מבודד באופן מלא בין תרמילי ה-Pods. מידע נוסף על האופן שבו gVisor מגן על עומסי עבודה של GPU זמין במדריך לתמיכה ב-GPU.

המגבלות הבאות חלות על עומסי עבודה של GPU ב-GKE Sandbox:

  • אין תמיכה ב-GPU במכונות וירטואליות מיקרו.
  • ב-gVisor, חלות המגבלות הבאות:
    • יש תמיכה רק בעומסי עבודה של CUDA.
    • המערכת תומכת רק בחלק מדגמי ה-GPU הזמינים. מידע נוסף זמין במאמר בנושא תמיכה בדגמי GPU.
    • בכל גרסה של GKE יש תמיכה רק בגרסאות latest ו-default של מנהל ההתקן של NVIDIA. יכול להיות שגרסאות אחרות של מנהלי ההתקנים לא יפעלו.
    • לא כל התכונות של ה-GPU נתמכות, כמו RDMA או IMEX. בהתאם לצרכים של הלקוחות, יכול להיות ש-gVisor יתמוך בתכונות ספציפיות במקרים מסוימים. כדי לבקש תמיכה בתכונה ספציפית, אפשר לפתוח בקשת תמיכה או להגיש בקשה להוספת תכונה ב-gVisor.

תמיכה בדגמי GPU

בטבלה הבאה מתוארת התמיכה בדגמי GPU שונים ב-GKE Sandbox:

דגם תצוגה מקדימה תמיכה ב-GA הערות
  • NVIDIA RTX PRO 6000
    		•
  • סוגי מכונות עם GPU אחד או יותר: 1.34.1-gke.2037001 ואילך
  • סוגי מכונות עם פחות מ-GPU אחד: לא נתמכים
    		• - -
  • NVIDIA GB200
  • NVIDIA B200
  • NVIDIA H200 141GB
    		•
  • ‫1.34.0-gke.1713000 ואילך
    		•  - -
  • NVIDIA H100 80GB
  • NVIDIA A100 80GB
  • NVIDIA A100 40GB
  • NVIDIA L4
  • NVIDIA T4
    		•  -
  • ‫1.29.15-gke.1134000 ואילך
  • ‫1.30.11-gke.1093000 ואילך
  • ‫1.31.7-gke.1149000 ואילך
  • ‫1.32.2-gke.1182003 ואילך
    		•  נתמך מאז ההשקה הראשונית.
  • NVIDIA V100
  • ‫NVIDIA P100 (מתקרב לסיום התמיכה)
    		•  לא נתמך לא נתמך הכרטיסים V100 ו-P100 משתמשים במנהלי התקנים קנייניים ולא נתמכים.
  • NVIDIA T4 VWS
  • NVIDIA L4 VWS
    		•  - - ‫GKE Sandbox לא תומך בסוגי צמתים של Windows או Ubuntu, שנדרשים לצמתים של תחנות עבודה וירטואליות.

    יחידות TPU בארגז החול של GKE

    ב-GKE בגרסה 1.31.3-gke.1111001 ואילך, אפשר להריץ עומסי עבודה של TPU בארגזי חול באמצעות gVisor. ‏gVisor לא מצמצם את כל נקודות החולשה של מנהל ההתקן של TPU, אבל הוא שומר על ההגנה מפני נקודות חולשה בליבת Linux. מידע נוסף על האופן שבו פרויקט gVisor מגן על עומסי עבודה של TPU זמין במדריך התמיכה ב-TPU.

    המגבלות הבאות חלות על עומסי עבודה של TPU ב-GKE Sandbox:

    • מכונות מיקרו וירטואליות לא תומכות ב-TPU.

    • ‫gVisor תומך בגרסאות הבאות של TPU:

      • V4pod
      • V4lite
      • V5litepod
      • V5pod
      • V6e

    הגדרת הצומת

    ההגבלות הבאות חלות על הצמתים שמשתמשים ב-GKE Sandbox:

    • ‫gVisor ו-microVMs תומכים רק בצומתי Linux. לא ניתן להשתמש בצמתים של Windows Server.
    • ‫gVisor תומך רק בתמונת הצומת של מערכת הפעלה שמותאמת לקונטיינרים. מכונות מיקרו-וירטואליות תומכות בתמונות צמתים של מערכת הפעלה שמותאמת לקונטיינרים ושל Ubuntu.
    • כדי להשתמש ב-MicroVMs, צריך להפעיל וירטואליזציה מקוננת בצמתים. כל הדרישות והמגבלות של וירטואליזציה מקוננת חלות.
    • באשכולות Standard, אי אפשר להפעיל את GKE Sandbox במאגר ברירת המחדל של הצמתים. באשכול חייב להיות תמיד לפחות מאגר צמתים אחד שלא משתמש ב-GKE Sandbox. מאגר הצמתים הזה צריך להכיל לפחות צומת אחד, גם אם כל עומסי העבודה שלכם נמצאים בארגז חול. ההגבלה הזו קיימת כדי להפריד בין שירותי המערכת לבין עומסי עבודה לא מהימנים.

    גישה למטא-נתונים של האשכול

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

    המגבלה הזו לא חלה על סוג ארגז החול microVM. כדי למנוע גישה למטא-נתונים של אשכולות מפודים ב-microVM, משתמשים ב-NetworkPolicy שדוחה תעבורת נתונים יוצאת אל 169.254.169.252/32 ביציאה 988, או באשכולות שמשתמשים ב-GKE Dataplane V2, אל 169.254.169.254/32 ביציאה 80.

    יכול להיות ש-SMT מושבת

    הגדרות של Simultaneous multithreading ‏(SMT, שנקרא גם Hyper-Threading במעבדי Intel) משמשות לצמצום נקודות חולשה בערוצים צדדיים שמנצלות שרשורים שמשתפים מצב ליבה, כמו נקודות חולשה של דגימת נתונים של מיקרו-ארכיטקטורה (MDS).

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

    הגדרת ברירת המחדל של SMT או Hyper-Threading לסוג מכונה תלויה במידת הפגיעות של המכונה ל-MDS, באופן הבא:

    • ‫Pods של Autopilot שמשתמשים ב-Scale-Out ComputeClass: התכונה SMT תמיד מושבתת.
    • סוגי מכונות שמשתמשות במעבדי Intel: השחלת-יתר מושבתת כברירת מחדל.
    • סוגי מכונות שמשתמשות במעבדי AMD: SMT מופעל כברירת מחדל.
    • סוגי מכונות שמשתמשים רק בשרשור אחד לכל ליבה, כמו מעבדי Arm: אין תמיכה ב-SMT. כל המעבדים הווירטואליים שביקשתם מוצגים.

    הפעלת SMT

    במאגרי צמתים של GKE Standard, אפשר להפעיל SMT אם הוא מושבת כברירת מחדל עבור סוג המכונה שנבחר. החיוב הוא על כל vCPU, גם אם מפעילים את SMT וגם אם לא. למידע נוסף, קראו את המאמר תמחור כשמשנים את מספר הליכי המשנה לכל ליבה. כדי לשנות את הגדרת ה-SMTP, מבצעים אחת מהפעולות הבאות:

    • מגדירים את הדגל --threads-per-core כשיוצרים מאגר צמתים של GKE Sandbox שמשתמש ב-gVisor:

      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: סוג המכונה.

    • כדי להשתמש ב-DaemonSet כדי להפעיל SMT במאגר צמתים קיים:

      1. הוספת התווית cloud.google.com/gke-smt-disabled=false לצומת למאגר צמתים קיים שמשתמש ב-gVisor:

        gcloud container node-pools update NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --node-labels=cloud.google.com/gke-smt-disabled=false

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

        • ‫NODE_POOL_NAME: השם של מאגר הצמתים הקיים.
        • ‫CLUSTER_NAME: השם של אשכול קיים שבו רוצים ליצור את מאגר הצמתים החדש.
        • ‫LOCATION: האזור או התחום של Compute Engine שבו נמצא האשכול.

      2. פורסים את ה-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

      3. מוודאים שה-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

      4. בודקים אם 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 ובמצב Standard

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

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

    תכונות לא תואמות

    המגבלות הבאות חלות על GKE Sandbox:

    • המגבלות הבאות חלות על ארגזי חול של gVisor ושל מכונות וירטואליות מיקרו:

    • המגבלות הבאות חלות רק על ארגזי חול של gVisor:

    • המגבלות הבאות חלות רק על ארגזי חול של microVM:

      • אין תמיכה בפודים שמשתמשים בהגדרה hostNetwork: true. פודים שפועלים בארגז חול של microVM ומשתמשים בהגדרה hostNetwork: true לא יכולים לגשת למשאבים מחוץ לפוד.
      • כל כלי אבחון שמסתמך על מעקב ברמת השקע יכול לגשת רק לממשקי הרשת שמצורפים ל-microVM.

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