Переменные сохраняются так же безопасно, как агент, который выполняет сборку, и целостность определения вашей сборки.
Как вы сказали, если пользователь может изменить определение сборки и имеет доступ к секрету, который он может передатьэто в PowerShell или в задаче Curl и т. д. Или, если пользователь может взять под контроль сценарий задачи сборки, он может перебрать все доступные секреты (задачи сборки считаются доверенными системой сборки).
Учтите, что каждый, ктоимеет доступ на запись к рабочим каталогам агента, может получить доступ ко всем секретам, которые доступны для определений сборки, которые выполняются на агенте сборки.Они могут изменять сценарии, используемые в задачах сборки, и таким образом получать такой же уровень доверия.Любая сборка, которая запускается после этого изменения и до тех пор, пока новая версия задачи не будет передана агенту, будет скомпрометирована в этом сценарии.Теоретически, каждое определение сборки может «заразить» папку _tasks агента.Лучший способ защититься от этого - использовать размещенный пул или регулярно сбрасывать виртуальные машины вашего агента.
Определения сборки YAML в сочетании с Pull-Requests дают вам больший контроль над процессом изменения / утверждения определений сборки.
Используя библиотеку переменных, вы можете уменьшить количество людей, которые могут добавлять секретные переменные в свое определение сборки.
Необходимо защитить пулы агентов и библиотеки переменных / определения сборки таким образом, чтобытолько ограниченные и доверенные пользователи могут получить доступ к этим ресурсам.При желании можно использовать одноразовые пароли, срок действия которых истекает через некоторое время или временно предоставляют эти разрешения.
Помните, что все изменения определений сборки, а также библиотек и сценариев переменных в репозитории Git отслеживаются.
Альтернативные способы получения доступа к секретам не применяются к DevOps Azure, поскольку ни один из них не имеет доступа к уровню приложений в Azure, а доступ строго контролируется Microsoft.