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

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

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

Azure Boards

• Ограничения для путей области и итерации

Azure Pipelines

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

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

• REST API для сред

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

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

• Отключенная переопределение состояния политики покрытия кода на "Сбой" при сбое сборки

Azure Repos

• Поддержка фильтров без больших двоичных объектов и без деревьев

Azure Boards

Ограничения для путей области и итерации

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

Azure Pipelines

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

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

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

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

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

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

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

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

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

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

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

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

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

Регистрация агента с помощью субъекта-службы

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

--auth 'SP' --clientid 12345678-1234-1234-abcd-1234567890ab --clientsecret --tenantid 12345678-1234-1234-abcd-1234567890ab

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

Виртуальные машины 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, что приводит к блокировке PR.

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

Azure Repos

Поддержка фильтров без больших двоичных объектов и без деревьев

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

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

Примечание.

Эти функции будут развернуты в течение следующих двух-трех недель.

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

Перейдите в Azure DevOps

Отправка отзыва

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

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

Thanks,

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