חתימת אימג'ים של Docker עם Cosign: Sigstore, Keyless, Kyverno

מדוע חתימה על אימג'ים של Docker נשברת בשלב הפריסה

כשל קלאסי נראה כך: הבנייה הסתיימה, האימג' נשלח ל-registry תחת תג צף, וכעבור שעה בצומת בסביבת העבודה מורצת קבוצה אחרת לגמרי של שכבות.

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

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

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

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

נבחן איך זה נסגר: חתימה על אימג'ים של Docker, Keyless דרך Sigstore ומדיניות Kyverno, שמכניסות לאשכול רק את מה שנבדק.

מה נותנת שרשרת אספקה ניתנת לאימות: אפקט בגדלים מדידים

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

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

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

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

חתימת ארטיפקטים: מצב מבוסס מפתח, ללא מפתח והיברידי

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

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

הטמעה שלב אחר שלב: מביקורת הצינור ועד מסירה לתפעול

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

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

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

3. הגדרת חתימה. Cosign חותם על האימג' לאחר הפרסום, והרשומה נשלחת ליומן השקיפות. בודקים בשירות אחד שתגים ו-digests לא נפרדים.

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

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

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

ערכת מסירה: מדיניות קבלה, סכימות ונוהלים

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

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

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

מקרה בוחן: הסרנו החלפת ארטיפקטים בין בנייה לפריסה

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

חתימה על אימג'ים של Docker הוטמעה באותו צינור: הפריסה מתבצעת לפי digest ולא לפי תג, וכל בנייה מקבלת אישור קצר-חיים במצב keyless Sigstore — מפתח ארוך-חיים לא נשמר. בכניסה לאשכול מדיניות Kyverno דוחה אימג' אם החתימה לא תקפה או הונפקה על ידי צינור אחר.

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

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

באילו הסתייגויות התוצאה ישימה

הסכימה עובדת במקום שבו הבנייה централізована ויש לה חשבון משלה. אם חלק מהשירותים נבנים על ידי צוותי קבלן, מתחילים במצב אזהרה: המדיניות כותבת אירוע ליומן אבל לא חוסמת את הפריסה — ומפעילים חסימה אחרי שכל הענפים חתומים. עבור registry-ים פרטיים מגדירים בנפרד אמון ברשות האישורים, אחרת אימג'ים לגיטימיים לא יעברו בדיקה.

במה בדיקה בזמן פריסה שונה מבדיקה במאגר?

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

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

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

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

ספקות טכניים של מהנדסים: מפתחות, ביטול, מקורות מהימנים

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

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

אימג'ים לא חתומים שכבר נפרסו — למחוק?

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

איך נקבע מקור מהימן?

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

מי הבעלים של מדיניות הקבלה?

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

נדון במשימה: ננתח את הצינור שלכם ונחזור עם תוכנית

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

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

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