„תריצו את זה בארגז חול“ נשמע כמו הוראה אחת. בפועל יש ארבעה גבולות נפוצים שאנשים מתכוונים אליהם, והם עוצרים דברים שונים מאוד. בחירה בגבול הלא נכון או משאירה אתכם חשופים, או הופכת כל הרצה לאיטית ויקרה יותר ממה שצריך.
ההשוואה הזו מניחה שהקוד באמת לא מהימן: נכתב בידי מודל שפה, הוגש בידי משתמש, או הגיע ב־pull request ממישהו שאינכם מכירים. לקוד שכתבתם בעצמכם יש צרכים אחרים.
מה יכול להשתבש
לפני שמשווים גבולות, כדאי לומר בשביל מה הם קיימים. קוד לא מהימן יכול:
- לקרוא את מה שאסור לו: משתני סביבה, מפתחות SSH, קבצים בתיקיית הבית שלכם, נקודות קצה של מטא־נתונים בענן.
- למצות משאבים: לולאה אינסופית, fork עד שהמכונה נתקעת, מילוי הדיסק.
- לנצל לרעה את הרשת: לסרוק מארחים אחרים, לשלוח ספאם, לכרות מטבעות קריפטו, לקרוא לשירותים הפנימיים שלכם.
- להשתקע: להתקין משימת cron או שירות ששורדים את המשימה.
- לברוח: לנצל באג בשכבה שמתחת כדי להריץ קוד על המארח עצמו.
כל רמה בהמשך מטפלת בחלק מאלה ולא באחרים.
רמה 1: תהליך
ארגז החול הפשוט ביותר הוא תהליך בן: subprocess.run עם זמן קצוב, אולי תחת משתמש נפרד, ואם אתם יסודיים גם עם מגבלות משאבים ומסנן seccomp.
עוצר: זמן שיוצא משליטה (הזמן הקצוב), חלק ממיצוי המשאבים (המגבלות), חלק מקריאות המערכת המסוכנות (seccomp). לא עוצר: קריאה של כל מה שהמשתמש הזה יכול לקרוא, גישה לרשת, השתקעות דרך כל מקום שהמשתמש יכול לכתוב אליו, וכל באג בליבה. כשל אופייני: הקוד קורא קובץ ששכחתם שהוא קריא, או שמפרש שפה „מוגבל“ מתגלה כבעל פתח מילוט. ההיסטוריה מלאה בארגזי חול בתוך שפות שלא החזיקו מעמד.
זמן העלייה הוא למעשה אפס. מתאים לקוד שכתבתם; זה לא גבול לקוד שלא כתבתם.
רמה 2: קונטיינר
בקונטיינר, namespaces נותנים לקוד תצוגה משלו של קבצים, תהליכים ורשת; cgroups מגבילים מעבד וזיכרון; הרשאות (capabilities) שהוסרו ו־seccomp מצמצמים את מה שהוא יכול לבקש מהליבה.
עוצר: קריאת הקבצים של המארח (אלא אם עוגנו פנימה), צפייה בתהליכים אחרים, שימוש בלתי מוגבל במשאבים, ואת רוב בעיית ההשתקעות אם זורקים את הקונטיינר אחר כך. לא עוצר: באג בליבת המארח המשותפת. כל הקונטיינרים על המכונה מדברים עם אותה ליבה, כך שחולשה נגישה בליבה היא יציאה. כשל אופייני: תצורה, לא ניצולים אקזוטיים. קונטיינר privileged, השקע של סביבת הריצה של הקונטיינרים מעוגן בפנים, רשת המארח מופעלת „רק לדיבאג“. כל אחד מאלה מסיר את הגבול בשקט.
זמן העלייה הוא אלפיות שנייה. קיימות גרסאות מוקשחות, כולל ליבות במרחב המשתמש שמיירטות קריאות מערכת לפני שהן מגיעות למארח, במחיר מסוים של מהירות ותאימות. לקוד מאנשים שאתם סומכים עליהם, קונטיינר שמוגדר היטב הוא ברירת מחדל סבירה.
רמה 3: microVM
microVM מריצה ליבה משלה תחת היפרווייזר, כמו מכונה וירטואלית מלאה, אבל עם כמעט כל החומרה המדומה מוסרת. Firecracker הוא הדוגמה המוכרת ביותר.
עוצרת: כל מה שקונטיינר עוצר, ובנוסף את בעיית הליבה המשותפת. כדי להגיע למארח, הקוד צריך לשבור את ההיפרווייזר או אחד מקומץ התקנים וירטואליים, משטח קטן בהרבה מממשק קריאות המערכת של ליבה. לא עוצרת: שימוש לרעה במה שאתם מוסרים לה. תעבורה יוצאת פתוחה עדיין יכולה להיות מנוצלת לרעה; סודות שאתם מזריקים עדיין יכולים לדלוף. כשל אופייני: מדיניות, לא בידוד. מישהו מעביר טוקן של סביבת ייצור „כדי שהבדיקות יעבדו“, או משאיר תעבורה יוצאת ללא הגבלה בעומס שלא צריך אותה.
זמן העלייה הוא משבריר שנייה ועד כשנייה, עם תקורה של כמה מגה־בייט. זה מהיר מספיק כדי ליצור אחת לכל משימה ולמחוק אותה אחר כך, מה שפותר גם את ההשתקעות: לא נשאר שום דבר לחזור אליו.
רמה 4: מכונה וירטואלית מלאה
למכונה וירטואלית רגילה, או ל־VPS, יש גבול מאותו סוג כמו ל־microVM: וירטואליזציה בחומרה והיפרווייזר. ההבדל הוא בכל מה שמסביב: מודל התקנים מלא, מערכת הפעלה שלמה, כתובת IP ציבורית אם תרצו, ומחזור חיים שנמדד בימים או בחודשים.
עוצרת: אותם סוגי בעיות כמו microVM, עם משטח תקיפה מעט גדול יותר כי מדמים יותר חומרה. לא עוצרת: שימוש לרעה בזהות הרשת שלה עצמה. מכונה וירטואלית עם IP ציבורי שמריצה קוד פוגעני מכניסה את כתובת ה־IP שלה לרשימות חסימה, וזה משנה אם אותה כתובת שולחת גם את הדואר שלכם. (אם זה כבר קרה, ראו מה לעשות כשכתובת ה־IP שלכם ברשימת חסימה.) כשל אופייני: היא חיה יותר מדי זמן. מכונה וירטואלית שנוצרה לניסוי אחד אוספת אישורי גישה ומצב, והופכת לאט למכונה המהימנה שהיא הייתה אמורה להגן עליה.
זמן העלייה הוא מעשרות שניות ועד דקות, והחיוב בדרך כלל חודשי. זו הצורה הנכונה לשירות ארוך טווח שצריך פורטים נכנסים, והצורה הלא נכונה להרצת קוד של 20 שניות.
ההשוואה
| תהליך | קונטיינר | microVM | מכונה וירטואלית מלאה | |
|---|---|---|---|---|
| ליבה משלה | לא | לא | כן | כן |
| הגבול העיקרי | הרשאות משתמש | namespaces + ליבה משותפת | היפרווייזר, מודל התקנים זעיר | היפרווייזר, מודל התקנים מלא |
| זמן עלייה | ~0 | ms | ~0.1–1 ש׳ | 10 ש׳ – דקות |
| תקורה | אין | קטנה | כמה MiB | עשרות–מאות MiB |
| זריקה אחרי כל משימה | קל | קל | קל | איטי, יקר |
| פורטים נכנסים / IP ציבורי | של המארח | של המארח | בדרך כלל אין | כן |
הבחירה
- קוד שאתם או הצוות שלכם כתבתם: תהליך או קונטיינר מספיקים.
- אינטגרציה רציפה (CI) לענפים שלכם: קונטיינר על ה־runner שלכם.
- קוד שסוכן יצר, הגשות משתמשים, pull requests מבחוץ: microVM לכל משימה, שנמחקת אחר כך.
- שירות לא מהימן שחייב לקבל חיבורים או לרוץ שבועות: מכונה וירטואלית נפרדת עם IP משלה, הרחק מכל דבר שמחזיק את אישורי הגישה שלכם או שולח את הדואר שלכם.
מה שלא תבחרו, חלים מעליו שני כללים: אל תשימו בפנים שום דבר שלא הייתם מוסרים לכותב הקוד, והחליטו במודע מה מותר לרשת לעשות.
איפה המוצרים שלנו נמצאים
לרמה 3 אנחנו מפעילים ארגזי חול לקוד: מכונות Firecracker microVM שעולות תוך כשנייה, עם אינטרנט יוצא, בלי פורטים נכנסים ועם חיוב לפי שנייה. הם מכוונים בדיוק לסעיף השלישי למעלה; הדף אמצעי ההגנה של MCP מסביר איך להגביל מה סוכן רשאי לעשות איתם. לרמה 4, VPS כמו תוכנית AI agent נותן לכם מכונה שלמה לפי חודש. הדוגמאות המלאות בארגז חול לסוכני בינה מלאכותית מראות את דפוס ה־microVM מקצה לקצה, ומה סוכני בינה מלאכותית צריכים מהתשתית בוחן את הבידוד כאחת מכמה דרישות.
תגובות
אין עדיין תגובות. היו הראשונים.