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

אינפורמטק דיגיטל » Recursos » פודמן, KVM וקונטיינרים: מדריך מעשי לווירטואליזציה מאובטחת

כשמתחילים להקים סביבת קונטיינרים רצינית על לינוקס, עולה מיד אותה שאלה: באיזו מידה בטוח להסתמך אך ורק על קונטיינרים, ומתי מומלץ לשדרג ל-KVM או למיקרו-VM? בסביבות ארגוניות, בהן Docker, Podman, LXC, מכונות וירטואליות KVM והיפר-ויזורים שונים מעורבבים יחד, הבנה מוצקה של מודל הבידוד היא המפתח למניעת טעויות.

יתר על כן, תרחישים מורכבים למדי אינם נדירים, כמו ניסיון להשתמש ב-Docker Desktop או Podman בתוך מכונה וירטואלית ב-VirtualBox או KVM , שבהם מספר רמות של וירטואליזציה (מקוננות או לא) נכנסות לתמונה, וקל להיתקל בשגיאות כמו "KVM אינו מופעל במארח". בואו נארגן את כל החלקים הללו - מכולות, מכונות וירטואליות, Podman, KVM, רשת ואבטחה - ונראה כיצד לשלב ביניהם כדי להשיג וירטואליזציה מאובטחת ומעשית באמת.

וירטואליזציה קלאסית עם KVM ומכונות וירטואליות

הבסיס של כל המערכת הזו נותר הווירטואליזציה המלאה של מערכות הפעלה באמצעות היפר-ויזורים כמו KVM, Xen או ESXi . כאן, החומרה הפיזית מפעילה היפר-ויזור שאחראי על "פיצול" המכונה למספר מכונות וירטואליות עצמאיות.

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

אנחנו מדברים בדרך כלל על שני סוגים של היפר-ויזורים: היפר-ויזורים מסוג 1 או Bare Metal, הפועלים ישירות על החומרה, והיפר-ויזורים מסוג 2, המתארחים על גבי מערכת הפעלה קיימת. VirtualBox או VMware Workstation יהיו מסוג 2 , בעוד ש-KVM המנוהל על ידי libvirt על שרת לינוקס קרוב יותר לתרחיש מסוג 1, למרות שהוא חולק שטח עם המארח עצמו.

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

כדי לנהל את הפלטפורמות הווירטואליות הללו ב-GNU/Linux, libvirt כמעט תמיד משמש כ-API לתזמור , שמעליו נתמכים כלי גרפיקה וכלים של שורת פקודה, או פרויקטים גדולים יותר כמו OpenStack, שבונה עננים שלמים על ידי שילוב של מכונות וירטואליות, מערכות הפעלה Bare Metal ומכולות.

דרישות חומרה ובעיות נפוצות עם KVM

לפני הפעלת KVM או שימוש בפתרונות התלויים בו (כגון תצורות מסוימות של Docker Desktop או micro-VM), עליך לוודא שהמעבד תומך בווירטואליזציה של חומרה (VT-x ב-Intel או SVM/AMD-V ב-AMD) ושהוא מופעל ב-BIOS/UEFI.

בלינוקס, יש לנו בדיקה מהירה: אם הפקודה `grep -E 'svm|vmx' /proc/cpuinfo` לא מחזירה דבר, או שהאפשרות עדיין מושבתת בקושחה, KVM לא יעבוד. יתר על כן, בתרחישים שבהם נפעיל מכונות וירטואליות בתוך מכונה וירטואלית אחרת (וירטואליזציה מקוננת), ההיפר-ויזור ברמה העליונה חייב לחשוף במפורש את ההרחבות הללו לאורח.

כאשר משהו משתבש, מופיעות הודעות אופייניות, כמו החלון הקופץ הידוע לשמצה של Docker Desktop ב-RHEL 9 בתוך VirtualBox: "KVM אינו מופעל במארח ". הבעיה כאן אינה עם Docker או RHEL ישירות, אלא שה-VirtualBox VM אינו מקבל את הרחבות הווירטואליזציה הדרושות כדי להפעיל KVM בתוכו.

פקודות כמו `modprobe kvm` או `modprobe kvm_amd / kvm_intel` צריכות לטעון את מודולי הליבה ללא הודעות שגיאה. אם `dmesg` לא מציג שום דבר רלוונטי, או `lsmod | grep kvm` מציג רק `kvm` ו-`irqbypass` חסרים, והמודולים הספציפיים למעבד חסרים, סביר מאוד שוירטואליזציה של חומרה אינה נחשפת למערכת האורחת או מושבתת בקושחה.

בתרחישים אלה, גם אם כל התכונות האפשריות מופעלות בתוך ה-host, אם VirtualBox אינו מציע וירטואליזציה מקוננת או שהוא מוגדר בצורה שגויה, KVM פשוט לא יעבוד . הפתרון כרוך בבדיקת תצורת ההיפר-ויזור המארח (VirtualBox, VMware וכו') והפעלת וירטואליזציה מקוננת אם זמינה.

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

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

קונטיינר הוא למעשה קבוצה של תהליכים המקובלים באמצעות מרחבי שמות וקבוצות שרת . בתוך "סביבה" זו, היישום מאמין שהוא פועל על מכונה משלו, עם מערכת קבצים משלו, ממשקי רשת ו-PID משלו, אך במציאות, הוא חולק את הליבה עם המארח.

קונטיינרים מציעים ביצועים כמעט מקוריים מכיוון שאין ליבה שנייה ואין אמולציית חומרה מלאה . התקורה מינימלית: מספיקה רק כדי להרכיב מרחבי שמות, להגביל משאבים עם cgroups ולאכוף מדיניות אבטחה (seccomp, AppArmor, SELinux וכו').

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

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

מרחבי שמות וקבוצות שרת: הבסיס לבידוד מכולות

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

מרחבי שמות מבודדים דברים כמו PIDs, רשת, נקודות הרכבה, IPC, שם מארח (UTS) ומשתמשים . בדרך זו, תהליך "רואה" רק את התהליכים, ממשקי הרשת, מערכת הקבצים ושם המארח של מרחב השמות שלו, מה שנותן לו תחושה של הימצאות במערכת אחרת.

מצידם, cgroups מאפשרים לך לציין כמה CPU, זיכרון, דיסק I/O, מספר תהליכים וכו', קונטיינר יכול לצרוך . זה מונע עומס בלתי מבוקר להציף את כל המארח, דבר חיוני בעת שיתוף צמתים בין צוותים או פרויקטים.

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

הדרך ההגיונית להקשיח את הסביבה היא לשלב מסנני syscall עם seccomp, מדיניות MAC (AppArmor או SELinux) וצמצום דרסטי של יכולות התהליך, באופן אידיאלי יחד עם מרחבי שמות של משתמשים ומצב rootless כדי למזער נזק אם מישהו יצליח לברוח מהקונטיינר.

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

בפלטפורמת קונטיינר אמיתית, משטח התקיפה מפוזר על פני מספר שכבות: הליבה וזמן הריצה (runc, containerd, CRI-O), שרשרת אספקת התמונה, תצורת הקונטיינר/מתזמר והתשתית הבסיסית (ענן, אחסון, IAM, רשת).

וקטורי תקיפה נפוצים כוללים פגיעויות תוכנה בליבת המערכת או בזמן הריצה של המכולה, שימוש בתמונות לא מאובטחות או לא מתוחזקות, יצירת שגיאות תצורה ב-Kubernetes או Docker (מכולות בעלות פריבילגיות, חיבורי מארח מסוכנים, מצבי רשת פתוחים יתר על המידה), ופגמי אבטחה ברישומים או בצינורות CI/CD.

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

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

לכן, בסביבת ייצור זה לא אופציונלי: עליך לסרוק תמונות לאיתור פגיעויות בעזרת כלים כמו Trivy, Clair או Grype , לשלוט באילו רישומים נעשה שימוש (Harbor, Quay, GHCR עם מדיניות) ולחתום/לאמת את התמונות לפני פריסתן באשכול.

Docker מול Podman: השפעה על מודל האיומים

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

Docker, במצב rootful קלאסי, מסתמך על daemon מרכזי (dockerd) שפועל כ-root . ממשק שורת הפקודה (CLI) מתקשר עם daemon זה דרך /var/run/docker.sock או דרך TCP, ותהליך פריבילגי זה הוא שיוצר ומשמיד קונטיינרים, מנהל תמונות, רשתות ואמצעי אחסון, ומקיים אינטראקציה עם רישומים.

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

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

גישה זו מתיישבת טוב יותר עם מודל יוניקס לפיו "כל תהליך שייך למשתמש שמפעיל אותו" ונמנעת מהסתמכות על דמון בעל הרשאות גבוהות . יתר על כן, Podman מציע תאימות עם פקודות Docker, מה שמפשט את ההעברה (ניתן אפילו להשתמש בכינוי `docker=podman` בסביבות שבהן אינך רוצה להתקין את Docker CE).

מצב ללא שורשים ומרחבי שמות של משתמשים

אחת ההתקדמות המעשית העיקרית בהפחתת ההשפעה של בריחת קונטיינר פוטנציאלית היא מצב rootless בשילוב עם מרחבי שמות של משתמשים . השאלה שהדבר נועד לענות עליה היא: "מה קורה אם הקונטיינר אכן בורח?"

מרחבי שמות משתמשים מאפשרים לך למפות מחדש את ה-UID 0 של המכולה ל-UID לא מורשה במארח . במילים אחרות, בתוך המכולה האפליקציה מאמינה שהיא root, אבל מנקודת מבטו של המארח, התהליך הזה הוא למעשה משתמש רגיל עם טווח subuid/subgid שהוקצה.

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

פודמן תוכנן מההתחלה עם מודל זה בחשבון: קונטיינריזציה ללא root כברירת מחדל במידת האפשר , שימוש ב-SELinux/AppArmor ו-cgroups אפילו ללא root, ודגש חזק על מזעור הרשאות מבניות.

Docker מציע כעת גם מצב rootless אמיתי , שבו dockerd ומכולות נמצאים בתוך מרחב שמות משתמש, בניגוד ל-userns-remap הישן יותר שבו הדמון נשאר root. מנקודת מבט ביטחונית, זה מונע מניצול לרעה כנגד dockerd להעניק גישת root אוטומטית למארח.

רשתות קונטיינרים עם Podman: ממשקים של גשר, מארח, macvlan ו-rootless

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

Podman 4 הציג את netavark, מנהל התקן רשת שעוקב אחר מודל CNI כדי לספק למכולות כתובות IP ברשתות גשר, macvlans וכו'. עם netavark, מכולות rootful בדרך כלל מתחברות כברירת מחדל לרשת בשם "podman" המשויכת לגשר לינוקס (podman0) במארח, עם כתובת 10.88.0.0/16.

רשת גשר ברירת מחדל זו מספקת קישוריות אינטרנט בסיסית באמצעות כללי SNAT ומאפשרת לך לחשוף פורטים של קונטיינר למארח באמצעות `-po --publish`, אשר מייצר כללי DNAT ב-iptables/nftables. לצורך תאימות עם Docker, רשת זו אינה מפעילה שרת DNS פנימי.

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

בסביבות מתקדמות יותר, ניתן להשתמש ברשתות macvlan או ipvlan כדי לחבר קונטיינרים ישירות לרשת הפיזית של המארח. Macvlan מאפשר לקונטיינרים לתקשר זה עם זה, בעוד ש-ipvlan נוטה לבודד אותם יותר; אלו אפשרויות שימושיות בפריסות שבהן כל קונטיינר צריך להיתפס כמארח אמיתי על ידי שאר הרשת.

רשתות חסרות שורשים: slirp4netns ופסטה

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

כאן נכנס לתמונה slirp4netns , המנגנון הקלאסי בו משתמש Podman rootless . פרויקט זה יוצר סביבת רשת מבודדת בתוך הקונטיינר ומשתמש במודול slirp של הליבה כדי לבצע תרגום כתובות (NAT) ולאפשר לקונטינר גישה לאינטרנט דרך הרשת של המארח.

בפועל, slirp4netns יוצר ממשק TAP בתוך מרחב השמות של הרשת של המכולה (לדוגמה, tap0 עם IP 10.0.2.100 ושער 10.0.2.2) ומנתב תעבורה דרך מחסנית TCP/IP המוטמעת במרחב המשתמש. זה פונקציונלי, אך מוסיף תקורה מסוימת ומגבלות מסוימות.

אחת המגבלות הללו היא שמשתמשים לא מורשים אינם יכולים להשתמש בפורטים מתחת ל-1024. הפרמטר sysctl net.ipv4.ip_unprivileged_port_start מסמן מאיזה פורט הם נחשבים "לא מורשים" (כברירת מחדל, 1024), אם כי ניתן להתאים זאת בקפידה אם מודל האבטחה מאפשר זאת.

ב-Podman 5, slirp4netns מוחלף על ידי pasta כמנגנון ברירת המחדל ללא שורשים . גם Pasta פועל כולו במרחב המשתמש, אך הודות לממשק ההקשה וטכניקות אפס העתקה, הוא משיג ביצועי רשת כמעט מקוריים, ומפחית את ההשפעה על השהייה והתפוקה בהשוואה ל-slirp4netns.

גישור ואחסון רשתות במכולות חסרות שורשים

אפילו כאשר עובדים במצב שאינו root, נוכל לחבר קונטיינרים ללא root לרשת הגשר "podman" המוגדרת כברירת מחדל באמצעות `--network=podman`. פעולה זו מנצלת את היכולות של netavark וממפה פורטים למארח באמצעות `-p`, בדיוק כמו במצב rootful.

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

כדי לבדוק את הגשרים חסרי השורשים הללו, פודמן מציע את הפקודה `podman unshare --rootless-netns` , אשר פותחת מעטפת במרחב השמות של הרשת של המשתמש. משם, ניתן לצפות בגשרים הפנימיים ולאמת קישוריות ישירה למכולות.

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

בקצה השני נמצאת רשת המארח (--network=host) , שבה המכולה חולקת את מחסנית הרשת עם המארח ללא כתובת IP משלו. במצב זה, אם מכולה ללא root מפעילה שרת בפורט 8080/tcp, השירות יהיה זמין ישירות בפורט 8080 של המארח, ובכך חוסכת מיפוי פורטים אך מפחיתה את הבידוד.

Podman Desktop, כלי הדמיה ותזמור מקומי

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

תמונות מתקבלות באמצעות `podman pull`, אשר מוריד מהרגיסטרים המוגדרים ב-`/etc/containers/registries.conf` . אם התמונה מצוינת ללא שם רישום, Podman ינסה לאתר אותה בתוך סדר הרישום שהוגדר, באמצעות התג `latest` כברירת מחדל.

בנוסף לפקודה הפקודית (CLI) של פודמן, אנו יכולים להשתמש ב-skopeo ככלי ייעודי לניהול, בדיקה והעתקה של תמונות בין רישומים ומאגרים מקומיים. פקודות כמו copy (העתק), delete (מחיקה) ו-sync (סנכרון) מאפשרות לנו להפוך את הסנכרון בין מאגרים לאוטומטי, לסמן תמונות לאיסוף זבל (Garbage Collection) ולהעביר ארטיפקטים בין סביבות.

לאחר הורדת התמונה, `podman run` מאפשר לך להפעיל קונטיינרים על ידי ציון הנתיב והתחבורה (כברירת מחדל, הובלת Docker וחיפוש ברישום המוגדר). האפשרויות הרגילות (-d, -p, --name, --pod וכו') מכסות הן תרחישי מעבדה והן פריסות רציניות יותר.

ניהול יומיומי מתבצע באמצעות `podman ps` כדי לרשום קונטיינרים, `podman stop/start` כדי לעצור או להפעיל מופעים קיימים, ו-`podman rm` כדי להסיר קונטיינרים שהופסקו . אם קונטיינר שונה ואנו רוצים להמיר אותו לתמונה חדשה, `podman commit` שומר את השינויים הללו תחת שם חדש.

פודים ומודלים מתקדמים של ביצוע עם פודמן

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

הפקודה `podman pod create` יוצרת פוד חדש ומחזירה את המזהה שלו, אך כברירת מחדל הפוד נשאר נעצר עד שמכלי משויך מופעל או שהוא מופעל במפורש באמצעות `podman pod start`.

כדי לראות אילו פודים נמצאים במערכת, השתמשו בפונקציה `podman pod ls` , שתפרט גם את מיכל ה-INFRA המשויך לכל אחד מהם. מיכל מיוחד זה שומר על הרשת ומשאבים משותפים אחרים של הפוד פועלים, כך שמספר המכולות לעולם אינו אפס.

פודמן מציע פקודות ספציפיות להפעלה, עצירה או הפעלה מחדש של פודים שלמים (podman pod start/stop/restart) , אך אנו יכולים גם לפעול רק על מיכל ספציפי בתוך הפוד מבלי לשנות את השאר, תוך שמירה על בידוד תהליכים ברמת האפליקציה.

כדי להוסיף עוד קונטיינרים לפוד קיים, השתמשו בפונקציה `podman run --pod POD_NAME` , בהתאם לאותו תחביר כמו עבור קונטיינרים בודדים. לא ניתן להסיר קונטיינר מפוד מבלי להרוס אותו, מכיוון שחברות בפוד קשורה למחזור החיים שלו.

הניטור מתבצע באמצעות podman ps –pod או פקודות ספציפיות לניטור התהליכים של כל הקונטיינרים בכל הפודים , תוך זיהוי מהיר של מה שייך לאיזו קבוצה וכיצד השירותים מופצים.

קונטיינרים, LXC ווירטואליזציה של יישומים

למרות ש-Docker ו-Podman שולטים בשיחה, הם לא אפשרויות הקונטיינריזציה היחידות ב-GNU/Linux . פתרונות כמו LXC/LXD, systemd-nspawn ו-Kata Containers מטפלים בבעיה מזוויות שונות במקצת.

LXC מספקת קונטיינרים של מערכת קלים מאוד, עם שם מארח משלהם, כתובת IP, מערכת קבצים ומערכת init מלאה . בשילוב עם LXD, הפועל כ-hypervisor עבור קונטיינרים ומכונות וירטואליות, היא מספקת חוויה קרובה מאוד למספר מכונות קלות משקל עם ביצועים כמעט-בלתי-מסוננים.

בעוד ש-Docker/Podman מתמקדות במכולות יישומים תואמות OCI , LXC זורחת כאשר נדרשות סביבות מתמשכות עם שירותים ותהליכים מרובים, ומתנהגת כמו מכונה וירטואלית אך עם פחות תקורה ואינטגרציה טבעית מאוד עם ליבת לינוקס.

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

לצד זאת, טכנולוגיות המכוונות למיקרו-VMs ובידוד משופר צברו תאוצה, כגון Kata Containers , אשר מפעילה כל פוד בתוך מכונה וירטואלית קטנה עם ליבה משלה, או gVisor, אשר מוסיף "ארגז חול ליבה" שנכתב ב-Go בין האפליקציה ללינוקס. שתיהן מפחיתות את התלות בליבת ה-Component המשותף ומתקרבות למודל האבטחה של מכונות וירטואליות תוך שמירה על ידידותיות המשתמש של הקונטיינרים.

שיטות עבודה מומלצות להקשחת Docker ו-Podman

עם כל האמור לעיל, הגישה הסבירה לפלטפורמת קונטיינרים חזקה היא לעבוד בשכבות: פילוח עם מרחבי שמות/קבוצות קוד, סינון מדיניות עם seccomp ו-MAC, והגבלת הרשאות מבנית באמצעות מצב rootless.

בפועל, מומלץ לאמץ את הנוהג הסטנדרטי של הפעלת קונטיינרים במצב שאינו root במידת האפשר , במיוחד בסביבות מרובות דיירים או בתוך עננים משותפים. Podman מאפשר זאת כברירת מחדל, ו-Docker rootless מכסה את אותה פילוסופיה כאשר נדרשת תאימות.

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

אמצעי יעיל נוסף הוא שימוש בהפצות בלתי ניתנות לשינוי, מוכוונות קונטיינרים, כגון openSUSE MicroOS או Flatcar Linux . מערכת ה-root לקריאה בלבד ומערכת העדכון האטומית שלהם מפחיתות מאוד את משטח ההתקפה ומקלות על חזרה לשרת אם משהו משתבש לאחר תיקון.

לגבי תצורה: אין להשתמש במכולות פריבילגיות בסביבת ייצור למעט במקרים מבוקרים ביותר , אין להריץ יישומים כ-root בתוך המכולה, להשתמש במערכות קבצים לקריאה בלבד במידת האפשר, ולהגביל את היכולות למינימום ההכרחי. פרופילי SELinux/AppArmor ו-seccomp המותאמים לקריאות בפועל של האפליקציה הם למעשה חובה.

לבסוף, אסור לנו לשכוח את היבט ניטור זמן הריצה . כלים כמו Falco, Sysdig Secure או Aqua עוזרים לזהות אנומליות, ניסיונות בריחה (כגון גישה חריגה ל-/proc או /sys), תעבורת רשת לא טיפוסית או פקודות חשודות, ומספקים זמן להגיב לפני שהמתקפה משתלטת.

על ידי שילוב של וירטואליזציה קלאסית עם KVM, קונטיינרים המנוהלים על ידי Podman (רצוי במצב Rootless), רשתות מפולחות היטב ושיטות עבודה טובות להקשחה, ניתן לבנות פלטפורמת וירטואליזציה גמישה ביותר ומאובטחת למדי. הבנה שלגרעין משותף היא הנקודה הקריטית ביותר, הסתמכות על מכונות וירטואליות או מיקרו-VM כאשר סיכון או תאימות רגולטורית דורשים זאת, וניהול קפדני של שרשרת אספקת התמונה עושים את ההבדל בין סביבת מעבדה לתשתית מוכנה לייצור.