Share via

Расширенное управление безопасностью

  • Статья

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

В Azure Pipelines мы добавили централизованный элемент управления для повышения безопасности запросов на вытягивание, созданных из вилки репозиториев GitHub.

Дополнительные сведения об этих функциях см. в заметках о выпуске.

Общее

Azure Pipelines

Azure Repos

Azure Artifacts

Общее

Включение расширенной безопасности на уровне проекта и организации

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

Включение на уровне проекта:

Снимок экрана: включение на уровне проекта.

Включение на уровне организации:

Снимок экрана: включение на уровне организации.

Предполагаемое число фиксаций во время включения расширенной безопасности

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

Снимок экрана: включение расширенной безопасности.

Azure Pipelines

Повторите попытку, когда истекает время ожидания утверждений и проверок

Когда истекает время ожидания утверждений и проверок, этап, к которому они принадлежат, пропускается. Этапы, имеющие зависимость от пропущенного этапа, также пропускаются.

Теперь вы можете повторить этап, когда время ожидания утверждения и проверки. Ранее это было возможно только при истечении времени ожидания утверждения.

Снимок экрана: повторная попытка этапа.

Роль администратора для всех сред

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

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

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

Снимок экрана: роль администратора.

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

При предоставлении роли администратора пользователя на уровне среды-концентратора он становится администраторами для всех существующих сред и для любых будущих сред.

Централизованный контроль для создания PR из вилки репозиториев GitHub

При создании общедоступных репозиториев из GitHub необходимо учитывать свою позицию в отношении сборок вилки. Вилки особенно опасны, так как они поступают из-за пределов вашей организации.

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

Чтобы повысить безопасность конвейеров, мы добавили элемент управления на уровне организации для определения того, как конвейеры создают ЗАПРОСы из вилки репозиториев GitHub. Новый параметр называется Ограничить создание запросов на вытягивание из вилки репозиториев GitHub и работает на уровне организации и проекта.

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

Давайте посмотрим, как работает переключатель на уровне организации. Новый элемент управления по умолчанию отключен, поэтому никакие параметры не применяются повсеместно.

Снимок экрана: переключение уровня организации.

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

Снимок экрана: включение переключателя.

При выборе параметра Безопасная сборка запросов на вытягивание из вилки репозиториев все конвейеры в масштабах всей организации не могут сделать секреты доступными для сборок запросов на вытягивание из вилки репозиториев, не могут сделать эти сборки такими же разрешениями, как обычные сборки, и должны быть активированы комментарием к запросу на вытягивание. Проекты по-прежнему могут не разрешать конвейерам создавать такие PR.

Снимок экрана: безопасная сборка запроса на вытягивание.

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

Снимок экрана: настройка.

Azure Repos

Новая политика ветви, запрещающая пользователям утверждать собственные изменения

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

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

На следующем рисунке показан запрос на вытягивание, созданный пользователем A, и дополнительные 4 фиксации (итераций), выполненные в этом запросе пользователями B, C, A again и C. После завершения второй итерации (фиксации, выполненной пользователем B), пользователь C одобрил ее. В то время это подразумевало утверждение первой фиксации пользователя A (при создании запроса на вытягивание), и новая политика будет успешной. После пятой итерации (последней фиксации пользователя C) утверждение было выполнено пользователем A. Это подразумевало утверждение для более ранней фиксации, выполненной пользователем C, но не подразумевало утверждение второй фиксации, выполненной пользователем A в четвертой итерации. Для успешного выполнения новой политики неутвержденная итерация четыре должна быть одобрена пользователем B, C или любым другим пользователем, который не внес никаких изменений в запрос на вытягивание.

Образ управления разрешениями.

Azure Artifacts

Введение в поддержку Azure Artifacts для контейнеров Cargo (общедоступная предварительная версия)

Мы рады сообщить, что Azure Artifacts теперь предлагает встроенную поддержку контейнеров Cargo. Эта поддержка включает четность функций по отношению к существующим протоколам, а также crates.io быть доступными в качестве источника вышестоящий. Теперь разработчики и команды Rust могут легко использовать, публиковать, администрирование и совместное использование контейнеров Cargo, используя надежную инфраструктуру Azure и оставаясь в знакомой среде Azure DevOps.

Для предварительной версии регистрация не требуется; Чтобы начать работу, перейдите к проекту Azure DevOps, выберите Артефакты и следуйте инструкциям по подключению проекта Rust к веб-каналу Azure Artifacts.

Дальнейшие действия

Примечание

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

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

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

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

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

Снимок экрана. Внесите предложение.

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

Thanks,

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