הגדרת סריקת תמונות Docker באמצעות Anchore Engine

Anchore Engine: היכן נכשלת בדיקת תמונות Docker

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

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

Anchore Engine סוגר בדיוק את החור הזה: סריקת תמונות docker מתבצעת לפי סכום בקרה (checksum) ולא לפי תג, והתמונה עצמה מפורקת לשכבות עם מלאי של חבילות מנהל המערכת ותלויות שפה.

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

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

מה נותנת סריקת תמונות בצינור הבנייה

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

• כיסוי הבניות. בעבר בדקו באופן סלקטיבי, לפי בקשה או לפני שחרור גדול; כעת כל תמונה מקבלת פסיקה לפני פרסום ב-registry. תמונה ללא חוות דעת פשוט לא ממשיכה הלאה.
• זמן לבדיקה ידנית. ניתוח הדוח אורך דקות במקום שעות של סקירה ידנית של רשימת החבילות והמניפסטים. ההערה מגיעה למי שבונה את התמונה, ולא למי שתורן אחר כך בלילה.
• בדיקת תלויות לפי שכבות. ניכר החבילה הספציפית והגרסה שלה שבגללן הבנייה אינה עוברת. התיקון מצטמצם בדרך כלל לשורה אחת בתיאור הבנייה, ולא לבנייה מחדש של השירות כולו.
• סוג כשל נעלם. כלל הקבלה חוסם פרסום של תמונה עם רמת פגיעות קריטית — התרחיש «לפרודקשן יצא משהו שאיש לא בדק» נסגר בשלב הבנייה.
• חריגים תחת שליטה. במקום הסכמה שקטה — רשומה עם סיבה ומועד בחינה מחדש. רישום החריגים מצטמצם עם הזמן, מפני שכל אחד מהם נראה על פאנל משותף.
• מגמה במקום חתך חד-פעמי. לפי השחרורים ניכר אם מספר הפגיעויות גדל ומה בדיוק מושך אותו: תמונת בסיס מזדקנת או ספרייה ספציפית. זה כבר בסיס להחלפה מתוכננת, ולא לטיפול בהול.

את סף התגובה ורשימת החריגים מתאימים לשירות: עבור כלי פנימי ועבור API ציבורי רמות הקבלה שונות.

מצבי סריקת תמונות ומגבלותיהם

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

מצבים ומגבלותיהם

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

סדר ההטמעה: מביקורת ה-registry ועד מסירת הנהלים

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

1. ביקורת רישום התמונות. אוספים רשימה של מאגרים ותגים פעילים, מסמנים ארכיוניים וכפולים. בפלט — מפת המלאי עם עדיפות: מה בודקים בכל פרסום ומה באופן חד-פעמי.
2. תרשים החיבור ל-registry. פורסים את Anchore Engine לצד ה-registry, מנפיקים חשבון לקריאה בלבד ומגדירים משיכת התמונה לפי אירוע פרסום תג — בנייה חדשה נכנסת מיד לתור הבדיקה.
3. כללים וספים. ממיינים את הממצאים לפי חומרה וסוג: פגיעויות בשכבה ההרצה, חבילות מיושנות, סודות בתוך שכבות. את סף החסימה בוחרים כך שיתפוס סיכון אמיתי, אך לא יופעל על כל תלות.
4. חריגים. עבור ממצאים שלא ניתן לסגור במהירות, קובעים חריג ממוקד עם מועד ובעלים במקום פטור כללי מכלל.
5. הרצת ניסיון על בניות חיות. מריצים את הבדיקה על הענפים הנוכחיים ללא חסימות, משווים את הפסיקות לניתוח ידני, מסירים התראות שווא.
6. מצב חוסם. הבדיקה נעשית לשער לפני ההעלאה: תמונה עם ממצא קריטי אינה יוצאת לסביבת הפרודקשן, והחזרה נשארת לתג המאומת הקודם.
7. מסירת נוהל הבדיקות. מוסרים מטריצת ספים, סדר ניתוח ממצאים, כללי חריגים והוראות לעדכון מאגר הפגיעויות.

תוצרי ההטמעה: קונפיגורציות, תרשימים ונהלים

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

• קובצי קונפיגורציה — פרמטרי הסורק, מקורות מאגרי הפגיעויות, לוח זמנים לסריקת תמונות, עומק ותקופת שמירת התוצאות.
• תרשים האינטגרציה — השרשרת «registry → בנייה → סריקה → אישור להעלאה» עם נקודות כשל ותיאור ההתנהגות כשהסורק אינו זמין.
• מדיניות חסימה — אילו סוגי פגיעויות עוצרים את השחרור, מה עובר לחריגים, עם איזה מועד בחינה מחדש ומי מסיר אותם.
• נוהל תגובה — רמות חומרה, מועדי תגובה של משמרת התורן, סדר הסלמה, תבנית רשומת תקרית.
• הוראות תפעול — עדכון מאגרי פגיעויות, רוטציית הרשאות ל-registry, בדיקת תקינות, ניתוח כשלים אופייניים.
• דוח קו בסיס — אילו תמונות כבר מפרות את המדיניות במועד המסירה ואיזה היקף עבודה נותר לסגור.
• מטריצת תפקידים והרשאות — מי משנה את המדיניות, מי רק קורא דוחות וכיצד פעולות אלה נרשמות בלוג.

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

מקרה בוחן: הרחקנו תמונות פגיעות מהפרודקשן

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

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

מדדים לפני ואחרי

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

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

במה Anchore Engine שונה מסורקים ב-registry

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

Anchore Engine — שירות נפרד: מפרק את התמונה לשכבות, אוסף רשימת חבילות וגרסאות של מערכת ההפעלה ומעריך אותה לפי כללים שכותבת הצוות שלכם. הבדיקה מתבצעת לא רק בעת השליחה, אלא גם לפי לוח זמנים — רשומה חדשה במאגר הפגיעויות ממירה תמונה שכבר שוחררה לסטטוס «יש ממצאים» ללא בנייה מחדש.

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

שאלות טכניות על סריקת תמונות

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

הבדיקה תאריך את הבנייה?

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

התראות שווא יחסמו את השחרור?

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

מה לעשות עם תמונות שכבר נפרסו?

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

נדון במשימת סריקת התמונות שלכם

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

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

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