Azure DevOps (ранее Team Foundation Services) предоставляет схожий с Gitlab набор инструментов и возможностей, включая собственную реализацию CI/CD с pipeline. Но это не только облачное решение – систему с агентами CI/CD можно развернуть и локально, что серьезно влияет на выбор ее настроек.
Платформа в основном опирается на знакомый нам механизм групп в Windows. При локальном развертывании есть возможности как интеграции с существующей AD, так и использования локальных групп пользователей для распределения ролей и привилегий.
Про бесконечное число ошибок, допускаемых при настройке групп в Windows, мы говорить не будем. В этой публикации мы подсветим узкие моменты, непосредственно связанные с Azure DevOps, на которые стоит обратить внимание при выборе конфигурации.
Права по умолчанию
Чтобы пользователь получил доступ к проекту, он должен быть добавлен в группу вида <ProjectName>\Project Valid Users. Но из-за особенностей работы наследования прав в системе этот пользователь будет автоматически добавлен в группу коллекции с проектом – <ProjectCollectionName>\Project Collection Valid Users. Что это значит? Что этот пользователь сможет просматривать содержимое всех проектов в рамках текущей коллекции, поскольку чтение у таких групп является выдаваемой привилегией по умолчанию.
Само добавление в группы Valid Users обычно происходит автоматически в момент приглашения пользователя в проект и изменения его прав.
В рамках наших проектов мы встречали случаи, когда в группу Valid Users всех проектов на сервере была включена доменная группа Domain Users со всеми пользователями. В результате любой пользователь из домена мог зайти в Azure DevOps и посмотреть содержимое проектов.
Два вида pipeline – два набора прав доступа
В этой платформе pipeline’ы разделены на два вида исходя из их назначения: Build и Release. Обе ветки имеют свои настройки привилегий, которые никак не связаны между собой. Если не ознакомленный с запутанной документацией человек будет настраивать привилегии вручную, он из-за незнания может попросту проигнорировать изменение стандартных настроек одного из базовых вариантов прав.
Таблица прав по умолчанию для Build Pipeline:
Права в общем-то похожи на те, что мы можем увидеть в Gitlab, но с некоторыми расширениями. Если их не изменяли, то любой, кто может редактировать содержимое репозитория, может редактировать и Build Pipeline и запускать процесс сборки.
При встрече с такой ситуацией особых проблем с эксплуатацией pipeline возникнуть не должно. Да, редактор, представленный в интерфейсе, интуитивно понятен и предлагает подсказки при редактировании конфигурации.
Таблица для Release Pipeline:
Тут все несколько интересней: большая часть привилегий и редактирования по умолчанию доступна начиная с уровня администратора проекта. Но добавление новых этапов pipeline требует прав редактирования самого pipeline, поэтому обычный пользователь может редактировать только существующие этапы.
Возможность редактирования этапа в таком pipeline сравнима с возможностью редактирования части yml конфигурационного файла в Gitlab (здесь это тоже yaml-конфиг, только в комплекте еще имеется нормальный конструктор). Редактирования только одной части такой конфигурации нам вполне хватит, чтобы заставить агенты-сборщики выполнять интересующие нас действия. Главное, чтобы в проекте уже существовал хотя бы один Release pipeline.
На практике мы столкнулись именно с таким случаем – измененные права на Build Pipeline при стандартных правах на Release-версию. К счастью для нас, в системе был доступен пустой шаблон выпуска, содержащий один пустой этап. Казалось бы – мелочь, но совпадение этих двух факторов привело к тому, что мы смогли выполнить произвольный код на сервере агента pipeline и получить доступ во внутреннюю инфраструктуру, пропустив таким образом этап побега из DMZ.
Агенты, обслуживающие pipeline, и варианты действий в этапах
Агенты в Azure DevOps мало чем отличаются от тех, что вы могли видеть в GitLab, и имеют схожие проблемы в области обеспечения безопасности. Агенты, размещенные на серверах, нужно изолировать, запускать с ограниченными привилегиями, и нельзя переиспользовать агенты между проектами. Также доступно использование конструкции Docker-in-Docker с таким же монтированием сокета docker-api внутрь контейнера агента, что несет уже знакомые нам последствия – об этом, кстати, предупреждают сразу:
Microsoft дает более развернутые рекомендации по безопасности механизма CI/CD, с которыми можно ознакомиться здесь.
А вот варианты действий в этапах работы pipeline в системе Azure DevOps намного разнообразнее, особенно если агент запущен на Windows-сервере. Так, помимо выполнения консольных команд, сходных для всех доступных платформ, на Windows-агентах можно пользоваться скриптами Powershell, писать код на C# и многое другое (с полным списком можно ознакомиться по ссылке).
Изменение pipeline и его отдельных этапов с помощью встроенного редактора приятнее и быстрее переписывания руками yaml-конфигураций в Gitlab. Результаты задач, выполняемых pipeline, можно просмотреть аналогичным с Gitlab способом.
