מידע על לוחות זמנים של סבבים

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

רוטציה תקופתית עוזרת בדרכים הבאות:

  • מגביל את ההשפעה במקרה של חשיפת סוד.

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

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

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

בדף הזה מפורטות המלצות להחלפת סודות שמאוחסנים ב-Secret Manager. תלמדו איך:

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

קישור גרסת סוד לאפליקציה

לסוד ב-Secret Manager יכולות להיות כמה גרסאות סוד. גרסאות של סודות מכילות את מטען הייעודי הבלתי ניתן לשינוי (מחרוזת הבייטים של הסוד בפועל), והן מסודרות וממוספרות. כדי להחליף סוד, מוסיפים גרסה חדשה של סוד לסוד קיים.

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

השקות הדרגתיות

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

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

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

גישה 1: פתרון במהלך תהליך הפצה קיים

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

כשמפעילים את האפליקציה, קוראים ל-Secret Manager עם שם הגרסה הספציפי של הסוד כדי לגשת לערך הסוד.

היתרונות של הגישה הזו:

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

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

  • אפשר להשיק את הערך בהדרגה כדי לצמצם את ההשפעה של פריסת ערכים לא טובים.

גישה 2: פתרון הבעיה בזמן הפעלת האפליקציה

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

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

גישה 3: פתרון בעיות באופן רציף

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

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

רוטציה של הסוד

אם אפשר לעדכן את הסוד באופן דינמי (לדוגמה, אם המערכת החיצונית שמאמתת את הסוד מספקת Admin API), מומלץ להגדיר משימת רוטציה שפועלת באופן תקופתי. השלבים הכלליים מפורטים בקטע הבא, עם Cloud Run כדוגמה לסביבת מחשוב.

הגדרת לוח זמנים להחלפה של הסוד

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

הפעלת Cloud Run כדי ליצור גרסה חדשה של סוד

יוצרים ומגדירים שירות Cloud Run לקבלת התראות על רוטציה ולהפעלת שלבי הרוטציה:

  1. משיגים או יוצרים סוד חדש במערכת החיצונית (לדוגמה, מסד נתונים, ספק API).

    מוודאים שלא מבטלים את התוקף של סודות קיימים, כדי שלא תהיה השפעה על עומסי עבודה קיימים.

  2. מעדכנים את Secret Manager עם הסוד החדש.

    יוצרים גרסה חדשה של סוד ב-Secret Manager. בנוסף, הפעולה הזו מעדכנת את הכינוי latest כך שיצביע על הסוד החדש שנוצר.

ניסיונות חוזרים ובו-זמניות

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

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

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

  • שימוש בתוויות בסודות כדי לשמור את המצב במהלך הרוטציה. מוסיפים תווית לסוד כדי לעקוב אחרי מספר הגרסה האחרונה שנוספה בהצלחה במהלך תהליך העבודה של הרוטציה (לדוגמה, ROTATING_TO_NEW_VERSION_NUMBER=3). אחרי שהרוטציה מסתיימת, מסירים את התווית למעקב אחרי הרוטציה.

  • משתמשים ב-etags כדי לוודא שתהליכים אחרים לא משנים את הסוד בו-זמנית במהלך תהליך העבודה של הרוטציה. מידע נוסף על תגי etag של סודות וגרסאות סודות

הרשאות לניהול זהויות והרשאות גישה (IAM)

תהליך הרוטציה דורש את ההרשאה secretmanager.versions.add כדי להוסיף גרסה חדשה של הסוד, ויכול להיות שהוא ידרוש את ההרשאה secretmanager.versions.access כדי לקרוא את הגרסה הקודמת של הסוד.

תהליך הרוטציה דורש את ההרשאה secretmanager.versions.add כדי להוסיף גרסה חדשה של הסוד, ויכול להיות שהוא ידרוש את ההרשאה secretmanager.versions.access כדי לקרוא את הגרסה הקודמת של הסוד.

לחשבון השירות שמוגדר כברירת מחדל ב-Cloud Run יש תפקיד עריכה, שכולל הרשאה להוסיף גרסאות של סודות, אבל לא לגשת אליהן. כדי לפעול בהתאם לעיקרון של הרשאות מינימליות, אנחנו ממליצים לא להשתמש בחשבון השירות שמוגדר כברירת מחדל. במקום זאת, צריך להגדיר חשבון שירות נפרד לשירות Cloud Run עם התפקידים ב-Secret Manager שנדרשים (יכול להיות תפקיד אחד או יותר):

  • roles/secretmanager.secretVersionAdder

  • roles/secretmanager.secretVersionManager

  • roles/secretmanager.secretAdmin

  • roles/secretmanager.secretAccessor

הפצת גרסת הסוד החדשה לעומסי עבודה

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

ניקוי גרסאות ישנות של סודות

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

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

  2. משביתים את הגרסה הישנה של הסוד ב-Secret Manager ומוודאים שהאפליקציות לא נשברות (מחכים פרק זמן סביר כדי לאפשר התערבות אנושית אם השבתה גורמת לבעיה בצרכן).

  3. מסירים את הגרסה הישנה של הסוד מהמערכת החיצונית או מבטלים את הרישום שלה.

  4. השמדת הגרסה הישנה של הסוד ב-Secret Manager

המאמרים הבאים