cert-manager ב-Kubernetes: מדוע תוקף תעודות TLS פג
חידוש תעודות TLS באשכול כמעט תמיד מוגדר — וכמעט תמיד נשבר בלי שמבחינים בכך. תעודה לתעבורה נכנסת קיימת לפרק זמן מוגבל, החידוש מתבצע כתהליך רקע, ובדיוק משום כך איש אינו עוקב אחריו: כל עוד השרשרת תקפה, המדדים נראים בריאים ואין שגיאות בלוגים.
לאחר מכן המועד האחרון חולף בשקט. האפליקציות פועלות, הדיפלוי תקין, אך הדפדפנים והלקוחות הניידים מסרבים להתחבר — וזה כבר לא כשל של שירות אחד, אלא הפסקה של תעבורה נכנסת בכל הדומיין.
לקוחות עם בדיקה קפדנית של שרשרת האמון קורסים עם שגיאת TLS, והנפקה ידנית של תעודות באותו רגע נמשכת שעות: צריך להספיק להנפיק תעודה חדשה, להכניס אותה ל-Secret ולהפעיל מחדש את ה-pods.
לסיטואציה כזו יש בדרך כלל שלוש סיבות. החידוש מוגדר, אך איש אינו מטפל בשגיאות אימות הבעלות על הדומיין: הרשומה עבור DNS-01 נותרה כשהייתה, הנתיב עבור HTTP-01 חסום על ידי כלל ניתוב או הגנה מפני בקשות חיצוניות — והבקר חוזר על הניסיון בשקט עד למועד האחרון.
הנפקה ידנית של תעודות מותירה Secrets עם השמות הקודמים והפניות לאובייקט הישן, ולכן השרשרת המחודשת פשוט לא מגיעה ל-pod. והתראה על כך שהתוקף עומד לפוג אינה מקושרת לאף ערוץ התראות.
המחיר של הזוטות האלה הוא אחד — אי-זמינות של השירות ברגע הכי פחות מתאים. נבחן כיצד זה נסגר ומה חייב להיות מוגדר לפני שהמועד האחרון יחלוף.
מה מניב ניהול אוטומטי של תעודות באשכול
באשכול התעודות מפסיקות להיות משימה ידנית: כל אחת מתוארת באופן הצהרתי — אובייקט Certificate מפנה ל-ClusterIssuer, והתוצאה נשמרת ב-Secret שאותו קורא ה-ingress. נקודת ניהול אחודה משמעה שהנפקה, אחסון ורוטציה מוגדרים במניפסט אחד, ולא במעבר בין פאנלים של שירותים שונים. הצמצום של פעולות ידניות נמדד במספר הצעדים: דומיין חדש הוא קומיט, ולא בקשה בתור.
החידוש האוטומטי של תעודות נשען על זמן החיים שנותר: הבקר רואה שנשאר פחות מחלק מוגדר עד לפקיעה, ומנפיק מחדש את התעודה מראש, תוך עדכון ה-Secret.
בקר ה-ingress קולט את התוכן החדש בלי הפעלה מחדש של ה-pods, ולכן הפחתת זמן ההשבתה היא לא «כמעט אפס», אלא בדיוק אפס: חלון החידוש כה רחב עד שניתוק החיבור כלל לא מתרחש.
האפקט העיקרי — סוג כשל שנמנע לחלוטין. תעודה שפג תוקפה ונשכחה בסביבת בדיקות, wildcard שחודש רק בסביבה אחת, חוסר סנכרון בין אשכולות — כל אלה מפסיקים להיות אירוע והופכים למשימה של הבקר.
גם התנהגות צפויה בעת עדכון המוני מובטחת: הבקשות לרשות האישורים נשלחות עם הגבלת קצב וניסיונות חוזרים, ולכן גל של הנפקות מחדש אינו הופך להפסקת שירות.
נותר הפיקוח: מדדים על תוקף התעודה, אירועים בעת כשל באימות הדומיין, התראה לפני ההגעה לתאריך הקריטי. מערך כזה הוא בדיוק צ'ק-ליסט הבשלות — חידוש בלי אדם, נקודת ניהול אחודה, אפס פעולות ידניות והיעדר סוג שלם של אירועים.
מצבי הפעולה של cert-manager ב-Kubernetes: השוואת גישות
<cite>cert-manager</cite> אינו מנפיק תעודות בעצמו — הוא מתאר את מקור החתימה באמצעות אובייקטים מסוג Issuer או ClusterIssuer, ו-Certificate מגדיר את הדומיינים ואת תוקף התעודה. מהבחירה של המקור תלויים הרוטציה האוטומטית, האמון מצד הלקוחות, ואופן ביטול התעודה בעת חשיפת המפתח.
המצבים משתלבים זה בזה בשלווה באשכול אחד: תעודות ציבוריות — לשירותים חיצוניים, רשות פנימית — לתעבורה בין שירותים, ותעודות חתומות עצמית — רק בסביבות זמניות. להלן ארבעה וריאנטים והמגבלות של כל אחד.
| וריאנט הנפקה | מתי מתאים | מגבלות |
|---|---|---|
| רשות אישורים ציבורית | דומיינים חיצוניים ולקוחות שאין להם תעודת שורש ארגונית | נדרש אימות בעלות על הדומיין, קיימות מגבלות על מספר ההנפקות, והתעודה נכנסת ליומנים ציבוריים |
| רשות אישורים פנימית של הארגון | שירותים בתוך הרשת, אימות הדדי בין שירותים | הלקוחות צריכים לתת אמון בתעודת השורש; נדרש נוהל הנפקה וביטול |
| מאגר סודות ארגוני | כבר קיים מאגר מפתחות מרכזי ודרישות לביקורת גישה | נדרש סנכרון בין מצב האשכול למאגר, וההרשאות ניתנות בנפרד |
| תעודות חתומות עצמית | סביבות בדיקה וזמניות, דיבוג | דפדפנים ולקוחות חיצוניים אינם נותנים אמון; לפרודקשן תעודה כזו אינה מועברת |
בפועל, באשכול אחד חיים בדרך כלל שניים-שלושה מצבים: קו חיצוני על רשות ציבורית, פנימי — על רשות עצמית, ותעודה חתומה עצמית נפרדת לבדיקות. את הבחירה מקבעים בסכמת המנפיקים ובמדיניות הרוטציה, כדי ששירות חדש לא ימשוך תעודה ידנית, ושהביטול ייארך דקות ולא שעות.
שלבי ההטמעה של חידוש תעודות אוטומטי
חידוש אוטומטי נשבר לא בהנפקת התעודה, אלא בקצוות: דומיין שנשכח להוסיף לתיאור, או מפתח פרטי בעותק יחיד. לכן שלבי ההטמעה בנויים מהמלאי ועד הקבלה — את התוצאה של כל שלב בודקים לפני שהיא נכנסת לקו הפעיל לפי חישוב אישיביקורת תצורת האשכול.
אוספים את כל הנקודות שבהן מסתיים החיבור המאובטח, מתעדים דומיינים, תוקפים ומקומות אחסון של מפתחות. בפלט — מרשם עם אחראי לכל רשומה. 2. סכמת אמון. מגדירים את רשות האישורים, את סדר הנפקת תעודות הביניים ואת שיטת האימות של הבעלות על הדומיין.
בנפרד מחליטים היכן מאוחסנים המפתחות וכיצד מתבצעת הרוטציה שלהם. 3. הגדרת ההנפקה. מתארים את התעודות באופן הצהרתי, מקשרים לדומיינים ומגדירים חלון חידוש עם מרווח — 30 יום לפני הפקיעה נותר זמן לטפל בתקלה ללא לחץ. 4. בדיקת החידוש על עותק של הקו.
מפעילים בכוח את המחזור בסביבת בדיקה: בוחנים את השרשרת, את סדר החלפת התעודה ואת התנהגות השירותים כשהמנפיק אינו זמין. 5. קבלה. מגדירים ניטור על תוקף התעודה והתראות מראש, ומריצים מחזור מלא בקו הפעיל בחלון מוסכם. 6. מסירה לתפעול. מוסרים את נוהל החידוש, את סכמת אחסון המפתחות ואת רשימת האחראים לתגובה להתראה.
מכאן ואילך החידוש מתבצע בלי פעולות ידניות, והכשל נראה לפני שהתעודה פגה.
מה נשאר לצוות לאחר הטמעת האוטומציה
אוטומציה בלי תיעוד יוצרת תלות במי שהגדיר אותה: המהנדס עוזב — והנפקת התעודות הופכת לקופסה שחורה בלתי מוסברת. לכן למסירה נכלל לא רק הקו הפעיל, אלא גם מערך של תוצרים שלפיהם המשמרת התורנית ואנשי צוות חדשים פועלים בלעדינו.
- סכמת האינטראקציה — כיצד בקשה לדומיין הופכת לתעודה מוכנה: שיטת אימות הבעלות, מקום אחסון המפתחות, הקשר בין ההנפקה לאובייקטים של הניתוב. תרשים בתוספת תיאור טקסטואלי של כל צעד.
- תיעוד התעודות — רשימה של כל האובייקטים המונפקים: דומיינים, סוגים (בודד, wildcard, עם מספר שמות), תוקף, אחראי על הדומיין והיכן התעודה משמשת.
- נוהל החידוש — כמה ימים לפני הפקיעה מתחיל החידוש, מה קורה בניסיון כושל, למי נשלחת ההתראה ובאיזה סדר מונפקת התעודה ידנית.
- מדיניות גישה — תפקידים והרשאות: מי משנה את הגדרות ההנפקה, מי קורא את הסודות, ולמי יש גישה לניהול רשומות ה-DNS לצורך אימות הבעלות.
- הוראות למשמרת התורנית — טיפול בכשלים טיפוסיים: תעודה שפג תוקפה, שגיאת אימות דומיין, מכסה שנגמרה אצל הספק החיצוני — עם ציון מה לבדוק ראשון.
- ניטור והתראות — דשבורד על תוקף התעודות והתראות על סף שבו עדיין נותר זמן להתערבות ידנית.
- נוהל חזרה לאחור — כיצד להחזיר את תצורת ההנפקה הקודמת וכיצד להשבית זמנית את האוטומציה מבלי להפיל את הניתוב.
המערך נבנה עבור הקו שלכם: שמות האובייקטים, כתובות הפאנלים ותחומי האחריות מוחלפים בשלכם, ולא נשארים דוגמאות מהתיעוד.
מקרה בוחן: כיצד הסרנו את החידוש הידני של תעודות
הקשר: סביבה מפוזרת — ארבעה קווים (פיתוח, בדיקות, קדם-פרודקשן, פרודקשן) ושלושה אזורים, כ-60 דומיינים ותת-דומיינים, כולל תעודות wildcard לשירותים פנימיים. התעודות הונפקו ידנית: מהנדס ניהל טבלת מועדים, הגיש בקשות לרשות האישורים ופרס את הקבצים בין מאזני העומס והבקרים. ברבעון הצטברו כמעט 40 פעולות, ופקיעה של תעודה אחת משמעה הפסקת הממשק החיצוני ושגיאות אצל הלקוחות.
cert-manager הותקן כאופרטור באשכול, וההנפקה תוארה באופן הצהרתי: מקור נפרד לכל סביבה, ומשותף — לדומיינים מהרמה העליונה. החידוש מתחיל 30 יום לפני הפקיעה, המפתח מתעדכן באותו מרחב שמות ונקלט בלי הפעלה מחדש של האפליקציה. בנפרד הוצג מדד של יתרת התוקף: אזהרה 21 יום מראש, התראה קריטית — 7 ימים מראש.
מה השתנה במספרים
- פעולות ידניות מתוכננות: כ-40 ברבעון → 0.
- אירועים בגלל תעודות שפג תוקפן: 9 בשנה → 0.
- הנפקת דומיין חדש: 2-3 ימים עם אישורים → 15-25 דקות מתיקון המניפסט ועד לתעודה מוכנה.
- שגיאות חידוש (אימות הבעלות על הדומיין אינו זמין, אזורים לא מסונכרנים) צפו בעבר ברגע הפקיעה — וכעת נראות בהתראה שלושה שבועות מראש; שיעור החידושים האוטומטיים המוצלחים בשנה — 100%.
ידניים נותרו רק החלפת ספק ה-DNS ומקרים חריגים חד-פעמיים — הם מתוארים בהוראה למשמרת התורנית, והטיפול נמשך דקות ולא שעות.
מה לעשות אם התעודות כבר מונפקות ידנית?
הגירה לאוטומציה היא לא מתג הפעלה, אלא רצף. בשלב הראשון שתי סכמות מתקיימות במקביל: cert-manager באשכול אינו נוגע ב-Secrets שכבר נוצרו, משום שהקשר בין תיאור ה-Certificate למאגר נוצר רק לפי שם ומרחב שמות שאתם עצמכם מגדירים. כל עוד אין תיאור, התעודות הידניות ממשיכות לעבוד ומתחדשות בסדר הקודם.
הצעד הראשון — בדיקה במרחב שמות שאינו ייצורי. מנפיקים תעודה לדומיין בדיקה באותה שיטה שבה יונפקו בהמשך תעודות הייצור: האם עובר אימות הבעלות על הדומיין, האם השרשרת המלאה נכנסת ל-Secret, האם בקר הכניסה קולט אותה בלי הפעלה מחדש של האפליקציות.
כך נבדקת לא רק ההנפקה, אלא גם ששרשרת האמון מלאה — אחרת הלקוחות יראו אזהרה שאי אפשר לתפוס בתוך האשכול.
כשהתוצאה תואמת את הצפוי, התיאורים מועברים לדומיינים האמיתיים בזה אחר זה: תחילה הקו הפחות עמוס, ואחר כך השאר. התעודות הידניות אינן נמחקות — הן נשארות כחזרה לאחור עובדת, עד שזו שהונפקה אוטומטית תעבור מחזור חידוש מלא.
החידוש הוא העיקר שלשמו כל זה נעשה. האוטומציה מעדכנת את ה-Secret מראש, לפני פקיעת התוקף, והאפליקציה קוראת את הקובץ החדש בלי התערבות ידנית. אם החידוש נכשל בגלל אי-זמינות של רשות האישורים או שינוי הרשאות, החזרה להנפקה ידנית דורשת פעולה אחת.
בנפרד נסגרות ההרשאות: הזכות לעדכן את ה-Secret ואת אובייקטי התיאור, הגישה לאזור הדומיין לצורך אימות הבעלות, ומרווח במספר הבקשות לרשות האישורים. בלי זה האוטומציה עובדת עד החלפת ה-DNS הראשונה או הרחבת ההרשאות — ושוב הופכת לידנית.
ספקות טכניים שכדאי להסיר לפני ההתחלה
לפני ההתחלה צפות בדרך כלל ארבע שאלות: היכן להנפיק את התעודות, מה לעשות עם שירותים מחוץ לאשכול, כיצד יעבור אימות הבעלות על הדומיין והאם החידוש יעבוד בלי התערבות ידנית. להלן תשובות קצרות שמסירות את רוב הספקות עוד לפני העבודה.
רשות אישורים חיצונית או פנימית?
רשות ציבורית חיצונית נלקחת לכל מה שרואים המשתמשים והלקוחות החיצוניים — הדפדפנים נותנים בה אמון בלי הגדרה נוספת. לשירותים פנימיים פורשים רשות אישורים משלנו: תעודת השורש נכנסת למאגרי האמון של הצמתים ומכונות הלקוח, וההנפקה מתבצעת בתוך הקו בלי תלות חיצונית.
סכמה משולבת היא נורמה: אובייקטים מנפיקים שונים לתעבורה חיצונית ופנימית, כדי שכשל של הרשות החיצונית לא יפגע בקשרים השירותיים.
מה לעשות עם שירותים מחוץ לאשכול?
תעודות מונפקות גם עבורם: את ה-Secret עם המפתח והשרשרת קורא מאזן עומס חיצוני או פרוקסי הפוך, או שהוא שולף את העדכון ממאגר משותף. קריטי הוא דבר אחר — ש� לאחר החידוש ה-Secret ייקרא מחדש על ידי התהליך, ולא יישאר בזיכרון עד להפעלה מחדש ידנית.
בודקים זאת בסביבת בדיקות: מקצרים את תוקף התעודה, ממתינים לעדכון אוטומטי ובוחנים אם הצרכן החיצוני קלט את התעודה החדשה.
כיצד יעבור אימות הבעלות על הדומיין?
דרך שרת ווב — אם הדומיין מצביע על האשכול ויש היכן להניח את קובץ הבדיקה. דרך DNS — אם נחוצות תעודות לקבוצת תת-דומיינים בבת אחת או שאין כניסה ציבורית כלל; אז האובייקט המנפיק זקוק להרשאות לשינוי רשומות אצל ספק ה-DNS, ואנחנו נותנים אותן בצמצום, רק לאזור הנדרש. עבור דומיינים פנימיים אין צורך באימות הבעלות.
כיצד להשתכנע שהחידוש יעבוד מראש?
החידוש מתחיל זמן ניכר לפני הפקיעה, ולכן התקלה מספיקה להיכנס לניטור, ולא לדוח על תקלה. מגדירים התראות על גיל התעודה, על שגיאות הנפקה ועל מיצוי ניסיונות אימות הבעלות, ובנוסף ריצת בקרה בקו בדיקות עם תוקף מקוצר. מכאן ואילך השאלה היא רק בגישה ל-DNS ובערוץ אימות גיבוי — אם הספק הראשי אינו זמין.
נדון במשימה שלכם ונחזור עם תוכנית
כדי שהערכת העבודה תישען על עובדות ולא על הנחות, אנחנו צריכים פריסה של התשתית שלכם: כיצד מונפקות התעודות כיום, היכן מאוחסנים המפתחות ומה בדיוק אמור להיכנס לאוטומציה. להלן מערך מינימלי של נתונים שממנו נבנית תוכנית הטמעה עניינית. אם משהו אינו בהישג יד, נבין זאת בשיחה ונדקדק בהתכתבות.
- הרכב הקווים. כמה אשכולות Kubernetes, היכן הם ממוקמים (ענן, שרתים עצמאיים, היברידי), כמה מרחבי שמות ונקודות כניסה של תעבורה יש לתחזק. מכך תלוי אם דרושה רשות מנפיקה משותפת אחת או נפרדת לכל קו.
- סכמת ההנפקה הנוכחית. מי מנפיק את התעודות כיום — ידנית, בסקריפטים או בשירות חיצוני; היכן מאוחסנים המפתחות הפרטיים; אילו סוגים נדרשים: דומיינים בודדים, wildcard, שמות פנימיים.
- רשימת השירותים בפרימטר. דומיינים ותת-דומיינים לאוטומציה עם ציון אילו ציבוריים ואילו נגישים רק מהרשת הפנימית. זה קובע את שיטת אימות הזכויות על הדומיין והיקף הבדיקות לאחר המיתוג.
- הרשאות ונקודות אינטגרציה. כיצד מוזנות רשומות ה-DNS, מי מנהל את האזורים, האם קיים מאגר סודות חיצוני וכיצד מתחברים אליו עומסי העבודה.
- מגבלות זמנים. תאריכים קשיחים, חלונות תחזוקה, מידת הסבילות להפסקה קצרה ב-TLS בעת המיתוג ודרישות ביקורת לתוקף המפתחות.
- ניסיון קודם. מה כבר ניסיתם, אילו אירועים היו עם פקיעת תעודות ומה בדיוק לא התאים בפתרון הקודם.
עם המערך הזה אנחנו מקבעים את היקף העבודה, את סדר השלבים, את נקודות החזרה לאחור ואת קריטריוני הקבלה. תארו את המשימה בפורמט נוח — נחזור עם הערכה ותוכנית.