כאשר עסקים וחברות מעוניינים לעבור לקונטיינרים, אחד האספקטים החשובים להם ביותר הוא אבטחת מידע. אז מה קורה כשאני חושף קונטיינר מסוים לעולם? איך אני מונע מפורץ כניסה לקונטיינר, וכיצד מונעים ממנו לחדור הלאה, לגנוב מידע ועוד?
טכנית, אלו שמכירים יוניקס ולינוקס משנים קודמות, מכירים בוודאי את chroot ובמקרים רבים אנשים נוטים לחשוב שקונטיינרים הם בדיוק כמו להריץ chroot (כלומר להקים file-system ועליו להריץ את פקודת chroot על מנת לתת "מערכת הפעלה" נוספת), אך למען האמת, Docker משתמש בהרבה יותר מזה כדי להריץ קונטיינר שיכול להיות מאובטח (יש צורך בעבודה נוספת על מנת לאבטח, אפשר לקרוא על כך כאן).
העניין הוא שברוב המקרים בחברה לא יריצו קונטיינר יחיד. אם יש לדוגמא אפליקציה וובית (Web), ברוב המקרים היא תהיה מחוברת ל-DB שירוץ על קונטיינר אחר, וההרצה תבוצע ע"י Container Scheduler כמו Mesos, OpenShift, Kubernetes, Docker-Swarm ועוד – הם ירימו את הקונטיינרים וינהלו את הכל.
אז מהם פתרונות האבטחה הקיימים? אציג מספר דוגמאות:
• אינטל מציעה את Clear Container (בגרסה 2.1.4 ששוחררה לאחרונה). היתרון של Clear Container בהשוואה לקונטיינרים של Docker הוא בכך שכל קונטיינר של Clear Container הוא בעצם מכונה וירטואלית (VM) שבתוכה מותקנת ורצה האפליקציה. משמע, בשביל להריץ Clear Container, תצטרכו להריץ זאת על Bare Metal (כלומר על "ברזלים") בלבד ולא על VM (יש כמובן Nested Virtualization לכל תוכנת וירטואליזציה, אבל אף חברה לא תשתמש בזה באופן רציני בפרודקשן לדוגמא). הבעיה הראשונה שאני רואה היא ששום חברה לא תסכים שמערכת תקים מכונות VM "על הברזל" בלי מערכת שתנהל את אותם VM מבחינת משאבים, ניטור ובכלל – ללא פתרון כמו vCenter שיש מ-VMWare למכונות VM – אף אחד רציני לא יכנס לזה.
האם הפתרון של אינטל יכול להשתמש ב-Kubernetes? כן אבל זה ממש לא מוכן לפרודקשן.
• Kubernetes בעקרון נוקט שיטת אבטחה של "הכל סגור". בברירת המחדל, כאשר אתה מקים קונטיינרים או POD, אינך יכול לגלוש אל האפליקציה שרצה בקונטיינרים או ב-POD ועליך "לחשוף" פורטים מסוימים או להשתמש ב"שרות חשיפה" כמו LoadBalancer או NodePort (שמאפשר לפתוח פורטים מסויימים שיתחברו אל ה-Load Balancer החיצוני שלכם) או ClusterIP. החסרון ב-Kubernetes הוא שזו מערכת Multi Platform שאינה מכירה בחלק מתכונות אבטחה שה-Kernel והמערכת יכולים לתת (כמו SELinux – גם בגרסה הנוכחית Kubernetes עדיין לא מאפשר לעבוד עם זה). Kubernetes מכיר כמובן ב -namespaces ו- cgroups כדבר שנותן אבטחה, אבל לחברות רבות זה לא מספיק.
• OpenShift מכיל את Kubernetes ומערכת Openshift בעצם "עוטפת" את Kubernetes ומוסיפה לו בדיוק את הדברים שחברות מחפשות מבחינת אבטחה. כך לדוגמא אין אפשרות להריץ התקנת Openshift על שרתים מבלי להפעיל SELinux ו-NetworkManager כך שמראש המערכת מקימה קונטיינרים ושאר דברים בצורה מאובטחת כברירת מחדל.
• מה עם Mesos? אני לא מומחה ב-Mesos אבל לפחות לפי כמה שהכרתי אותו, ישנה אבטחה ברמה של הקמת ותקשורת בין קונטיינרים (עם Auth), אבל אינני רואה שם שום דבר שיכול בעצם למנוע מפורץ שנמצא בקונטיינר – "לצאת החוצה", כלומר הכל תלוי בבנייה ידנית שלך לקונפיגורציות של הקונטיינר, שימוש בתכונות אבטחה של ה-Kernel (ראו לינק ראשון בפוסט זה) וכו'. אין SELinux, AppArmor שיכולים למנוע דברים גם אם המשתמש השיג root מקומי בתוך הקונטיינר.
• לגבי Docker-Swarm: אנשים לא אוהבים שאני אומר את זה, אבל מבחינת אבטחה ב-Docker Swarm, אין ממש הרבה. כן, אתה יכול לבנות רשת מוצפנת (IPSEC), אבל זה לא עוזר אם מישהו נכנס לקונטיינר ויש לו עכשיו גישה לקונטיינר עם ה-DB. זה נחמד שיש הצפנה, אבל הפורץ נכנס אחרי שיש כבר הצפנה והרשת בין הקונטיינרים פועלת באופן שקוף (כבר בוצע Authentication). אז נכון, הוא לא יוכל לפתוח כניסות חדשות, אבל הוא בהחלט יכול להשתמש בכניסות קיימות (פורטים) ואולי לא לגרום לנזק לכל המערכת אלא רק לקונטיינרים שאליהם הקונטיינר שהוא נכנס מחובר. בקיצור, דעתי האישית לגבי Docker-Swarm, היא שהוא לוקה בחסר במבחינת אבטחה.
אז האם Docker עצמו יכול להיות מאובטח? בהחלט כן, במידה ואתה מתכנן להריץ מספר קונטיינרים קטן ללא Scheduler ואתה מוכן לעשות את העבודה הנוספת להגן על הקונטיינרים (הם לא מספיק מאובטחים בברירת מחדל, אם אתה מחפש להריץ קונטיינר עם פורט 80 החוצה, אתה ממש לא חייב להריץ את הקונטיינר כ-root). אם אתה משתמש ב-Kubernetes, אז יש לך Best Practice כיצד להגן על הקונטיינרים/POD וכו' ברמת התקשורת ואותנטיקציה, אבל Kubernetes עדיין לא יודע איך להגן בתוך הקונטיינר נגד פורץ. הפתרון של אינטל הוא נחמד אבל עד שיהיה פתרון ברמה של כלי שרץ על VM או בשילוב עם מערכת Management ל-VM (כמו vcenter ואחרים) אף חברה רצינית לא תיקח את הסיכון להשתמש בו.
לכן, הפתרון שאני ממליץ עליו כיום מבחינת קלות שימוש, נוחות ומה שהכי חשוב – אבטחה, הוא הפתרון של OpenShift Origin (כגרסת קוד פתוח) או OpenShift Enterprise כגרסה מסחרית. גרסת הקוד הפתוח להתקנה על ברזלים/VM מצריכה שימוש באוטומציה כמו Ansible. ירסת הדגמה ניתן להרים על VM יחיד או על הלינוקס שלך בדסקטופ. ראו בוידאו הבא כיצד לעשות זאת
מאת: חץ בן חמו,
http://linvirtstor.net
כאשר עסקים וחברות מעוניינים לעבור לקונטיינרים, אחד האספקטים החשובים להם ביותר הוא אבטחת מידע. אז מה קורה כשאני חושף קונטיינר מסוים לעולם? איך אני מונע מפורץ כניסה לקונטיינר, וכיצד מונעים ממנו לחדור הלאה, לגנוב מידע ועוד?
טכנית, אלו שמכירים יוניקס ולינוקס משנים קודמות, מכירים בוודאי את chroot ובמקרים רבים אנשים נוטים לחשוב שקונטיינרים הם בדיוק כמו להריץ chroot (כלומר להקים file-system ועליו להריץ את פקודת chroot על מנת לתת "מערכת הפעלה" נוספת), אך למען האמת, Docker משתמש בהרבה יותר מזה כדי להריץ קונטיינר שיכול להיות מאובטח (יש צורך בעבודה נוספת על מנת לאבטח, אפשר לקרוא על כך כאן).
העניין הוא שברוב המקרים בחברה לא יריצו קונטיינר יחיד. אם יש לדוגמא אפליקציה וובית (Web), ברוב המקרים היא תהיה מחוברת ל-DB שירוץ על קונטיינר אחר, וההרצה תבוצע ע"י Container Scheduler כמו Mesos, OpenShift, Kubernetes, Docker-Swarm ועוד – הם ירימו את הקונטיינרים וינהלו את הכל.
אז מהם פתרונות האבטחה הקיימים? אציג מספר דוגמאות:
• אינטל מציעה את Clear Container (בגרסה 2.1.4 ששוחררה לאחרונה). היתרון של Clear Container בהשוואה לקונטיינרים של Docker הוא בכך שכל קונטיינר של Clear Container הוא בעצם מכונה וירטואלית (VM) שבתוכה מותקנת ורצה האפליקציה. משמע, בשביל להריץ Clear Container, תצטרכו להריץ זאת על Bare Metal (כלומר על "ברזלים") בלבד ולא על VM (יש כמובן Nested Virtualization לכל תוכנת וירטואליזציה, אבל אף חברה לא תשתמש בזה באופן רציני בפרודקשן לדוגמא). הבעיה הראשונה שאני רואה היא ששום חברה לא תסכים שמערכת תקים מכונות VM "על הברזל" בלי מערכת שתנהל את אותם VM מבחינת משאבים, ניטור ובכלל – ללא פתרון כמו vCenter שיש מ-VMWare למכונות VM – אף אחד רציני לא יכנס לזה.
האם הפתרון של אינטל יכול להשתמש ב-Kubernetes? כן אבל זה ממש לא מוכן לפרודקשן.
• Kubernetes בעקרון נוקט שיטת אבטחה של "הכל סגור". בברירת המחדל, כאשר אתה מקים קונטיינרים או POD, אינך יכול לגלוש אל האפליקציה שרצה בקונטיינרים או ב-POD ועליך "לחשוף" פורטים מסוימים או להשתמש ב"שרות חשיפה" כמו LoadBalancer או NodePort (שמאפשר לפתוח פורטים מסויימים שיתחברו אל ה-Load Balancer החיצוני שלכם) או ClusterIP. החסרון ב-Kubernetes הוא שזו מערכת Multi Platform שאינה מכירה בחלק מתכונות אבטחה שה-Kernel והמערכת יכולים לתת (כמו SELinux – גם בגרסה הנוכחית Kubernetes עדיין לא מאפשר לעבוד עם זה). Kubernetes מכיר כמובן ב -namespaces ו- cgroups כדבר שנותן אבטחה, אבל לחברות רבות זה לא מספיק.
• OpenShift מכיל את Kubernetes ומערכת Openshift בעצם "עוטפת" את Kubernetes ומוסיפה לו בדיוק את הדברים שחברות מחפשות מבחינת אבטחה. כך לדוגמא אין אפשרות להריץ התקנת Openshift על שרתים מבלי להפעיל SELinux ו-NetworkManager כך שמראש המערכת מקימה קונטיינרים ושאר דברים בצורה מאובטחת כברירת מחדל.
• מה עם Mesos? אני לא מומחה ב-Mesos אבל לפחות לפי כמה שהכרתי אותו, ישנה אבטחה ברמה של הקמת ותקשורת בין קונטיינרים (עם Auth), אבל אינני רואה שם שום דבר שיכול בעצם למנוע מפורץ שנמצא בקונטיינר – "לצאת החוצה", כלומר הכל תלוי בבנייה ידנית שלך לקונפיגורציות של הקונטיינר, שימוש בתכונות אבטחה של ה-Kernel (ראו לינק ראשון בפוסט זה) וכו'. אין SELinux, AppArmor שיכולים למנוע דברים גם אם המשתמש השיג root מקומי בתוך הקונטיינר.
• לגבי Docker-Swarm: אנשים לא אוהבים שאני אומר את זה, אבל מבחינת אבטחה ב-Docker Swarm, אין ממש הרבה. כן, אתה יכול לבנות רשת מוצפנת (IPSEC), אבל זה לא עוזר אם מישהו נכנס לקונטיינר ויש לו עכשיו גישה לקונטיינר עם ה-DB. זה נחמד שיש הצפנה, אבל הפורץ נכנס אחרי שיש כבר הצפנה והרשת בין הקונטיינרים פועלת באופן שקוף (כבר בוצע Authentication). אז נכון, הוא לא יוכל לפתוח כניסות חדשות, אבל הוא בהחלט יכול להשתמש בכניסות קיימות (פורטים) ואולי לא לגרום לנזק לכל המערכת אלא רק לקונטיינרים שאליהם הקונטיינר שהוא נכנס מחובר. בקיצור, דעתי האישית לגבי Docker-Swarm, היא שהוא לוקה בחסר במבחינת אבטחה.
אז האם Docker עצמו יכול להיות מאובטח? בהחלט כן, במידה ואתה מתכנן להריץ מספר קונטיינרים קטן ללא Scheduler ואתה מוכן לעשות את העבודה הנוספת להגן על הקונטיינרים (הם לא מספיק מאובטחים בברירת מחדל, אם אתה מחפש להריץ קונטיינר עם פורט 80 החוצה, אתה ממש לא חייב להריץ את הקונטיינר כ-root). אם אתה משתמש ב-Kubernetes, אז יש לך Best Practice כיצד להגן על הקונטיינרים/POD וכו' ברמת התקשורת ואותנטיקציה, אבל Kubernetes עדיין לא יודע איך להגן בתוך הקונטיינר נגד פורץ. הפתרון של אינטל הוא נחמד אבל עד שיהיה פתרון ברמה של כלי שרץ על VM או בשילוב עם מערכת Management ל-VM (כמו vcenter ואחרים) אף חברה רצינית לא תיקח את הסיכון להשתמש בו.
לכן, הפתרון שאני ממליץ עליו כיום מבחינת קלות שימוש, נוחות ומה שהכי חשוב – אבטחה, הוא הפתרון של OpenShift Origin (כגרסת קוד פתוח) או OpenShift Enterprise כגרסה מסחרית. גרסת הקוד הפתוח להתקנה על ברזלים/VM מצריכה שימוש באוטומציה כמו Ansible. ירסת הדגמה ניתן להרים על VM יחיד או על הלינוקס שלך בדסקטופ. ראו בוידאו הבא כיצד לעשות זאת
מאת: חץ בן חמו,
http://linvirtstor.net
לפרטים נוספים ויצירת קשר עם נציג אורקל
הודעתך לא התקבלה - נסה שוב מאוחר יותר