איך לחבר GitHub ל־AWS DevOps Agent עם הרשאות בשליטתכם
מדריך לחיבור GitHub.com ל־AWS DevOps Agent באמצעות GitHub App פרטית בבעלותכם: בחירת הרשאות קריאה או כתיבה ובדיקת הגישה במאגר ניסוי לפני חיבור קוד ארגוני.
אפשר כעת לחבר את GitHub.com ל־AWS DevOps Agent באמצעות GitHub App פרטית שנשארת בבעלות החשבון או הארגון שלכם. העדכון הרשמי מ־22 בספטמבר 2026 מוסיף בחירת Custom app, ובתהליך היצירה מאפשר לבחור בין קריאה בלבד לקריאה וכתיבה. המדריך הבא מתמקד בחיבור ראשון למאגר ניסוי, כדי לבדוק את גבולות הגישה לפני שמכניסים קוד ארגוני לתמונה.
1. הבינו מה השתנה והגדירו את מטרת החיבור
החידוש הוא באופן הקמת האינטגרציה ובבעלות על האפליקציה: לפי התיעוד, השירות יוצר עבורכם GitHub App פרטית בחשבון או בארגון שבחרתם. זה לא רק הבדל בשם החיבור. לצוות הפיתוח יש רכיב מזוהה בבעלותו, שאפשר לכלול במיפוי האינטגרציות הארגוני ולשייך לאחראי ברור. עם זאת, בעלות על האפליקציה אינה הוכחה לכך שהמידע נשאר בארגון או שאינו מעובד בשירות חיצוני.
לפני פתיחת תהליך ההגדרה, כתבו מה אתם רוצים לבדוק. למשל: האם החיבור מאפשר לסוכן לגשת למידע הרלוונטי במאגר ניסוי לצורך משימה הנתמכת בשירות. אל תגדירו יעד עמום כמו ״לתת לסוכן לעבוד על הקוד״. יעד מצומצם יעזור להחליט אם קריאה מספיקה, לזהות כישלון ולהימנע מהוספת הרשאות שאינן קשורות לצורך.
גבולות המדריך: העדכון מתייחס ל־GitHub.com. התחקיר אינו מפרט את כל מסכי ההתקנה, את ההרשאות הפרטניות או את הפעולות הנתמכות בסוכן. לכן Custom app הוא שם האפשרות המאומת כאן; יתר השלבים הם סדר עבודה מומלץ, ולא שחזור מלא של ממשק הקונסולה.
2. הכינו מאגר ניסוי ובעלים לחיבור
התחילו במאגר ייעודי שאין בו קוד לקוח, סודות או נתוני משתמשים. אפשר להכין פרויקט קטן עם קובץ תצורה ותיעוד פנימי לדוגמה, כדי שתוכלו לזהות אם נשלף המידע הנכון. העדיפו תוכן סינתטי שיצרתם לצורך הבדיקה על פני העתק של מאגר ייצור: גם היסטוריית Git עלולה להכיל מידע שלא רואים בקבצים הנוכחיים.
- בחרו אם האפליקציה צריכה להיות בבעלות חשבון אישי או ארגון. לחיבור צוותי מתמשך, העדיפו בעלות ארגונית בהתאם למדיניות שלכם.
- ודאו שמי שמבצע את ההקמה רשאי ליצור ולהתקין GitHub Apps בהקשר שנבחר. אם נדרש אישור מנהל ארגון, תכננו אותו מראש.
- מנו אחראי לחיבור ומחליף שיוכל לבדוק אותו או לטפל בניתוק גם בהיעדרו.
- רשמו את מאגר הניסוי, מטרת הבדיקה ורמת ההרשאה המתוכננת. שמרו את הרשומה במקום הנגיש לצוות.
- בדקו מראש את אמצעי ההסרה או הגבלת הגישה הזמינים בהגדרות GitHub ובשירות, בלי להסתמך על מחיקת קוד מהמאגר.
בסטארטאפ ישראלי קטן, אותה מפתחת עשויה להיות גם מנהלת הארגון וגם אחראית התשתיות. דווקא במצב הזה כדאי להפריד בין מי שמאשרת הרחבת הרשאות לבין מי שמבצעת את הניסוי, כשאפשר. אם ספק DevOps חיצוני מבצע עבורכם את ההתקנה, קבעו מראש מי יהיה בעל האפליקציה ומי יוכל לנהל אותה לאחר סיום ההתקשרות.
3. בחרו Custom app והתחילו מקריאה בלבד
פתחו את תהליך חיבור GitHub.com ב־AWS DevOps Agent ובחרו Custom app. המשיכו בתהליך יצירת האפליקציה הפרטית בחשבון או בארגון המתאים. לפני אישור, בדקו שאתם פועלים בזהות ובארגון הנכונים, במיוחד אם אתם מנהלים כמה ארגוני GitHub או עובדים במקביל על פרויקטים של לקוחות שונים.
בבחירה בין קריאה בלבד לקריאה וכתיבה, התחילו בקריאה אם אין דרישה מוגדרת לשינוי מידע. עברו על ההרשאות הפרטניות שמוצגות בתהליך, ולא רק על הכותרת הכללית. אם מוצעת בחירה במאגרים מסוימים, הגבילו את ההתקנה למאגר הניסוי; אם אינכם מצליחים להגביל את הגישה כנדרש, עצרו ובדקו את ההגדרות לפני אישור החיבור.
הרשאת כתיבה צריכה לענות על צורך מוגדר, לא על האפשרות שאולי נצטרך אותה בהמשך.
חשוב להבחין בין הרשאה ליכולת: בחירה בקריאה וכתיבה אינה מעידה לבדה שהסוכן תומך בכל פעולת GitHub, ואינה מבטיחה יצירת commit או pull request. הפעולות הזמינות תלויות ביכולות השירות ובהרשאות המדויקות. גם קריאה בלבד אינה נטולת סיכון, משום שהיא עשויה לחשוף קוד ומידע פנימי במסגרת החיבור.
4. בדקו גישה תקינה וגם את גבולות ההרשאה
לאחר ההקמה, ודאו שהאפליקציה מופיעה בחשבון או בארגון שהתכוונתם אליו ושפרטי ההתקנה תואמים להחלטות שקיבלתם. בדקו את מצב החיבור בשירות, ואז הפעילו משימה נתמכת ומצומצמת שדורשת מידע ממאגר הניסוי. בחרו מידע מוכר כדי שתוכלו להשוות את התוצאה לתוכן המקורי, ולא להסתפק בתשובה שנשמעת סבירה.
בדקו גם את הצד השלילי: אם הגבלתם את ההתקנה למאגרים מסוימים, ודאו בהגדרות שמאגר בדיקה נוסף אינו נכלל. ככל שהשירות מאפשר בדיקה מתאימה, בדקו שאין גישה אליו. אל תבקשו מהסוכן לשנות מאגר ייצור כדי להוכיח שאין לו כתיבה. את גבולות ההרשאה מאמתים קודם בהגדרות, ובמידת הצורך בניסוי בטוח ומבודד.
אם הבדיקה נכשלת, אל תעברו מיד להרשאות רחבות יותר. בדקו לפי הסדר את זהות הארגון, התקנת האפליקציה, הגישה למאגר ואישורים ארגוניים שעשויים להידרש. שמרו תיעוד של השגיאה ושל הפעולה שניסיתם לבצע, ללא סודות. כך אפשר להבחין בין חיבור לא תקין, חסימת מדיניות ופעולה שאינה נתמכת.
5. הרחיבו שימוש רק אחרי בדיקה מתועדת
לפני מעבר למאגר עבודה, סכמו מה נבדק, מה הצליח ואילו הרשאות אושרו. אם נדרשת כתיבה, בדקו בתיעוד כיצד להגדיר אותה לחיבור שלכם, ואז חזרו על הניסוי בסביבה מבודדת. במאגרים הרלוונטיים, שלבו את ההרשאה עם כללי ההגנה וביקורת הקוד הנהוגים אצלכם; אל תניחו שבעלות על האפליקציה מחליפה אותם.
לצוות בישראל שעובד עם קוד של לקוחות בארץ ובחו״ל, המעבר לייצור דורש גם בדיקת ההתחייבויות החוזיות ומדיניות שיתוף הקוד. העדכון אינו קובע היכן מידע מעובד או נשמר. התוצאה הרצויה של הניסוי היא חיבור בבעלות הנכונה, הרשאות שתואמות משימה מוגדרת ודרך ידועה לבטל גישה, לא רק סימון שההתקנה הסתיימה.
שאלות נפוצות
איך מחברים GitHub ל־AWS DevOps Agent עם אפליקציה בבעלות הארגון?
בתהליך חיבור GitHub.com בוחרים Custom app. השירות יוצר GitHub App פרטית בחשבון או בארגון שלכם, ובתהליך היצירה בוחרים בין הרשאות קריאה בלבד לקריאה וכתיבה.
האם AWS DevOps Agent חייב הרשאת כתיבה ל־GitHub?
אפשרות Custom app כוללת גם בחירה בקריאה בלבד, ולכן אין חובה לבחור כתיבה בעת יצירת האפליקציה. התאמת ההרשאה תלויה במשימה: מומלץ להתחיל בקריאה ולהוסיף כתיבה רק כשיש צורך מוגדר ולאחר בדיקה.
האם העדכון ל־Custom app חל גם על GitHub Enterprise Server?
העדכון שסופק בתחקיר מתייחס במפורש לחיבור GitHub.com. אין בו בסיס לאישור תמיכה ב־GitHub Enterprise Server, ולכן יש לבדוק זאת בתיעוד המתאים לפני תכנון החיבור.
דרגו את הכתבה
הדירוג עוזר לנו לדעת מה שווה לכם.
תגובות