הגדרת ניהול סודות באמצעות Doppler עם אינטגרציה ל-K8s ו-CI/CD

למה סודות דולפים מצינורות CI/CD ומה הקשר ל-Doppler

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

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

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

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

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

מה נותן קונטור אחיד לניהול סודות

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

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

צמצום פעולות ידניות וזמן פריסה

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

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

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

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

איך Doppler מספק סודות: השוואת מצבים

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

סודות סטטיים, דינמיים וקצרי מועד

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

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

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

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

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

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

ביקורת וספירת מלאי

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

בדיקה ומסירה לתפעול

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

מה נשאר אצלכם אחרי הטמעת Doppler

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

תרשימים, קונפיגורציות ומדיניות גישה

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

מקרה בוחן: הוצאת סודות מריפוזיטוריז וצינורות

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

מה היה לפני

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

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

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

מה קרה אחרי

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

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

במה Doppler שונה מסודות בתוך האורקסטרטור

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

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

ההבדל ניכר בחתך של תחומי שימוש.

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

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

שאלות טכניות שנשאלות לפני תחילת העבודה

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

איך להעביר סודות בלי השבתה?

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

מי בתוך הצוות רואה את הסודות?

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

מה יקרה אם נחליף קבלן?

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

האם נצטרך לשכתב את צינורות הבנייה?

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

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

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

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

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

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