Что такое группы служб Azure?

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

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

Зачем использовать группы служб?

Группы служб решают общую проблему: иерархия ресурсов Azure (группы управления → подписки → группы ресурсов) может не отражать, как работают ваши команды. Рассмотрим пример.

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

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

Когда использовать группы служб или другие группировки

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

Необходимые условия

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

Ключевые возможности

• Несколько иерархий: группы служб позволяют использовать сценарии, в которых ресурсы можно группировать в разных топологиях для нескольких целей.
• Гибкое членство: группы служб позволяют объединять ресурсы из разных подписок, предоставляя унифицированные возможности представления и управления. Они также позволяют группировать подписки, группы ресурсов и ресурсы. Одни и те же ресурсы могут быть подключены ко многим разным группам служб, что позволяет создавать и использовать разные пользовательские лица и сценарии.
• Управление низкими привилегиями: группы служб предназначены для работы с минимальными разрешениями, гарантируя, что пользователи могут управлять ресурсами без чрезмерного доступа.

Примеры сценариев

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

• Унифицированное представление ресурсов

  • Организации с несколькими приложениями и средами могут использовать группы служб для создания централизованного представления сведений о ресурсах в разных средах. Ресурсы-члены или контейнеры ресурсов из различных сред в разных группах управления или подписках могут быть связаны с одной группой сервисов, предоставляя единую эталонную точку для сведений о ресурсах.
  • Так как группы служб не наследуют разрешения от своих членов, клиенты могут применять принципы наименьших привилегий для назначения разрешений на группы служб, которые позволяют просматривать сведения о ресурсах. Эта возможность позволяет реализовать сценарии, в которых два пользователя могут получить доступ к одной и той же группе служб, но только одному из них разрешён доступ к определённым ресурсам и их изменение.

• Создание инвентаризации

  • Клиенты могут подключать ресурсы к группам служб, чтобы получить консолидированное представление всех ресурсов определенного типа или функции во всей среде.

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

Принцип работы

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

Сведения о группах служб

• Группа служб создается в поставщике ресурсов Microsoft.Management.
• Группы служб позволяют создавать вложенные структуры до 10 уровней глубины группировки. Вложение можно управлять с помощью свойства parent в ресурсе группы служб.
• Назначения ролей в группе служб можно наследоваться только дочерним группам служб. Нет наследования через членство в ресурсах или контейнерах ресурсов.
• Существует ограничение в 2000 членов группы служб, поступающих из одной подписки.
• В одном арендаторе может быть не более 10 000 групп служб.
• Идентификаторы групп служб и участников группы служб поддерживают до 250 символов. Они могут быть буквенно-цифровыми и специальными символами: - _ ( ). ~
• Для групп служб требуется глобальный уникальный идентификатор. Два клиента Microsoft Entra не могут иметь группу служб с идентичными идентификаторами.
• Членство в группах служб управляется через 'Microsoft.Relationship/ServiceGroupMember' на нужном элементе (ресурсе, группе ресурсов или подписке) при нацеливании на необходимую группу служб.

Группировки в Azure Resource Manager

Azure предлагает широкий спектр контейнеров ресурсов, которые позволяют нашим клиентам управлять ресурсами в различных масштабах. Группы служб являются самыми новыми в семействе контейнеров Azure Resource Manager (ARM), используемых для упорядочивания среды.

В этой таблице показана сводка различий между группами.

Сравнение сценариев

*: если политика применяется к области, принудительное применение относится ко всем членам в области. Например, в группе ресурсов она применяется только к ресурсам под ним.

**. Теги могут применяться между областями и добавляться в ресурсы по отдельности. Политика Azure имеет встроенные политики, которые помогают управлять тегами.

: теги Azure можно использовать в качестве критериев в Политика Azure для применения политик к определенным ресурсам. Azure теги подвергаются ограничениям.

Группа базовых услуг

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

Группы служб создают корневую группу служб при получении первого запроса в пределах арендатора, и пользователи не могут создавать или обновлять корневую группу служб. "/providers/microsoft.management/servicegroups/[tenantId]"

Доступ к корневому каталогу должен быть предоставлен пользователю с разрешениями microsoft.authorization/roleassignments/write на уровне клиента. Например, глобальный администратор арендатора может увеличить уровень доступа арендатора, чтобы иметь эти разрешения. Сведения о повышении доступа глобального администратора клиента

Элементы управления доступом на основе ролей

Существует три встроенных определения ролей для поддержки групп служб в предварительной версии.

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

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

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

Любой пользователь с допустимыми разрешениями в клиенте может создать группу служб под корнем. Пользователь, создающий группу служб, становится администратором группы служб. Чтобы изменить группу служб или создать дочерние группы служб, пользователь должен иметь "Участника группы служб" в этой группе служб. Чтобы добавить участников, у пользователей должны быть права "Участник группы услуг" в группе услуг и "Microsoft.Relationship/write" на ресурсе.

Связанный контент

• Краткое руководство. Создание группы служб с помощью REST API
• Практическое руководство. Управление группами служб
• Подключение членов группы служб с помощью REST API