ארכיטקטורה לאבטחת גישת SSH עבור מכולות Docker במצב ללא שורש

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

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

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

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

האתגר הטכני המרכזי במימוש סכימה זו ב-Docker במצב rootless נובע מכך שמזהה המשתמש (UID) של התהליך בתוך המכולה אינו תואם למזהה המשתמש שלו במארח. בעיה זו מקשה על עיגון רגיל של SSH_AUTH_SOCK עבור תהליך עם מזהה משתמש שאינו שורש.

חלופה אפשרית היא ביטול גישת ה-SSH מהמכולה והעברת העבודה עם Git או מערכות חיצוניות לשירות API נפרד, כגון שרת MCP עבור סוכני בינה מלאכותית. עם זאת, פתרון זה אינו תמיד מהווה תחליף מלא ל-git מקומי, שכן הוא יוצר שתי מערכות קבצים נפרדות הדורשות סנכרון מצב קבצים, למשל באמצעות volume משותף.