אני רוצה לחזור לימים שמיקרוסופט שחררו את Windows 95. הנה מערכת הפעלה חדשה, טענה מיקרוסופט, שיכולה להריץ ריבוי משימות מבלי שאפליקציה אחת תגרום לקריסת שאר האפליקציות שרצות! כולנו כמובן יודעים את האמת הפשוטה שאפליקציות בהחלט גרמו למערכת ההפעלה לקרוס כמו כלום, אפליקציות "בלעו" זכרון וניהול הזכרון היה די כושל, בוודאי כשמשווים זאת למערכות היותר מתקדמות שמיקרוסופט הוציאו שנים לאחר מכן כמו ה-NT 4.0 וה-2000 וכו'. הסיבה המרכזית לכך היתה כמובן כל הסביבה "מתחת" – DOS, שלא היתה ממש בנויה טוב לדברים כאלו, וה-Protected Mode שאינטל הוסיפה החל במעבדי i386 לא ממש עזר הרבה (אם כי לא באשמת אינטל).
שנת 2018, חברות רבות עוברות להשתמש בקונטיינרים אבל ישנה אי נוחות מבחינת אבטחת מידע לגבי קונטיינרים. למי שלא מכיר – הסיבה שקונטיינרים רצים מהר היא בגלל שהקונטיינר אינו מכיל Kernel או דרייברים שמתממשקים ל-Kernel. קונטיינרים מקבלים שרותים מ-Kernel יחיד שרץ על אותה מכונה (פיזית או וירטואלית) וכך כל מה שיש בקונטיינרים הם ספריות ואפליקציה שצריכה לרוץ (ולצערי רבים עדיין בונים קונטיינרים שמכילים מספר אפלקציות/שרותים במקום להריץ רק אפליקציה אחת. זה "מתנקם" אחר כך באנשי Devops שעוברים להשתמש ב-Kubernetes).
מדוע אי נוחות מבחינת אבטחת מידע? כי הקונטיינר הוא לא יותר מאשר Process, שלא-כל-כך קשה "לצאת" ממנו אל ה-Host ומשם לחולל נזקים. רד-האט עם מערכת ה-OpenShift שלה לא מאפשרת (בברירת מחדל) לדוגמא לקונטיינרים לרוץ כ-root או להריץ בתוכה אפליקציות כ-root, וכל המערכת רצה עם SELinux מופעל (כ-Enforcing), כך שאם אתה מבטל SELinux, אין OpenShift. בפתרונות אחרים מבוססים Kubernetes חוסמים תקשורת בין ה-Pods, אבל זה לא תמיד יכול לסייע – במיוחד אם המערכת חשופה החוצה ומריצים מאות pods שמכילים Apache או NGINX לדוגמא.
לשם כך נצטרך קודם להיפטר מ-Docker.
לפני שזורקים עליי מטר עגבניות רקובות, אסביר: Docker עובד מעולה עם הפורמט שלו, אבל מבחינת אבטחה – הוא לא משהו. בנוסף, Docker כבר נהיה מנופח מבחינת משאבים ואין לו שום יתרון מבחינת אבטחת מידע על פתרונות אחרים, למיטב ידיעתי.
במקום Docker, תכירו את CRI-O. (מבטאים "קריאו")
CRI-O זו מערכת חלופית ל-Docker שיודעת לבצע מה ש-Docker מבצע (ולכן היא תואמת ל-Docker), רק שהיא צורכת פחות משאבים, ואחד הדברים המעולים שיש בה הוא שניתן בעצם להגדיר קונטיינרים שאנחנו בוטחים בהם (Trusted) וקונטיינרים שאיננו בוטחים בהם (Untrusted) ולהריץ את 2 הסוגים במקביל, כאשר קונטיינרים שאיננו בוטחים בהם, ירוצו דרך מערכת QEMU כמכונה וירטואלית (sandbox) עם kernel קטן וכל השרותים הנחוצים להרצת קונטיינר. במילים אחרות – בשינוי קובץ YAML נוכל בקלות להקים את הקונטיינרים בצורה מופרדת או בצורה רגילה.
CRI-O מתחבר ל-Kubernetes בצורה חלקה ואינו מצריך הטמעת טלאים, וכמו כן CRI-O משתמש בשיטה של אינטל (שנקראה בעבר Clear Containers וכיום Kata Containers) כדי להריץ קונטיינרים בצורה מבודדת, אך שעדיין מאפשרת להשתלב בתוך אותם Namespaces לדוגמא.
להלן הדגמת וידאו קטנה איך עם CRI-O בשילוב Kubernetes מאפשר להריץ קונטיינרים שאנחנו מגדירים כ-Trusted ואיך משלבים קונטיינרים שאנחנו מגדירים כ-Untrusted ורצים בתוך סשן VM (לחצו מצד ימין למטה על האייקון עם החצים כדי לצפות בכל הטרמינל, הנגן לא יודע לבצע Scale לוורדפרס):
כפי שאנחנו יכולים לראות, השילוב רץ יפה מאוד.
לאלו המעוניינים לנסות את הדברים הללו, חשוב לשים לב לנקודות הבאות:
- כרגע, לא ניתן להריץ את הדברים בענן ציבורי בתוך Instance רגיל אלא אך ורק בתוך Bare Metal Instances. כמו כן לא ניתן להשתמש ב-CRI-O בתוך שרותים כמו ECS.
- אם אתם רוצים להריץ זאת בתשתית מקומית שלכם, ואתם מריצים Kubernetes על מכונות VM, יש להגדיר את אותן מכונות VM עם Nested Virtualization על מנת להריץ קונטיינרים Untrusted.
- אם אתם רוצים לנסות את הדברים על מכונת הדסקטופ שלכם עם Minikube, יש להפעיל את minikube עם ההוראות כאן.
- אם אתם משתמשים במערכת OpenShift (גירסה 3.11 ומעלה), ניתן להוסיף תמיכת CRI-O בנוסף לתמיכת Docker למערכת. ההוראות – כאן.
- אם אתם משתמשים ב-CAAS של SuSE, בגירסה 3 ומעלה ניתן לבחור בין Docker ל-CRI-O. עוד פרטים ניתן לקרוא כאן.
לסיכום: CRI-O מאפשר לנו להריץ בצורה קלה ומאובטחת קונטיינרים שלא אנחנו בנינו ושהורדנו ממקורות אחרים ובמקביל הוא מאפשר לנו להריץ קונטיינרים שאנו בוטחים בהם (ושאנחנו בנינו) כפי שהרצנו עד היום, רק מבלי להשתמש ב-Docker עצמו ובמשאבים הגדולים שהוא צורך.