GitHub Actions עוברת בהדרגה למודל Multi-Cloud עבור חלק מעבודות ה־Linux המתארחות אצל GitHub. החל מהעדכון שפורסם ב־28 באוקטובר 2026, jobs זכאים עשויים לרוץ על תשתית AWS לצד Azure, בלי שינוי בתוויות ה־runner ובלי צורך לערוך את קובצי ה־YAML. מבחינת המפתח הכול אמור להיראות זהה; מבחינת צוותי רשת ואבטחה, זה שינוי שדורש בדיקה.
מי עובר ל־Multi-Cloud?
לפי GitHub, השינוי חל על jobs זכאים של GitHub-hosted Linux runners — ובהם runners סטנדרטיים בני 2 או 4 ליבות וכן larger runners תואמים שאינם דורשים תצורת רשת מיוחדת. סביבות Windows, private networking וסוגי runner ייעודיים אינם כלולים במהלך הזה. בחשבונות Free, Pro ו־Team ההפעלה מתבצעת אוטומטית; לקוחות Enterprise Cloud יכולים להצטרף בתהליך opt-in.
למה ה־Workflow לא משתנה אבל ה־Firewall כן?
אותן תוויות כמו ubuntu-latest ממשיכות לעבוד, ולכן אין סיבה לבנות תנאים נפרדים לפי ספק הענן. השינוי נמצא מתחת לשכבת ה־workflow: כתובות המקור שמהן ה־runner מתקשר עשויות להגיע מטווחים נוספים. ארגון שאִפשר רק טווחי Azure או Microsoft עלול לראות כשלי יציאה, חיבור למאגרים פרטיים, גישה ל־API פנימי או חסימות במדיניות Microsoft Entra.
ארבע פעולות לפני ההרחבה
- בדקו רשימות IP קשיחות: חפשו Firewall rules, proxy allowlists, VPN policies ותנאי גישה שמניחים שכל runner מגיע מ־Azure.
- השתמשו במקור הרשמי: משכו את מערך
actionsמ־GET https://api.github.com/metaוהחילו את כל הטווחים המפורסמים עבור GitHub Actions. - אוטומטו סנכרון: טווחי IP משתנים. job תקופתי שמחשב diff ומעדכן את בקרות הרשת בטוח יותר מהעתקה ידנית חד־פעמית.
- בדקו תרחישים רגישים: הריצו workflow שמתחבר ל־registry, למאגר קוד פרטי, ל־secrets ולשירותים פנימיים, ואמתו לוגים בשערי היציאה וב־Entra.
מה לא כדאי לעשות
אין צורך לפצל pipelines לפי AWS ו־Azure, ואין להניח שכתובת IP קבועה היא זהות אמינה. במערכות רגישות עדיף לשלב הרשאות קצרות חיים מבוססות OIDC, הקצאת הרשאות מינימלית ובקרות רשת שמתעדכנות אוטומטית. מי שנדרש לטווח יציאה קבוע צריך לבחון runner ייעודי או תצורת רשת נתמכת במקום להסתמך על כתובות של צי ציבורי.
מקור
תמונת נושא: Stanislav Kondratiev / Pexels, ברישיון Pexels Free License.
