GitHub App просить доступ на рівні enterprise: просте пояснення для новачка

Що змінило і що перевірити перед Install

Команді потрібна інтеграція GitHub, але на екрані встановлення згадано рівень enterprise. Незрозуміло, чи відкриє натискання Install («Установити») доступ до всіх проєктів компанії.

Ні, не автоматично. Встановлення на рівні enterprise саме по собі не надає доступу до всіх організацій і репозиторіїв. Перед погодженням треба окремо з’ясувати, що застосунок зможе робити та яких ресурсів стосуватимуться ці дії.

7 серпня 2026 року GitHub повідомив, що власники enterprise тепер можуть установлювати публічні GitHub Apps, створені не в цьому корпоративному обліковому записі. У такому контексті їх називають сторонніми. Це слово описує походження застосунку, а не рівень його безпеки. Анонс не повідомляє про вразливість чи активну атаку. Перевірка потрібна через ризик незрозумілих або надмірних дозволів.

Не плутайте встановлення на рівні enterprise з доступом

GitHub App — це інтеграція, яку встановлюють, щоб сервіс міг виконувати певні дії в GitHub. Для перевірки її доступу розрізняйте чотири поняття:

• Enterprise — корпоративний обліковий запис, який може об’єднувати кілька організацій.
• Організація (organization) — простір компанії або команди з учасниками та репозиторіями.
• Репозиторій (repository) — окремий проєкт із кодом, задачами й налаштуваннями.
• Дозвіл (permission) — право прочитати або змінити певні дані чи виконати конкретну дію.

Дозвіл не є ще одним рівнем після enterprise, організації та репозиторію. Він відповідає на запитання «що може зробити застосунок». Область ресурсів показує, де ця дія може застосовуватися.

Що може зробити застосунок? До яких ресурсів стосується ця дія?

Наприклад, зрозумілий опис пілота може звучати так: «Застосунок читає назви й статуси запитів на злиття змін (pull requests) у тестовому репозиторії». Фрази «йому потрібен доступ на рівні enterprise» недостатньо: вона не називає ані дії, ані ресурсів.

Чому два дозволи треба перевірити окремо

У короткому анонсі GitHub окремо названо два дозволи рівня enterprise:

• Enterprise organization installations стосується встановлень GitHub Apps в організаціях enterprise;
• Enterprise organization installation repositories стосується репозиторіїв, пов’язаних із такими встановленнями.

Ці описи показують предмет дозволу, але не всі можливі операції та межі доступу. Якщо застосунок просить один із них, попросіть адміністратора або власника інтеграції відповісти на чотири запитання:

1. Яку конкретну дію має виконати застосунок?
2. Яких організацій або репозиторіїв стосуватиметься ця дія?
3. Що саме не працюватиме без цього дозволу?
4. Чи можна обмежити пілот однією організацією або репозиторієм, якщо налаштування це дозволяють?

Анонс також зазначає, що для встановлень між різними enterprise діють обмеження. Він не містить достатньо деталей, щоб перетворити цю згадку на універсальне правило. Якщо ваш сценарій охоплює кілька enterprise, перевірте умови в актуальній офіційній документації та на екрані встановлення.

П’ять кроків перед кнопкою Install

1. Сформулюйте одну потребу й назвіть власника. Запишіть конкретну задачу застосунку та людину, яка відповідає за інтеграцію.
2. Зафіксуйте те, що показано зараз. Запишіть запитані дозволи та область ресурсів, якщо її видно на екрані встановлення. Не покладайтеся на стару інструкцію.
3. Поясніть кожен дозвіл. Для кожного назвіть дію, ресурс і причину. Якщо хоча б один дозвіл залишається незрозумілим, не погоджуйте встановлення.
4. Почніть з обмеженого пілота. Якщо налаштування це дозволяють, виберіть тестовий репозиторій або найменшу доступну область і короткий тестовий період.
5. Заздалегідь сплануйте перевірку та відкликання. Визначте, хто припинить доступ, які доступні журнали чи інші записи перевірятиме команда та коли вона повторно оцінить інтеграцію.

Не натискайте Install, доки команда не визначила власника, не пояснила кожен запитаний дозвіл і не з’ясувала, як відкликати доступ. Відомий постачальник не замінює цих відповідей.

Де може допомогти ШІ

ШІ може допомогти перефразувати назви дозволів простою мовою та підготувати запитання до адміністратора. Дайте йому конкретне завдання: для кожного дозволу назвати можливу дію, ресурси та припущення. Передавайте лише очищений список без назв компанії, організацій і приватних репозиторіїв, токенів, секретів чи внутрішніх URL.

Відповідь ШІ може бути помилковою і не є схваленням установлення. ШІ не бачить фактичної конфігурації чи поведінки застосунку. Кожне пояснення звіряйте з екраном встановлення й офіційною документацією GitHub.

Запам’ятайте: слово enterprise саме по собі не описує фактичний доступ. До встановлення команда має знати дозволену дію, відповідні ресурси, відповідального та спосіб відкликання.

Джерела

• Enterprises can now install third-party GitHub Apps