Федерация удостоверений рабочей нагрузки для общедоступной предварительной версии Azure Pipelines

Мы рады сообщить, что федерация идентификаций нагрузки для Azure Pipelines теперь доступна в общедоступной бета-версии! Подключения к службе Azure (ARM) были обновлены с дополнительной схемой для поддержки федерации удостоверений рабочей нагрузки.

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

Azure Boards

• Лимиты для областных и итерационных путей

Azure Pipelines (система конвейеров Azure)

• Федерация удостоверений рабочей нагрузки в Azure Pipelines (общедоступная предварительная версия)

• Агенты конвейера можно зарегистрировать с помощью идентификатора Microsoft Entra вместо PAT

• REST API для сред

• Предотвращение непреднамеренных запусков конвейера

• Безопасная сборка репозиториев GitHub по умолчанию

• Отключено переопределение статуса политики покрытия кода на «Сбой», когда сборка проваливается

Azure Repos

• Поддержка фильтров без блобов и деревьев

Azure Boards

Ограничения для области и маршрутов итерации

Ограничения играют важную роль в поддержании работоспособности и эффективности крупной глобальной службы. В этом спринте мы вводим жесткие ограничения в 10 000 для каждого проекта по обеим областям и путям итерации. Перейдите на страницу "Отслеживание работы", "Процесс" и "Ограничения проекта", чтобы узнать больше о различных ограничениях в службе.

Azure Pipelines (система конвейеров Azure)

Федерация удостоверений рабочей нагрузки в Azure Pipelines (общедоступная предварительная версия)

Вы хотите прекратить хранение секретов и сертификатов в подключениях к службе Azure? Хотите перестать беспокоиться о смене этих секретов всякий раз, когда они истекают? Теперь мы объявляем общедоступную предварительную версию федерации удостоверений рабочей нагрузки для подключений к службе Azure. Федерация удостоверений рабочей нагрузки использует стандартную в отрасли технологию Open ID Connect (OIDC), чтобы упростить проверку подлинности между Azure Pipelines и Azure. Для упрощения этой проверки подлинности вместо секретов используется субъект федерации.

В рамках этой функции подключение службы Azure (ARM) было обновлено с другой схемой для поддержки федерации удостоверений для управления рабочими нагрузками. Это позволяет задачам конвейера, использующим подключение службы Azure, выполнять аутентификацию с помощью субъекта федерации (sc://<org>/<project>/<service connection name>). Основные преимущества использования этой схемы по сравнению с существующими схемами проверки подлинности приведены ниже.

• Упрощенное управление: Вам больше не нужно создавать, копировать и хранить секреты из учетных записей service principal в Azure AD в Azure DevOps. Секреты, используемые в других схемах аутентификации подключений к службам Azure (например, принципал службы), истекают через определенный период (два года в настоящее время). По истечении срока действия пайплайны выходят из строя. Необходимо повторно создать секрет и обновить подключение к службе. Переключение на федерацию удостоверений рабочей нагрузки устраняет необходимость управления этими секретами и улучшает общий опыт создания подключений к службе и управления ими.
• Улучшенная безопасность. При федерации удостоверений рабочей нагрузки не существует постоянного секрета, связанного с взаимодействием между Azure Pipelines и Azure. В результате, задачи, выполняемые в заданиях конвейера, не могут утечь или эксфильтровать конфиденциальные данные с доступом к вашим рабочим средам. Это часто было беспокойством для наших клиентов.

Эти функции можно использовать двумя способами:

• Используйте новую схему федерации удостоверений рабочей нагрузки при создании нового подключения к службе Azure. В будущем это будет рекомендуемый механизм.
• Преобразуйте существующие подключения службы Azure (которые основаны на секретах) в новую схему. Вы можете выполнить это преобразование по одному подключению за раз. Лучше всего, вам не нужно изменять ни один из конвейеров, использующих эти подключения к службе. После завершения преобразования они будут автоматически применять новую схему.

Чтобы создать новое подключение службы Azure с помощью федерации удостоверений рабочей нагрузки, просто выберите федерацию удостоверений рабочей нагрузки (автоматически) или (вручную) в интерфейсе создания подключения службы Azure:

Чтобы преобразовать ранее созданное подключение к службе Azure, выберите действие "Преобразовать" после выбора подключения:

Все задачи Azure, включенные в Azure Pipelines, теперь поддерживают эту новую схему. Однако если вы используете задачу из Marketplace или самостоятельно созданную задачу для развертывания в Azure, она еще не может поддерживать федерацию удостоверений нагрузки. В этих случаях мы просим обновить задачу для поддержки федерации идентификации рабочих нагрузок для повышения безопасности. Полный список поддерживаемых задач можно найти здесь.

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

Эта запись блога содержит дополнительные сведения.

Агенты конвейера можно зарегистрировать с помощью Microsoft Entra ID вместо PAT

Агент конвейера теперь поддерживает дополнительные аргументы для использования учётной записи службы или пользователя для регистрации агента. Необходимо предоставить доступ удостоверению, используемому в пуле агентов, в его параметрах безопасности. Это устраняет необходимость использования личного маркера доступа (PAT) для одноразовой настройки агентов.

Регистрация агента с помощью учетной записи службы

Чтобы использовать учетную запись службы для регистрации агента Pipelines в Azure DevOps Services, укажите следующие аргументы:

--auth 'SP' --clientid 00001111-aaaa-2222-bbbb-3333cccc4444 --clientsecret --tenantid aaaabbbb-0000-cccc-1111-dddd2222eeee

Использование субъекта-службы в расширении виртуальной машины агента

Виртуальные машины Azure можно включить в группы развертывания с помощью расширения виртуальной машины. Расширение виртуальной машины было обновлено, чтобы использовать учетную запись службы вместо персонального токена доступа (PAT) для регистрации агента.

"settings": {
  "userServicePrincipal": true     
}
"protectedSettings": {
  "clientId": "[parameters('clientId')]"      
  "clientSecret": "[parameters('clientSecret')]"      
  "tenantId": "[parameters('tenantId')]"      
}

Регистрация агента в интерактивном режиме с использованием потока кода устройства

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

REST API для средовых окружений

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

Мы знаем, что вы хотите создавать среды программным способом, поэтому мы опубликовали документацию по REST API.

Предотвращение непреднамеренных запусков конвейера

Сегодня, если в YAML-конвейере не указан необходимый trigger раздел, он запускается для любых изменений, отправленных в репозиторий. Это может привести к путанице в том, почему конвейер был запущен, что может привести к множеству непреднамеренных запусков.

Мы добавили настройку конвейеров на уровне организации и проекта с именем Disable подразумеваемый триггер CI YAML, которая позволяет изменить это поведение. Вы можете не запускать конвейеры, если отсутствует их раздел триггера.

Создавайте репозитории GitHub безопасно по умолчанию

В последнем спринте мы представили централизованную систему управления для создания PR из форкнутых репозиториев GitHub.

С помощью этого спринта мы активируем опцию Securely build pull requests from forked repositories на уровне организации для новых организаций. Существующие организации не затронуты.

Отключено изменение состояния политики покрытия кода, изменяющее его статус на "Сбой", когда сборка завершилась с ошибкой.

Ранее состояние политики покрытия кода изменялось на "Сбой" в случае, если сборка в запросе на внесение изменений (PR) завершалась неудачей. Это стало препятствием для некоторых из вас, у кого сборка была настроена как необязательная проверка, а политика покрытия кода - как обязательная проверка для PR, что приводило к их блокировке.

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

Azure Repos

Поддержка фильтров без использования BLOB и деревообразных структур

Azure DevOps теперь поддерживает два дополнительных фильтра во время клонирования и извлечения. Это следующие страницы: --filter=blob:none и --filter=tree:0 Первый вариант (клон без больших двоичных объектов) лучше всего используется для регулярной разработки, а второй вариант (клон без дерева) лучше подходит для тех случаев, когда вы удаляете клон, например, после запуска сборки.

Дальнейшие шаги

Перейдите к Azure DevOps и посмотрите.

Как предоставить отзыв

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

Вы также можете получить советы и ответы на ваши вопросы от сообщества на Stack Overflow.

Спасибо,

Сильвиу Андреика