GitHub Actions: מבנה תהליכים, גבולות אמון ו־OIDC

📘 סדרת העמקה ב־GITHUB

חלק 1: מאגרים, ענפים ובקשות משיכה ←
▸ חלק 2: GitHub Actions, תהליכי עבודה ו־OIDC — אתם כאן
חלק 3: חבילות, מרשם קונטיינרים ואבטחה ←

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

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

1. ההפשטות המרכזיות

GitHub Actions מבוסס על קבוצה קטנה של הפשטות מקוננות: אירוע מפעיל תהליך עבודה אחד או יותר; כל תהליך מכיל עבודה אחת או יותר; כל עבודה רצה על runner; וכל עבודה מכילה רצף שלבים המבצעים פקודות מעטפת או פעולות לשימוש חוזר.

היררכיית ACTIONS

אירוע: push, בקשת משיכה, תזמון או הפעלה

מפעיל

תהליך עבודה: ‎.github/workflows/*.yml

מכיל

עבודות — במקביל כאשר תלויות, בקרת מקביליות וקיבולת מאפשרות

רץ על

runner:‏ ubuntu-latest או self-hosted

מבצע

שלבים: run למעטפת או uses לפעולה

2. מבנה קובץ תהליך עבודה

קובצי YAML של תהליכים נמצאים תחת .github/workflows. הדוגמה להלן מיועדת ל־GitHub.com ולפרויקט עם סקריפטי npm שנבדקו וקובץ נעילת תלויות. היא אינה פורסת דבר. תגי גרסה ראשית הם המחשה קריאה, לא קיבוע בלתי משתנה: בדקו את הגרסאות הרשמיות והחליפו ב־SHA מלאים שנבדקו לפני אימוץ. דוח הכיסוי חייב להכיל רק מידע מאושר שאינו רגיש.

# Illustrative CI only; not installed or run here.
name: Example CI
on:
  push:
    branches: [main]
  pull_request:
  workflow_dispatch:
permissions:
  contents: read
jobs:
  test:
    runs-on: ubuntu-latest
    timeout-minutes: 15
    steps:
      - uses: actions/checkout@v7
        with:
          persist-credentials: false
      - uses: actions/setup-node@v7
        with:
          node-version: '24'
          package-manager-cache: false
      - run: npm ci
      - run: npm run lint
      - run: npm test -- --coverage
      - uses: actions/upload-artifact@v7
        with:
          name: reviewed-coverage
          path: coverage/
          if-no-files-found: error
          retention-days: 7

3. אירועים וגבולות האמון שלהם

האירועים כוללים push,‏ pull_request,‏ schedule,‏ workflow_dispatch,‏ repository_dispatch,‏ release,‏ issues,‏ discussion ו־deployment_status. בתהליכים בעלי הרשאות מוגברות מסוג pull_request_target ו־workflow_run אסור לבצע checkout או להריץ קוד לא מהימן מבקשת משיכה. יש להתייחס גם לתוצרים ולקלטים נכנסים כלא מהימנים.

דפוסי הפעלה נפוצים

אירוע	שימוש	הערות
`push`	CI עבור אירועי push תואמים	סינון לפי ענפים ונתיבים
`pull_request`	אימות בקשת משיכה	בקשות משיכה מ־fork בדרך כלל אינן מקבלות סודות מאגר רגילים ומקבלות GITHUB_TOKEN לקריאה בלבד; ההגדרות והקשר האירוע חשובים.
`schedule`	בניות ליליות וסריקות	UTC כברירת מחדל; אזור זמן IANA אופציונלי; מרווח מזערי של 5 דקות. הרצות עשויות להתעכב או להישמט.
`workflow_dispatch`	תהליך ידני עם קלטים מוצהרים	טיפוסי קלט מוצהרים אינם הרשאה, escaping למעטפת או אימות עסקי מלא.
`release`	פרסום רק עבור סוג פעילות השחרור המיועד	משתלב עם Releases API

4. רצים: מנוהלים, באירוח עצמי וגדולים

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

השוואת runners

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

5. בניות מטריצה: מקביליות כחלק מהתכנון

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

jobs:
  test:
    strategy:
      fail-fast: false
      max-parallel: 2
      matrix:
        os: [ubuntu-latest, windows-latest]
        node: ['22', '24']
        include:
          - os: ubuntu-latest
            node: '24'
            coverage: true
        exclude:
          - os: windows-latest
            node: '22'
    runs-on: ${{ matrix.os }}
    timeout-minutes: 15
    steps:
      - uses: actions/checkout@v7
        with:
          persist-credentials: false
      - uses: actions/setup-node@v7
        with:
          node-version: ${{ matrix.node }}
          package-manager-cache: false
      - run: npm ci
      - if: matrix.coverage != true
        run: npm test
      - if: matrix.coverage == true
        run: npm test -- --coverage

6. מטמון ותוצרים

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

מטמון לעומת תוצר

מטמון
קלטים לשימוש חוזר, לא סודות. רשומות שלא ניגשו אליהן יותר מ־7 ימים נמחקות; ברירת המחדל היא 10 GB למאגר. הגדלה עלולה לגרור חיוב ואינה מבוצעת כאן.

תוצר
פלטי תהליך נשמרים. במאגרים ציבוריים ניתן לקבוע 1–90 ימים ובפרטיים 1–400, בכפוף למדיניות המנהלת. זו שמירה לזמן מוגבל, לא ארכיון קבוע.

7. תהליכים לשימוש חוזר ופעולות מורכבות

פעולות מורכבות משתמשות מחדש בשלבים; תהליכים לשימוש חוזר משתמשים מחדש בעבודות; פעולות JavaScript ו־Docker אורזות מימושים. פרסום ב־Marketplace הוא אופציונלי. שימוש חוזר אינו מבטל בדיקת קוד, הרשאות וקלטים מוצהרים. הדוגמה הבאה מאמתת קלט לא מזיק ואינה מבצעת פריסה.

# File 1: .github/workflows/reusable-check.yml
name: Reusable Check
on:
  workflow_call:
    inputs:
      target:
        required: true
        type: string
permissions: {}
jobs:
  validate:
    runs-on: ubuntu-latest
    timeout-minutes: 2
    steps:
      - shell: bash
        env:
          TARGET: ${{ inputs.target }}
        run: |
          case "$TARGET" in
            staging|production) printf '%s\n' 'התווית התקבלה; אין פריסה.' ;;
            *) printf '%s\n' 'תווית לא נתמכת.' >&2; exit 1 ;;
          esac

# File 2: .github/workflows/call-check.yml
name: Call Check
on: workflow_dispatch
permissions: {}
jobs:
  check:
    uses: ./.github/workflows/reusable-check.yml
    with:
      target: staging

8. סודות, משתנים וסביבות

אפשר לתחום סודות לארגון, למאגר או לסביבה; ערכים שאינם רגישים שייכים למשתנים. סביבות בעלות שם כגון staging ו־production יכולות להחיל כללי הגנה מוגדרים לפני שעבודה מקבלת את סודות הסביבה. הבקרות הזמינות תלויות במסלול ובנראות המאגר; שם לבדו אינו שער אישור.

תחומי סודות

ארגון
משותף רק עם מאגרים מורשים שנבחרו; צמצמו תחום ומשך חיים.

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

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

9. OIDC: פדרציה ואישורי ענן קצרי חיים

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

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

זרימת אמון OIDC

1. עבודה מורשית מבקשת אסימון OIDC

←

2. GitHub מנפיקה JWT

←

3. הספק בודק חתימה, מנפיק, קהל יעד ונושא או הקשר מורשה

←

4. הספק מעניק רק גישה זמנית המורשית לפי המדיניות

10. מודל ארגז החול של runner

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

11. נראות ואיתור תקלות

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

כלי אבחון

ACTIONS_STEP_DEBUG=true — יומני שלבים מפורטים
ACTIONS_RUNNER_DEBUG=true — יומני runner מפורטים
$GITHUB_STEP_SUMMARY — הצגת Markdown בממשק ההרצה
actions/upload-artifact — העלו רק דוחות מאושרים ונקיים ממידע רגיש להרצה המיועדת.
gh run watch ו־gh run view --log — מעקב ביומנים משורת הפקודה

12. מיטוב ביצועים ועלויות

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

13. Marketplace וקיבוע גרסאות

התייחסו לפעולות צד שלישי, כולל מרחבי שמות מוכרים כגון actions/* ו־github/*, כתלויות ברות ביצוע. תג יוצר מאומת בודק זהות, לא בטיחות קוד. בדקו מקור והרשאות, קבעו SHA מלא מאושר ובחנו עדכונים. קיבוע מקבע גרסה; הוא אינו מוכיח שהיא בטוחה או עדכנית.

רשימת ביקורת לקיבוע, לא YAML בר ביצוע:
- אתרו את השחרור המיועד במאגר הפעולה הרשמי.
- בדקו את קוד המקור ואת דרישות התאימות.
- תעדו SHA מלא מאומת של commit ואת תווית השחרור.
- השתמשו ב־SHA בתהליך ובחנו עדכונים עתידיים.
- אל תעתיקו את הקיבוע הישן של v4.1.1 כהמלצה עדכנית.

סיכום

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