Как работают белые списки (allowlist) на GitHub и зачем они нужны

Allowlist (белый список) на GitHub — это явный перечень пользователей, команд, приложений или действий, которым разрешён доступ к репозиторию, workflow или организации; настройка allowlist уменьшает риск несанкционированных пушей, запуска вредоносных Actions и использования сторонних приложений. Ниже — практические шаги и советы по внедрению.

Что такое allowlist и где его применяют

Allowlist — это политика «разрешено только то, что явно указано». На GitHub её применяют в трёх основных областях:

• Доступ к коду: коллаборация и команды (Manage access, teams).
• CI/CD: разрешённые GitHub Actions и reusable workflows (Settings → Actions → General).
• Интеграции и раннеры: одобренные GitHub Apps, OAuth-приложения и self-hosted runner groups.

Такой подход особенно полезен для организаций с высоким уровнем безопасности: финансы, госпроекты, крупные open-source репозитории.

Как настроить белый список в репозитории и организации — пошагово

1. Определите область контроля: репозиторий, группа репозиториев или вся организация.
2. Доступ к коду:
   • В репозитории: Settings → Manage access → Invite teams/collaborators; используйте команды вместо отдельных пользователей.
   • В организации: создайте команды с нужными правами и используйте их для управления доступом.
   • Включите защищённые ветки (Branch protection) и требуйте Pull Request, проверки и обязательных ревью.
3. Разрешённые Actions:
   • Перейдите в Settings → Actions → General.
   • Выберите «Allow specified actions and reusable workflows».
   • Добавьте конкретные actions (в формате owner/name) или отметьте «Only actions in this repository».
   • Для организаций задайте политику на уровне org, чтобы наследовать её в репозиториях.
4. Управление раннерами:
   • Self-hosted runners группируются и задаётся список репозиториев, которые могут их использовать.
   • В Organization settings → Actions → Runner groups: укажите, какие репозитории допускаются.
5. Разрешённые приложения:
   • В Organization → Third-party access / OAuth application allowlist одобрите конкретные приложения для использования.
6. Автоматизация:
   • Используйте шаблоны репозиториев и политики организации, чтобы новые репозитории сразу наследовали настройки.
   • Периодические ревью доступа: экспортируйте список участников и проверяйте активность.

Советы по управлению и автоматизации

• Стандартизируйте имена команд и роли (например: infra-read, infra-write, ci-admin).
• Включите аудит: проверяйте Audit Log для событий изменения доступа, разрешения приложений и выполнения Actions.
• Автоматизируйте удаление неактивных участников (скрипт или GitHub Apps).
• Документируйте процесс одобрения новых Actions/Apps и ведите список одобренных версий (tag/sha), чтобы не зависеть от latest.

Частые ошибки

• Слишком жёсткий allowlist, который ломает CI (не включили нужные actions).
• Разрешение приложений без проверки scope (они получают лишние права).
• Ожидание, что branch protection решит все проблемы — без контроля приложений и Actions ваши CI может запускать вредоносный код.
• Нехватка регулярных ревью и удаления устаревших разрешений.

FAQ

• Можно ли задать allowlist только для одного репозитория?
  • Да. Настройки Actions, collaborators и branch protection можно настроить на уровне репозитория.
• Что делать, если workflow использует неразрешённый action?
  • Добавьте его в allowlist как owner/name или используйте версию по SHA после проверки.
• Как быстро проверить, какие приложения разрешены в организации?
  • Просмотрите раздел Third-party access / OAuth application allowlist в настройках организации и Audit Log.

Заключение: внедряйте allowlist пошагово — начните с Actions и доступа к коду, автоматизируйте ревью и документируйте правила. Это даст сильную защиту при минимальном нарушении рабочих процессов.