ניהול סודות ב-GitHub Actions: הגנה על מפתחות API וסיסמאות בתוך Workflows
By Mirko Peters ·
למדו כיצד לאבטח את צינורות ה-CI/CD שלכם באמצעות שימוש נכון בסודות של GitHub Actions. גלו שיטות עבודה מומלצות לניהול בטוח של מפתחות API ואסימוני גישה.
Automatically translated with AI from the original post. Read the English original

כאשר האוטומציה שלכם פועלת לחלוטין ללא השגחה בענן, שמירה על פרטי ההזדהות הופכת לקריטית. ניהול יעיל של סודות GitHub Actions מבטיח שמפתחות ה-API, סיסמאות הפריסה ואסימוני הגישה שלכם לא יישמרו בקוד המקור, ועדיין יהיו נגישים בקלות ל-workflows שזקוקים להם כדי לבנות ולפרוס את הפרויקטים שלכם.
עיקרי הדברים
- לעולם אין לכתוב סיסמאות רגישות, מפתחות API או אסימוני גישה ישירות בקבצי ה-YAML של ה-workflow.
- GitHub מספקת שלוש רמות של סודות: סודות מאגר, סודות ארגון וסודות סביבה.
- סודות מוצפנים עוד לפני שהם מגיעים ל-GitHub, ומוסתרים אוטומטית ביומני ההרצה.
- סודות סביבה יכולים לאכוף שער אישור אנושי לפני שפרטי ההזדהות לפריסה נעשים זמינים ל-job.
- יש לפעול תמיד לפי עקרון ההרשאות המינימליות, ולהעניק לכל סוד את מספר ההרשאות הקטן ביותר הנדרש.
מדוע פרטי הזדהות בטקסט גלוי נכשלים ב-CI/CD
מפתה מפתחים הממהרים להקים צינור חדש להדביק מפתח API ישירות לקובץ התצורה של ה-workflow. after all, אם ה-workflow פרטי, מי בכלל יראה אותו? תפיסה זו יוצרת פגיעויות אבטחה חמורות. קבצי ה-workflow מנוהלים בבקרת גרסאות, כלומר כל גרסה היסטורית, כל commit וכל branch שומרים רשומה קבועה של כל מה שנכתב במסמכי ה-YAML האלה.
יתרה מזאת, מאגרים משנים לעיתים קרובות הרשאות, עוברים ממצב פרטי לציבורי, או עוברים fork על ידי תורמים. אם פרטי ההזדהות שלכם שמורים כמחרוזות בטקסט גלוי בתוך קובצי התצורה, שגיאת הגדרת הרשאה אחת עלולה לחשוף את כל סביבת הייצור שלכם. התייחסות לקובצי התצורה אך ורק כאל הוראות, תוך אחסון הנתונים הרגישים בכספת מוצפנת ונפרדת, היא הכלל היסודי של אבטחת ענן מודרנית.
שלוש הרמות של סודות GitHub
GitHub מכירה בכך שלפרטי הזדהות שונים יש היקפים שונים. כדי לעזור למפתחים לנהל את בקרת הגישה ביעילות, הפלטפורמה מאפשרת להגדיר סודות בשלוש רמות ארגוניות נפרדות.
סודות ברמת מאגר
סודות מאגר שייכים לפרויקט יחיד. אם אתם בונים אפליקציה עצמאית או מתחזקים plugin בודד, סוד מאגר שומר על מחרוזות החיבור ואסימוני הפריסה שלכם נעולים לאותו workspace ספציפי. פרויקטים אחרים בארגון שלכם אינם יכולים לגשת אליהם.
סודות ברמת ארגון
כאשר מספר מאגרים בתוך חברה צריכים לגשת לאותם משאבים משותפים, כגון registry מרכזי לקונטיינרים או תעודת חתימת קוד ארגונית, סודות ארגון חוסכים מכם שכפול של רשומות. מנהלים יכולים להגדיר מדיניות ולקבוע אילו מאגרים או צוותים רשאים לרשת את פרטי ההזדהות הארגוניים האלה.
סודות ברמת סביבה
סודות סביבה קושרים פרטי הזדהות ליעדי פריסה מסוימים, כגון סביבות staging או production. כאן מאחסנים את המפתחות הנדרשים כדי לגעת במערכות חיות. חשוב מאוד: סודות סביבה מאפשרים להגדיר בודקים נדרשים, כך שאדם חייב לאשר ידנית הרצת פריסה לפני שפרטי ההזדהות של הייצור יהיו זמינים ויועברו ל-runner.
כיצד GitHub מגנה על הנתונים שלכם בזמן העברה
האבטחה אינה מסתכמת במקום שבו נשמרים הסודות, אלא כוללת גם את האופן שבו הם נעים במהלך ההרצה. הסודות מוצפנים במחשב המקומי לפני שהם נשלחים ל-GitHub, כך שלעולם אינם מועברים ברשת בטקסט גלוי. לאחר השמירה, הם נשארים מוסתרים לגמרי מהתצוגה בממשק הגדרות המאגר.
כאשר זרימת עבודה (workflow) רצה, יש להעביר במפורש סוד לשלב או לפעולה לפי שמו, באמצעות תחביר ביטוי כגון ${{ secrets.DATABASE_URL } }. המשמעות היא שפעולה זדונית או לא אמינה מ-marketplace של צד שלישי אינה יכולה לקחת לעצמה באופן אוטומטי כל פרטי זיהוי מהמאגר. היא מקבלת רק את מה שמעבירים לה במפורש.
בנוסף, GitHub סורקת אוטומטית את יומני הפלט של המשימות (jobs) כדי להסתיר מחרוזות רגישות. אם הסקריפט שלכם מדפיס בטעות ערך של סוד לקונסולה, GitHub מנסה להחליף את התווים בכוכביות. עם זאת, מאחר שסקריפטים יכולים לשנות או להצפין מחרוזות לפני ההדפסה, הסתמכות בלעדית על הסתרה ביומנים אינה תחליף לכתיבת קוד מאובטח.
שיטות עבודה מומלצות לאוטומציה מאובטחת
ניהול סודות של GitHub Actions בצורה יעילה דורש אימוץ של הרגלים יומיומיים מסוימים. ראשית, יש להבחין תמיד בין הגדרת תצורה לבין סוד. אם הערך הוא פשוט כתובת אתר ציבורית, שם סביבה או דגל תכונה שאינו רגיש, שמרו אותו בטקסט גלוי בתוך קובץ ה-YAML, כדי שהצוות יוכל לקרוא בקלות כיצד פועל צינור העבודה. את מנגנון הסודות יש לשמור אך ורק לנתונים שחייבים להישאר חסויים.
שנית, אמצו את עקרון ההרשאות המינימליות. צרו אסימוני גישה מפורטים (fine-grained) עם תוקף קצר ככל האפשר והיקף הרשאות צר ככל האפשר. אם אסימון פריסה צריך רק לכתוב ל-S3 bucket אחד מסוים, אל תעניקו לו הרשאות ניהול על כלל תשתית הענן שלכם.
סיכום
שליטה בניהול סודות של GitHub Actions הופכת את צינורות ה-CI/CD שלכם מסיכון אבטחתי פוטנציאלי למנועי אוטומציה חזקים ברמה ארגונית. על ידי הפרדת פרטי הזיהוי מהקוד וניצול בקרות גישה רב-שכבתיות, תוכלו לשחרר תוכנה במהירות מבלי לוותר על אבטחה.
כדי להכיר את יסודות בניית זרימות העבודה האוטומטיות, עיינו ב-האזינו לפרק המלא. הצטרפו לדיון המלא כדי ללמוד עוד על הגדרת טריגרים, משימות (jobs) ורצים (runners) לסביבת הענן המודרנית שלכם!
שאלות נפוצות
האם אפשר לקרוא סוד של GitHub Actions בבקשת משיכה (pull request) שמגיעה מ-fork?
כברירת מחדל, GitHub מונעת מבקשות משיכה של תורמים חיצוניים (forks) לגשת לסודות המאגר שלכם, כדי למנוע הרצה של קוד זדוני וגניבת פרטי הזיהוי שלכם.
כיצד מעבירים סוד מזרימת עבודה לשלב ספציפי?
מעבירים סודות לזרימת העבודה באמצעות ההקשר 'env' בתוך שלב או משימה, תוך מיפוי הסוד של GitHub למשתנה סביבה, כגון env: API_KEY: ${{ secrets.MY_API_KEY } }.
האם מובטח שסודות של GitHub Actions יהיו מוסתרים ביומנים?
GitHub מסתירה אוטומטית ערכי סוד ידועים ביומני ההרצה, אך זו אינה ערובה מוחלטת. אם ערך של סוד עובר מניפולציה, הצפנה או טרנספורמציה לפני ההדפסה, חלקים ממנו עלולים להיחשף.
מה ההבדל בין סודות מאגר לסודות סביבה?
סודות מאגר זמינים לכל זרימת עבודה במאגר נתון, ואילו סודות סביבה מקושרים לסביבות פריסה מסוימות (כגון staging או production) ויכולים לדרוש אישורי בדיקה ידניים.