אני בטוח שזה קרה לך: אתה מנסה להרכיב מיכל לשימוש אישי, אתה רוצה להפוך אותו לבטוח יותר בעת השימוש בו. מכולות לא מורשעות ופתאום, אתם מוצאים את עצמכם לכודים במבוך של שגיאות הרשאה. זה מתסכל לבזבז שעות בהגדרת תיקיות בספריית הבית של המשתמש רק כדי לגלות שהקונטיינר לא יכול לכתוב אליהן, או שכאשר הוא כן יכול לכתוב, הקבצים המתקבלים במארח פגומים. בלתי אפשרי לנהל כי הם שייכים למשתמש רפאים.
המציאות היא שבעוד שמיכון קונטיינרים האיץ את אספקת התוכנה, הוא פתח את הדלת לסיכונים ניכרים. על פי נתונים אחרונים, הרוב המכריע של תמונות הייצור נושאות [לא ברור - אולי "לא ברור" או "לא ברור"] נקודות תורפה קריטיותזה הופך את האבטחה לעמוד תווך שאינו ניתן למשא ומתן. זה לא רק עניין של מניעת האקרים לתקוף אותנו, אלא גם של הבנת אופן פעולת המערכת. בידוד תהליכי כדי שהתשתית שלנו לא תיהפך למסננת.
הבנת המערכת האקולוגית של אבטחת קונטיינרים
כדי להפסיק לנחש עם הרשאות, ראשית עלינו לדעת על מה אנחנו מגנים. הארכיטקטורה של קונטיינר מחולקת למספר שכבות קריטיות. ראשית, יש לנו את תמונה של המיכלשהוא התוכנית המקורית; אם זה פגיע, כל המופעים שתפרסו יהיו לא מאובטחים. לכן חיוני להשתמש תמונות של בסיס מהימן ולשמור עליהם מעודכנים.
אז ה- זמן ריצהאשר משמש כמתווך בין מערכת ההפעלה המארחת לבין היישום. אם זמן הריצה מיושן, הסיכון ל... בריחת מכולה עולה באופן דרמטי. לכך עלינו להוסיף תזמור, כמו Kubernetes, שבו ה- בקרת גישה מבוססת תפקידים (RBAC) זהו המחסום האמיתי היחיד מפני גישה לא מורשית לממשק ה-API של הניהול.
אנחנו לא יכולים לשכוח את מערכת הפעלה מארחתאם תוקף מצליח לפרוץ את ליבת המארח, הוא מחזיק במפתחות לכל הדומיין. ההמלצה כאן ברורה: השתמש ב- מערכת הפעלה מינימלית כדי להפחית את משטח ההתקפה. לבסוף, הרשת היא נקודת הכניסה הנפוצה ביותר; כמעט 30% מהפריצות מתרחשות עקב כשלים בקישוריות, כך ש- פילוח רשת והצפנת TLS/SSL הם חובה.
כאב הראש של הרשאות ומשתמש הבסיס
הבעיה האופיינית לחובבים היא תהליך העבודה עם אמצעי אחסון. יוצרים תיקייה, מרכיבים אותה, ואז, בום!, שגיאה. ההרשאה נדחתהזה קורה מכיוון שכברירת מחדל, קונטיינרים רבים מתחילים כ-root. כאשר אתה מנסה לאלץ את UID ו-GID ב-0 כדי לגרום להם להתאים למשתמש המארח שלך, אתה יוצר גשר מסוכן. אם המכולה לא מאפשרת לך להגדיר את המזהים האלה, תבזבז אחר צהריים שלם בניסיון להבין באיזה משתמש פנימי היישום משתמש כדי לבצע chown מדריך ל.
הפתרון היעיל הוא ליישם את עקרון הזכות הקטנה ביותראסור להריץ שום דבר כ-root אלא אם כן זה הכרחי לחלוטין. כדי לפתור את בעיית הקבצים שנוצרו על ידי קונטיינרים שלא ניתן למחוק במארח, חיוני להגדיר את ה-Dockerfile באמצעות ההוראה הבאה: משתמש, הגדרת משתמש ללא הרשאות לפני הפעלת היישום.
אם אתה משתמש בפודמן, הקונספט של מיכלים חסרי שורשים זה מקורי ומאוד מועיל, אבל זה דורש שתבין כיצד משתמשי מארח ממופים למשתמשי קונטיינר. כדי למנוע מהרשאות לצאת משליטה, באופן אידיאלי האפליקציה צריכה להיות מתוכננת לכתוב לנתיבים ספציפיים ושה- מיפוי נפחים זה נעשה תוך התחשבות ב-UID האמיתי של המשתמש שמפעיל את התהליך.
אסטרטגיות לבניית תמונות משוריינות
אם אתם רוצים להפסיק לסבול, עליכם לשנות את האופן שבו אתם בונים את הדימויים שלכם. טכניקה אחת יעילה בצורה ברוטלית היא... בניינים רב-שלבייםבעיקרון, אתה משתמש בתמונה כבדה עם כל כלי הבנייה כדי ליצור את הקובץ הבינארי, ואז אתה מעתיק רק את הקובץ הזה לתמונה הסופית. קל במיוחד.
אפשר אפילו להמשיך הלאה בעזרת התמונה לגרדזה יוצר קונטיינר שאין בו שום דבר: בלי מעטפת, בלי מנהל חבילות, רק את האפליקציה שלך. זה הופך את זה כמעט בלתי אפשרי עבור תוקף לבצע פקודות זדוניות אם יצליח להיכנס, מכיוון אין מפרש פקודות זמין.
אמצעי אבטחה נוסף הוא ניקוי התמונה של כל קובץ בינארי עם הרשאות setuid או setgidהרשאות אלו מאפשרות להריץ קובץ עם הרשאות של בעל הקובץ ולא של המשתמש שמפעיל אותו, וזוהי דרך מהירה עבור... הסלמת הרשאותפקודה פשוטה לחיפוש והסרה של קטעים אלה במהלך בניית תמונה יכולה לחסוך לכם הרבה צרות.
הסכנות של מצב פריבילגי והיכולות של לינוקס
לפעמים, מתוך ייאוש מחוסר יכולת לפתור בעיית הרשאות, אנו נופלים בפיתוי להשתמש בדגל -חָסוּיתשכחו מלעשות את זה. מצב פריבילגי שובר את הבידוד של המכולה ומעניק לכם גישה מלאה למכשירים של המארח. זה כמו לתת את המפתחות לבית שלכם לזר רק בגלל שהוא לא ידע איך לפתוח את שער הגינה.
במקום זאת, כדאי לך לשחק עם ה- יכולות לינוקסDocker מקצה קבוצה של הרשאות ברירת מחדל (כגון CAP_CHOWN או CAP_NET_RAW). אם היישום שלך אינו צריך לתפעל את הרשת ברמה נמוכה, הגישה החכמה ביותר היא... לבטל יכולות מיותרות ולהוסיף רק את אלו הנדרשים באופן מוחלט על ידי --cap-add.
עבור אלו המנהלים סביבות רציניות יותר, ישנן תוספי הרשאה כגון opa-docker-authz. אלה מאפשרים יירוט קריאות ל-API של הדמון של Docker וחסימת כל ניסיון להפעיל מכולה במצב פריבילגי, מה שמבטיח שאף אחד, אפילו בטעות, לא ישאיר את הדלת פתוחה למארח.
אופטימיזציה ותחזוקה של הסביבה
אל תתעכבו על גודל התמונה של 5MB בעת שימוש ב-Alpine Linux אם זה גורם לבעיות תאימות עם הספריות. לפעמים תמונה גדולה מעט יותר של דביאן עדיפה. יציב וידוע על ידי הצוות. מה שחשוב הוא יישום של סריקת פגיעויות צינור CI/CD אוטומטי לזיהוי CVEs לפני שהתמונה מגיעה למצב הייצור.
בנוגע לאחסון, זה מונע מהאפליקציה לכתוב למערכת הקבצים הבסיסית. הגדר את ה- מערכת קבצים לקריאה בלבד (rootfs) ומגדיר אמצעי אחסון ספציפיים רק עבור הנתונים שצריכים להישמר. זה לא רק מאובטח יותר, אלא גם כופה ארכיטקטורה נקייה יותר, חסר אחוזההקלה על קנה מידה אופקי.
עבור תהליכים מתוזמנים, אל תשימו עבודת cron בתוך המכולה של האתר. כלל הזהב הוא תהליך אחד לכל מיכלהגישה הנקייה ביותר היא להשתמש בתמונה של האפליקציה שלך כדי להפעיל מכולה זמנית שמבצעת את המשימה ואז הורסת את עצמה, או לנהל את ה-cron מהמארח על ידי קריאה למנוע המכולה באמצעות פקודות.
אבטחת קונטיינרים היא תהליך מתמשך הכולל ביטול גישת root, הגבלת יכולות ליבה והסרת כלים מיותרים מתמונות קונטיינרים. על ידי שילוב משתמשים לא מורשים עם הקשחת זמן ריצה וניטור מתמיד, מושגת סביבה שבה פונקציונליות אינה פוגעת בשלמות מערכת המארח.
כותב נלהב על עולם הבתים והטכנולוגיה בכלל. אני אוהב לחלוק את הידע שלי באמצעות כתיבה, וזה מה שאעשה בבלוג הזה, אראה לכם את כל הדברים הכי מעניינים על גאדג'טים, תוכנה, חומרה, טרנדים טכנולוגיים ועוד. המטרה שלי היא לעזור לך לנווט בעולם הדיגיטלי בצורה פשוטה ומשעשעת.