Azure Назначение группы DevOps для управления проектами

Question

Групповое присвоение проектам дает другой конечный результат в зависимости от того, как было выполнено назначение:

1. Если создано групповое правило и предоставлен доступ к проекту - доступ может также удалить в настройках правила группы, проекты могут иметь группу AD, назначенную в качестве члена.

2. Если для группы AD создано правило группы, и для этой же группы AD требуются дополнительные разрешения (скажем, запретить доступ к конвейеры) - группа AD должна быть добавлена ​​в качестве члена в группу DevOps (в этом случае группа DevOps не имеет правила группы). Тогда есть 3 возможности:

   • назначить проект для правила группы (как в сценарии 1), тогда группа DevOps не будет использоваться и будет действовать только как группа разрешений

   • Группа DevOps может быть добавлена ​​в проект из настроек проекта.

   • Группа AD может быть добавлена ​​в проект из настроек проекта.

   В двух последних случаях - правило группы AD имеет унаследованное назначение для этого проекта и нельзя удалить из настроек правила группы.

3. Для группы DevOps можно создать правило группы, и эта группа DevOps может иметь группу AD в качестве члена. Существует та же проблема, что если эту группу добавить в проект из настроек проекта - доступ не может быть отменен в настройках правила группы. Это немного лучше, чем вариант 2, потому что у вас есть группа и групповое правило для одной и той же группы, но затем управление уровнем доступа осуществляется не на уровне группы AD, а на уровне группы DevOps. 4. Может случиться так, что группа AD имеет правило группы и принадлежит к группе DevOps, которая также имеет правило группы, но я полагаю, что это не должно быть в реальной жизни

Как управлять доступом к проектам? Должен ли весь доступ управляться с уровня организации с использованием групп / назначений пользователей? Или это должно управляться на уровне проекта путем добавления участников? Из приведенного выше описания я вижу, что использование обоих этих методов может привести к путанице и путанице, когда некоторые права доступа могут быть аннулированы в настройках пользователя org, а другие - нет. Какая рекомендуемая здесь практика?

В настройках проекта пользователь имеет доступ к группам DevOps и всем группам AD (AFAK на основе разрешений AD) при добавлении участника в команду. Можно ли это контролировать из части DevOps? Чтобы этот пользователь мог добавлять только группы DevOps или группы AD, для которых создано правило группы? Это может быть связано с вопросом выше, но какова здесь рекомендуемая практика?

====== Добавление сценария для иллюстрации моих вопросов

Давайте рассмотрим этот сценарий: группы AD "Devs" и "QA" необходимо предоставить доступ к DevOps и проектам P1 и P2.

1. Администратор proj P1 может go в настройки proj -> команды и напрямую добавить группу AD "QA" проэктировать. Поскольку QA еще не является частью организации, я бы сказал, что это действие не должно быть разрешено. Можно ли помешать админам это делать? Любые аргументы, почему это должно быть разрешено?
2. Глобальный администратор (GA) добавляет правило группы для добавления группы AD "Devs" в DevOps. DevOps Group не создана для этого правила, поэтому AD группу необходимо добавить в новую или существующую DevOps группу. Допустим, создана новая группа «DevOps-Devs» и в нее в качестве участника добавлена ​​группа AD. Теперь владелец P2 хочет добавить разработчиков в проект. Он / она может добавить как AD "Devs", так и "DevOps-Devs" в настройках проекта. Я бы предположил, что следует использовать группу DevOps, верно? (опять же, как можно предотвратить добавление группы AD?)
3. GA создает группу DevOps под названием DevOps-QA. Затем он добавляет групповое правило для этой группы. Группа AD "QA" затем добавляется в качестве члена DevOps-QA. Какой метод (2 или 3) предпочтителен или рекомендован для создания правил группы? Тогда вместо добавления участников в проект через настройки proj, доступ к проекту назначается группе DevOps-QA в настройках правил группы -> Управление групповое правило

Кроме того, я бы сказал, что доступ пользователей / групп объявлений к проектам должен в основном управляться в настройках организации. Это не тот случай, если используются 1 и 2 опции. Если используется вариант 3, доступ можно добавить или отозвать из группы в настройках «управления правилами группы», однако было упомянуто, что правила группы в основном используются для лицензирования (и они должны быть созданы в первом место), так что теперь, похоже, это не лучшее место для управления доступом. Отсутствие мнения по этому вопросу и предоставление пользователям возможности использовать свой предпочтительный способ может привести к еще большей путанице в будущем управлении организацией. Какой подход вы можете порекомендовать?

Answer 1

Групповые правила используются в основном для лицензирования . @alictai предоставил объяснение в этой ссылке:

Azure DevOps включает лицензирование на основе групп для групп Azure Active Directory (Azure AD) и Azure DevOps группа, так что вы можете назначить уровень доступа или расширения для группы. Ресурсы в Azure DevOps назначаются всем членам группы. Это позволяет администраторам организации легко автоматизировать свои политики лицензирования.

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

Вкладка «Разрешения» в сведениях о группе предоставлена ​​для удобства просмотр того, что группа, и, следовательно, все пользователи (после входа в организацию) в группе имеют доступ.

---

Обновление:

1. Как ваша организация подключен к Azure Active Directory, вы можете повторно использовать Azure группы AD для массового управления разрешениями для вашей организации. Просто добавьте эти группы в группу, которую вы хотите. При добавлении группы QA в конкретный командный проект участники могут иметь доступ только к ресурсам в этом командном проекте. Для создания Azure групп AD и управления ими вам необходимы разрешения администратора Azure AD или администратор каталога должен делегировать вам эти разрешения на портале Azure. Если вы не хотите, чтобы администратор проекта добавлял Azure групп AD, вы не можете предоставлять им Azure разрешения администратора AD или делегата администратора каталога.

https://docs.microsoft.com/en-us/azure/devops/organizations/accounts/manage-azure-active-directory-groups?view=azure-devops&tabs=preview-page

Вы не можете предоставлять администраторам проекта Azure Разрешения администратора AD или делегата администратора каталога.

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

https://docs.microsoft.com/en-us/azure/devops/organizations/accounts/organization-management?view=azure-devops