רשימת בדיקה מעשית לאבטחת בידוד Docker לאירוח רב-דיירים

סיכום

אירוח Docker רב-דיירים דורש בידוד חזק כדי למנוע בריחות ממכולות. מאמר זה מספק רשימת בדיקה מעשית לאבטחה המכסה שישה תחומים עיקריים: הרצה כלא-root, ביטול יכולות, החלת פרופילי seccomp, הפעלת מיפוי מחדש של מרחב שמות משתמש, הגדרת מגבלות משאבים ושימוש במערכת קבצי שורש לקריאה בלבד. כל שלב כולל דוגמת תצורה קונקרטית ל-Docker Compose. תלמד גם על מלכודות נפוצות כמו בעיות תאימות ליבה עם מרחבי שמות משתמש ופשרות ביצועים בעת החלת seccomp. על ידי ביצוע רשימת בדיקה זו, תוכל להפחית משמעותית את משטח התקיפה מבלי להוסיף מורכבות מיותרת. המאמר מסתיים בתצורת בסיס מומלצת לסביבות ייצור רב-דיירים.

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

1. הרץ מכולות כמשתמש שאינו root

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

FROM alpine:3.18
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
USER appuser

ב-Compose, ניתן גם להגדיר את המשתמש ישירות:

services:
  app:
    image: myapp
    user: "1000:1000"

אזהרה: יישומים מסוימים דורשים root לפעולות לגיטימיות (למשל, קשירה לפורטים מתחת ל-1024). השתמש ב-CAP_NET_BIND_SERVICE במקום להריץ את כל המכולה כ-root. לעיון מעמיק בבסיסי הבידוד, ראה את המדריך שלנו בנושא השגת בידוד אמיתי רב-דיירים ב-Docker.

2. בטל את כל היכולות והוסף רק את הדרושות

יכולות Linux מעניקות למכולות הרשאות מפורטות. כברירת מחדל, Docker מעניק סט של יכולות. בטל הכל והענק רק את הדרושות.

services:
  app:
    image: myapp
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE  # if needed

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

3. החל פרופיל Seccomp

Seccomp (מצב חישוב מאובטח) מסנן קריאות מערכת הזמינות למכולה. Docker מגיע עם פרופיל seccomp ברירת מחדל החוסם קריאות מערכת מסוכנות כמו clone עם דגלים מסוימים. ניתן להתאים אישית עוד יותר.

services:
  app:
    image: myapp
    security_opt:
      - seccomp=/path/to/custom-profile.json

פרופיל מחוזק עשוי לחסום unshare, ptrace ו-mount. התחל עם ברירת המחדל של Docker והגבל יותר. אזהרה: פרופילים מחמירים מדי עלולים לשבור יישומים. בדוק ביסודיות בסביבת staging. לעוד על הגנות מפני בריחת מכולות, קרא הגנה מפני בריחת מכולות.

4. הפעל מיפוי מחדש של מרחב שמות משתמש

מרחבי שמות משתמש ממפים את משתמש ה-root של המכולה למשתמש מארח לא מורשה. המשמעות היא שגם אם תוקף משיג root בתוך המכולה, אין לו הרשאות מיוחדות במארח.

הפעל אותו על דמון Docker על ידי עריכת /etc/docker/daemon.json:

{
  "userns-remap": "default"
}

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

5. הגדר מגבלות משאבים עם Cgroups

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

services:
  app:
    image: myapp
    deploy:
      resources:
        limits:
          cpus: '0.5'
          memory: 512M

עבור Docker Compose v3, השתמש בקטע deploy (עובד עם swarm או compose v2). עבור Docker רגיל, השתמש ב---memory ו---cpus. אזהרה: הגדרת מגבלות נמוכות מדי עלולה לגרום להריגות OOM. עקוב אחר השימוש והתאם בהתאם.

6. השתמש במערכת קבצי שורש לקריאה בלבד

מערכת קבצי שורש לקריאה בלבד מונעת מתוקפים לכתוב קבצים זדוניים או לשנות קבצי תצורה בתוך המכולה.

services:
  app:
    image: myapp
    read_only: true
    tmpfs:
      - /tmp:noexec,nosuid,size=64m

הרכב tmpfs על ספריות הזקוקות לגישת כתיבה (כמו /tmp). זה מאלץ את כל הנתונים הניתנים לכתיבה להיות זמניים. אזהרה: יישומים מסוימים דורשים אחסון מתמשך; השתמש בכרכים בעלי שם לשם כך.

מלכודות נפוצות

• תאימות ליבה: מיפוי מרחב שמות משתמש וכללי seccomp מסוימים דורשים ליבת Linux עדכנית (4.14+). בדוק את גרסת הליבה שלך.
• השפעה על ביצועים: Seccomp ומרחבי שמות משתמש מוסיפים תקורה קטנה, אך היא זניחה עבור רוב העומסים. בצע בדיקות ביצועים על היישום הספציפי שלך.
• מורכבות: הוספת כל ששת האמצעים בבת אחת עלולה לשבור דברים. החל אותם אחד אחד, בדוק כל שינוי.

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

סיכום

מארח Docker רב-דיירים מאובטח אינו דורש כלים אקזוטיים—רק שימוש נכון בתכונות המובנות של Docker. התחל עם משתמש שאינו root, בטל את כל היכולות, החל פרופיל seccomp, הפעל מיפוי מרחב שמות משתמש, הגדר מגבלות משאבים והשתמש במערכת קבצים לקריאה בלבד. רשימת בדיקה זו מהווה בסיס חזק החוסם את טכניקות הבריחה הנפוצות ביותר. לאחר היישום, הפעל כלי אבטחה כמו docker-bench-security כדי לוודא את התצורה שלך. זכור: אבטחה היא תהליך, לא מוצר. ככל שפגיעויות ליבה חדשות צצות, חזור על ההגדרות שלך. לדפי נחיתה אוטומטיים המציגים את שירות האירוח שלך, השתמש ב-Pagenza כדי להעלות את האתר שלך לאוויר תוך דקות.