Новые политики для личных токенов доступа

В этом спринте мы добавили новые политики, чтобы ограничить область действия и срок действия личных маркеров доступа (PAT). Кроме того, мы обновили расширение Windows Shell для Team Foundation Version Control (TFVC) для поддержки Visual Studio 2019.

Дополнительные сведения см. в следующих описаниях функций.

General

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

Azure Repos

General

Ограничьте область применения и срок действия персонального токена доступа (PAT) через политику арендатора Azure AD.

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

Мы получили отзыв об администраторах, не имеющих необходимых элементов управления для ограничения области угроз, вызванной утечкой PAT. На основе этих отзывов мы добавили новый набор политик, которые можно использовать для ограничения области действия и срока действия личных маркеров доступа организации в Azure DevOps (PATs)! Вот как они работают:

Пользователи, назначенные роли администратора Azure DevOps в Azure Active Directory, могут перейти на вкладку Azure Active Directory в параметрах организации любой организации Azure DevOps, связанной с Azure AD.

Элементы управления IMAGE PAT

Там администраторы могут:

  1. ограничить создание глобальных личных маркеров доступа (маркеры, которые работают для всех организаций Azure DevOps, доступных пользователем).
  2. ограничение создания персональных токенов доступа с полным доступом
  3. определение максимальной продолжительности жизни для новых личных маркеров доступа

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

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

Поддержка политики условного доступа для трафика IPv6

Теперь мы расширяем поддержку политики условного доступа (CAP), чтобы включить политики ограждения IPv6. Как мы видим, люди все чаще обращаются к ресурсам Azure DevOps на устройствах с IPv6-адресов, мы хотим убедиться, что ваши команды оснащены для предоставления и удаления доступа из любого IP-адреса, включая поступающие из IPv6-трафика.

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

Сохранять конвейеры, используемые в других конвейерах

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

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

Изменения в автоматическом создании сред

При создании конвейера YAML и ссылке на среду, которая не существует, Azure Pipelines автоматически создает среду. Это автоматическое создание может происходить в контексте пользователя или системном контексте. В следующих потоках Azure Pipelines знает о пользователе, выполняющего операцию:

  • Вы используете мастер создания конвейера YAML в веб-интерфейсе Azure Pipelines и ссылаетесь на среду, которая еще не создана.
  • Вы обновляете ФАЙЛ YAML с помощью веб-редактора Azure Pipelines и сохраняете конвейер после добавления ссылки на среду, которая не существует.

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

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

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

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

Удалить диалог Аналитики из конвейера сборки

На основе отзывов диалоговое окно "Аналитика задач или конвейера", отображающееся при переходе по конвейеру сборки, было удалено для улучшения рабочего процесса. Аналитика конвейера по-прежнему доступна, чтобы получить необходимые аналитические сведения.

Azure Repos

Обновления расширения оболочки Windows Team Foundation Version Control (TFVC) для Visual Studio 2019

Предыдущая версия расширения оболочки Windows TFVC работала только на компьютерах с установленными Visual Studio 2017.

Мы выпустили новую версию этого средства, совместимую с Visual Studio 2019. Расширение обеспечивает интеграцию с проводником Windows и общими диалогами файлов. Благодаря этой интеграции можно выполнять множество операций управления версиями без необходимости запускать Visual Studio или программу командной строки Team Foundation.

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

Замечание

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

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

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

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

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

Внести предложение

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

Спасибо,

Vijay Machiraju

  • Last updated on