לאיזה מאגר CA של Docker מצביע כשל ה-proxy?
הפרידו בין משיכת תמונות, הורדות בזמן build ובקשות של אפליקציית הקונטיינר כאשר סומכים על CA בדיקה מורשה.
הוספת CA ארגוני בתוך קונטיינר לא יכולה לתקן משיכת תמונה שנכשלה אצל עמית. משיכה מוצלחת גם אינה מוכיחה שהאפליקציה שבתוך התמונה סומכת על שירות ה-HTTPS הנבדק.
| פעולה | אמון שיש לבדוק |
|---|---|
| משיכת תמונה דרך פרוקסי הבדיקה של הארגון | המארח או סביבת Docker שמבצעת את המשיכה |
| הורדה בזמן build של תמונה | סביבת ה-build ומנגנון ההורדה שלה |
| קריאה לשירות HTTPS מהאפליקציה הפעילה | מאגר מערכת ההפעלה של התמונה או תצורת האמון של האפליקציה עצמה |
עקבו אחרי השגיאה עד לתהליך שמאמת את הצד השני, ואז אשרו את המנפיק, שם המארח ושלב ה-handshake. שירות בדיקה מורשה רשאי לחתום על תעודת היעד עם ה-CA של הארגון. כשל TLS במאזין proxy של HTTPS אינו אוטומטית כשל של תעודת היעד שאליה מגיעים דרכו. הזנת כתובת ה-IP של הפרוקסי אינה מספקת חומר אמון.
התקינו את תעודת המנפיק הציבורית המאושרת דרך המנגנון הנתמך של המארח, הפצת התמונה או האפליקציה הרלוונטית. ההנחיה של Docker בנושא CA מכסה מאגרי מארח וקונטיינר, אבל נתיב CentOS אינו הוראה ניידת ל-Debian או ל-Windows. עדכון יכול לבטל תוספת לחבילה שנוצרה; אפליקציית Java או לקוח אחר עם תצורת CA משלו עשויים להתעלם לחלוטין מחבילת מערכת ההפעלה.
לאמון אפליקציה מתמשך, הכניסו את השינוי לתהליך התצורה המאושר של התמונה או האפליקציה. עריכה אינטראקטיבית בקונטיינר אחד פעיל לא תופיע בקונטיינר הבא שנוצר מהתמונה.
הפיצו רק את תעודת האמון הציבורית הנדרשת דרך הערוץ המורשה. לעולם אל תכניסו מפתח פרטי של CA לתמונה ואל תתייחסו לבקשת התקנת root מפרוקסי ציבורי לא מוכר כהתקנה רגילה. השאירו את אימות שם המארח והשרשרת פעיל לאחר שהמאגר המיועד הוגדר.