ניהול עם אופטימיזציה מסייע לתפעול אמין יותר של קונטיינרים – חלק ב'

כתב: אנדריאס ניב, ארכיטקט ראשי לתחום השירותים הפיננסיים ברד-האט (Red Hat)

ניהול מחזור חיים

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

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

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

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

אבטחה

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

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

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

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

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

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

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

חלקה השלישי והאחרון של הכתבה יתפרסם מחר.

לחלק א' לחצו כאן.