Git-хостинги

Интеграция с системой контроля версий определяет, какой проверенный исходный код может стать управляемым артефактом Gateway. Владелец приложения отвечает за репозиторий и политику веток, владелец платформы — за настройки сборки и развёртывания, а владелец безопасности — за права поставщика и секреты. Успех означает, что конкретный коммит можно проследить через доказательства сборки до неизменяемого артефакта и проверенного релиза.

Настраивайте интеграции исходного кода в Settings > Integrations. Поддерживаются GitLab, GitHub и обычный Git в зависимости от доступности коннектора и тарифа. Доступ к удалённой ОС описан отдельно в разделе SSH-подключения.

Используйте отдельную машинную идентичность или идентичность приложения с доступом к репозиторию только для чтения, если процесс явно не требует большего. Ограничьте разрешённые репозитории и хосты. Проверяйте подлинность webhook, выбор ветки, разрешение коммита и ротацию учётных данных.

URL репозитория не должны содержать встроенные учётные данные. Проверка ключей хоста SSH и сертификатов HTTPS должна завершаться безопасным отказом. Удаляйте интеграцию только после обнаружения и миграции зависимых источников Docker, Compose Project и Pages.

Типы интеграций

• GitLab: обнаружение проектов и групп, операции с репозиторием, webhooks, переменные, процессы CI и необязательное обнаружение реестра в соответствии с правами по тарифу.
• GitHub: обнаружение репозиториев и поддерживаемые операции с репозиторием или Actions через настроенное приложение или токен.
• Generic Git: ограниченный аутентифицированный доступ к репозиторию, когда отдельный поставщик не требуется.

GitLab

1. Используйте отдельного пользователя GitLab с членством только в нужных группах/проектах. В меню аватара откройте Edit profile > Access > Personal access tokens. Создайте токен: интерфейс может называть его классическим персональным токеном.
2. Задайте имя, срок действия и права из таблицы. Сразу скопируйте секрет.
3. В интеграции GitLab в Gateway укажите адрес экземпляра, например https://gitlab.example.com, без /api/v4, и токен. Выберите разрешённые проекты/группы вместо всех обнаруженных проектов.
4. Проверьте токен, обнаружение разрешённого проекта и доступ к репозиторию и ветке. Токен развёртывания GitLab не заменяет эту учётную запись API.

Сценарий	Права токена GitLab
Обнаружение проектов и чтение метаданных API	read_api
Чтение/клонирование кода для сборок	read_repository вместе с read_api для специализированного коннектора
Обнаружение/скачивание приватных образов реестра	Дополнительно read_registry и нужное членство в проекте
Запись файлов через API, управление обработчиками событий/переменными, изменяющие операции CI	api; роль пользователя в проекте также должна разрешать операцию
Отправка изменений через Git по HTTPS	write_repository; это не даёт общего права записи через API

Для сборок с чтением исходников начните с read_api + read_repository, а не с api. Широкое право api нужно только для включённых сценариев записи. Токен не обходит защиту веток и отсутствие членства в проекте. Персональная авторизация GitLab для интерактивных инструментов остаётся отдельной от сохранённого системного токена.

Источники: создание персонального токена GitLab, права токенов GitLab.

GitHub

Если настроено подключение OAuth, используйте Connect GitHub и проверьте запрашиваемый доступ к организациям и репозиториям на экране согласия GitHub. Для подключения токеном:

1. В GitHub откройте Settings > Developer settings > Personal access tokens > Tokens (classic) > Generate new token (classic).
2. Задайте отдельное имя и срок действия. Выберите repo для приватных репозиториев или public_repo, если нужны только публичные. Это широкие права на репозиторий, а не только чтение: ограничьте доступ самой учётной записи нужными репозиториями.
3. Дополнительные права выбирайте только для сценариев из таблицы ниже. Создайте и скопируйте токен. При необходимости авторизуйте его для SSO организации.
4. Добавьте токен в интеграцию GitHub в Gateway, выберите разрешённые репозитории/организации и проверьте обнаружение репозитория и доступ к нужной ревизии.

Дополнительный сценарий	Право классического токена
Чтение членства в организациях и командах	read:org
Скачивание пакетов GitHub Packages	read:packages
Изменение файлов процессов GitHub Actions	workflow вместе с доступом к репозиторию

Ограничение текущей реализации: Gateway определяет возможности токена GitHub по классическим правам OAuth. Детализированный персональный токен (fine-grained PAT) может пройти аутентификацию GitHub, но коннектор не распознает доступ к репозиториям. Не заменяйте им токен из инструкции выше. Если организация запрещает классические токены, используйте одобренное настроенное подключение OAuth либо сначала решите вопрос совместимости коннектора; не ослабляйте политику организации. Для сборки сохранённого репозитория не нужны delete_repo и администрирование организации.

Источники: управление персональными токенами GitHub, значения классических прав OAuth.

Generic Git

1. На Git-сервере создайте отдельные учётные данные для клонирования выбранных репозиториев. Например, токен развёртывания GitLab с read_repository подходит для Git по HTTPS, но не заменяет токен специализированного коннектора API GitLab.
2. В Gateway выберите обычный Git. Укажите Git host URL, например https://git.example.com, и явный список Repositories, например https://git.example.com/team/app.git.
3. Заполните Username и Access token отдельно. Для токена развёртывания используйте выданное с ним имя пользователя. Не добавляйте учётные данные в URL репозитория.
4. Нажмите Test connection и сохраните. Тест проверяет первый репозиторий: перед использованием в сборках отдельно проверьте доступ к остальным разрешённым репозиториям.

Это подключение по HTTPS, а не импорт приватного ключа из External SSH. У него нет универсального набора прав всех Git-провайдеров или полного набора возможностей API GitLab/GitHub. Успешное клонирование не подтверждает права управления обработчиками событий, переменными или CI через API.

Безопасная настройка

1. Создайте отдельную идентичность поставщика или машинную идентичность.
2. Выдайте доступ к репозиторию только для чтения, если документированный процесс не требует записи.
3. Ограничьте организации, группы, проекты и репозитории через поддерживаемый коннектором режим выбора.
4. Добавьте интеграцию в Settings → Integrations.
5. Проверьте TLS-сертификат или SSH-ключ сервера до сохранения учётных данных.
6. Проверьте обнаружение репозитория и доступ к одной разрешённой ревизии.
7. Убедитесь, что репозиторий или хост вне области отклоняется.
8. Настраивайте проверку подлинности и доставку webhook только после успешной работы пути чтения.

Жизненный цикл привязки источника

Кто может запускать и просматривать сборки?

Обнаружение репозиториев и прямые операции с исходным кодом используют права соответствующей интеграции. Привязка или изменение источника проходят проверки коннектора и репозитория. Интерактивные инструменты GitLab также могут требовать собственную авторизацию пользователя в GitLab, если использование системных учётных данных не разрешено явно.

Запуск сборки из уже сохранённого источника Docker — действие над ресурсом: docker:containers:manage для контейнера или развёртывания, docker:compose:manage для Compose. Только ради запуска такой сборки не нужно выдавать оператору отдельное право integrations:gitlab:repo:read. Gateway по-прежнему проверяет сохранённый коннектор, разрешённый репозиторий и учётные данные источника. Для действий развёртывания Pages используется pages:deploy.

История и логи сборок требуют права просмотра цели: docker:containers:view, docker:compose:view или pages:view. Ограничения конкретным ресурсом и наследуемой папкой сохраняются; право управления само по себе не заменяет просмотр. Не расширяйте доступ до всей ноды или всех репозиториев вместо выдачи нужного разрешения на цель. См. Права доступа.

Сохранённые привязки

Практические сценарии: сборки Docker, сборки Pages из Git и реестры образов. Другие типы коннекторов перечислены в обзоре интеграций.

Рабочие нагрузки Docker, Compose Project и Pages Projects создают собственные привязки источника. Привязка хранит интеграцию, репозиторий, выбор ревизии, конфигурацию сборки, политику автоматизации и Build Secrets с областью источника.

После удаления интеграции зависимые ресурсы нельзя считать готовыми к безопасной повторной сборке. Сначала составьте список зависимостей, отключите автоматические действия, перенесите каждую привязку источника и проверьте новую ревизию и учётные данные.

Диагностика

Разделяйте ошибку аутентификации, отказ списка разрешений, отсутствие репозитория, разрешение ревизии, доставку webhook, допуск Build Worker и отсутствие права по тарифу. На странице интеграции и в связанных Tasks сохраните идентификаторы запросов поставщика и историю операций Gateway, не записывая токены, закрытые ключи, переменные или Build Secrets. Исправьте именно найденный уровень и повторите ограниченную проверку.

Процесс исходного кода для рабочей среды

Связывайте исходный код рабочей среды с проверенной политикой веток и точным разрешённым коммитом. Имя ветки служит входом выбора, а дайджест коммита — неизменяемым доказательством собранного содержимого. До включения автоматических действий подтвердите корень приложения, менеджер пакетов, скрипт сборки, каталог артефакта, платформу среды выполнения и политику публикации или развёртывания. Храните Build Secrets отдельно от обычных Variables среды выполнения и выдавайте только значения, нужные на этапе сборки.

Для Pages и управляемых сборок Git проверяйте всю цепочку: доступ поставщика, обнаружение репозитория, разрешение коммита, допуск Build Worker, загрузку зависимостей, создание артефакта, политику уязвимостей, если она включена, неизменяемую идентичность артефакта, публикацию Tag или ревизию рабочей нагрузки и состояние клиентского пути. Успешный webhook поставщика или клонирование источника — только начало цепочки.

Ротация, миграция и удаление

Для ротации добавьте замену у поставщика и в Gateway, проверьте обнаружение и одну реальную сборку, затем отзовите прежнее значение. При миграции поставщика или репозитория остановите автоматические развёртывания, запишите последний одобренный коммит и дайджест артефакта, настройте новый источник, сравните разрешённое дерево, выполните пробную сборку и только после проверки переместите указатель рабочей среды.

Перед удалением коннектора перечислите все зависимости Docker, Compose Project, Pages, реестра, webhook и автоматизации. Сначала отключите триггеры. Уже работающие неизменяемые артефакты могут продолжить работу, но после исчезновения коннектора будущие сборки, обновления или восстановление из источника завершатся ошибкой. Сохраняйте последний одобренный артефакт и инструкцию отката, пока новый путь источника не пройдёт полный эксплуатационный цикл.

Проверка безопасности

Проверяйте журналы аудита поставщика, ключи развёртывания, ключи хостов SSH, секреты webhook, разрешённые организации и репозитории и неактивные привязки. Доступ к репозиторию для чтения может раскрыть закрытый исходный код и конфигурацию; права записи или права процесса влияют на цепочку поставки программного обеспечения. Выдавайте их только тогда, когда выбранный сценарий Gateway действительно этого требует.

Интеграция источника не заменяет проверку изменений репозитория, защищённые ветки, управление зависимостями или одобрение артефакта. Gateway добавляет контролируемое обнаружение, сборку, развёртывание, области и аудит вокруг этих практик; он должен использовать политику исходного кода организации, а не становиться недокументированным исключением.