Защита репозитория

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2020

Исходный код, файл YAML конвейера и необходимые скрипты и инструменты хранятся в репозитории управления версиями. Разрешения и политики ветви должны использоваться для обеспечения безопасности изменений в коде и конвейере. Вы также можете добавить разрешения конвейера и проверка в репозитории.

Кроме того, следует просмотреть управление доступом по умолчанию для репозиториев.

Из-за дизайна Git защита на уровне ветви будет нести вас только до сих пор. Пользователи с доступ на отправку репозитория обычно могут создавать новые ветви. Если вы используете проекты с открытым кодом GitHub, любой пользователь с учетной записью GitHub может вилку репозитория и предложить вклад обратно. Так как конвейеры связаны с репозиторием, а не с определенными ветвями, необходимо предположить, что код и файлы YAML не являются доверенными.

Вилки

Если вы создаете общедоступные репозитории из GitHub, необходимо рассмотреть свою позицию по сборкам вилки. Вилки особенно опасны, так как они приходят извне вашей организации. Чтобы защитить продукты от кода внесли свой вклад, рассмотрите следующие рекомендации.

Примечание.

Следующие рекомендации применяются в основном к созданию общедоступных репозиториев из GitHub.

Не предоставляйте секреты для вилки сборок

По умолчанию конвейеры настроены на сборку вилок, но секреты и защищенные ресурсы по умолчанию недоступны для заданий в этих конвейерах. Не отключать эту последнюю защиту.

Примечание.

Если включить сборки fork для доступа к секретам, Azure Pipelines по умолчанию ограничивает маркер доступа, используемый для сборок вилки. Он имеет более ограниченный доступ к открытым ресурсам, чем обычный маркер доступа. Чтобы предоставить вилкам те же разрешения, что и обычные сборки, включите сборки Make fork имеют те же разрешения, что и обычные параметры сборки .

Рассмотрите возможность активации сборки вилки вручную

Вы можете отключить автоматические сборки вилок и вместо этого использовать комментарии запроса на вытягивание в качестве способа создания этих вкладов вручную. Этот параметр дает возможность просмотреть код перед активацией сборки.

Использование размещенных корпорацией Майкрософт агентов для сборок вилки

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

Просмотр изменений кода

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

Версия конвейера YAML, который будет выполняться, — это версия запроса на вытягивание. Таким образом, обратите особое внимание на изменения в код YAML и код, который выполняется при выполнении конвейера, например скрипты командной строки или модульные тесты.

Ограничение область маркера GitHub

При создании запроса на вытягивание GitHub вилки Azure Pipelines гарантирует, что конвейер не может изменять содержимое репозитория GitHub. Это ограничение применяется только в том случае, если вы используете приложение GitHub Azure Pipelines для интеграции с GitHub. Если вы используете другие формы интеграции GitHub, например приложение OAuth, ограничение не применяется.

Ветви пользователей

Пользователи в организации с правильными разрешениями могут создавать новые ветви, содержащие новый или обновленный код. Этот код может выполняться через тот же конвейер, что и защищенная ветвь. Кроме того, если файл YAML в новой ветви изменен, обновленный YAML будет использоваться для запуска конвейера. Хотя эта конструкция обеспечивает большую гибкость и самообслуживание, не все изменения безопасны (будь то вредоносные или нет).

Если конвейер использует исходный код или определен в Azure Repos, необходимо полностью понять модель разрешений Azure Repos. В частности, пользователь с разрешением Create Branch на уровне репозитория может ввести код в репозиторий, даже если этот пользователь не имеет разрешения на участие.

Следующие шаги

Затем узнайте больше о защите, предоставляемой проверка на защищенных ресурсах.