Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Los grupos de servicios de Azure ofrecen una manera flexible de organizar y administrar recursos entre suscripciones y grupos de recursos, en paralelo a cualquier jerarquía de recursos de Azure existente. Son ideales para escenarios que requieren agrupación entre límites, permisos mínimos y agregaciones de datos entre recursos. Estas características permiten a los equipos crear colecciones de recursos adaptadas que se adapten a las necesidades operativas, organizativas o basadas en roles. Este artículo le ayuda a proporcionar información general sobre qué son los grupos de servicios, los escenarios para usarlos y hechos importantes.
Important
Los grupos de servicios de Azure se encuentran actualmente en versión preliminar pública. Consulte Términos de uso complementarios para las versiones preliminares de Microsoft Azure para conocer los términos legales que se aplican a las características de Azure que se encuentran en la versión beta, en versión preliminar o que todavía no se han publicado para que estén disponibles con carácter general.
Principales capacidades
- Varias jerarquías: los grupos de servicios habilitan escenarios en los que los recursos se pueden agrupar en distintas vistas con varios fines.
- Pertenencia flexible: los grupos de servicios permiten agrupar los recursos de distintas suscripciones, lo que proporciona una vista unificada y funcionalidades de administración. También permiten la agrupación de suscripciones, grupos de recursos y recursos. Los mismos recursos se pueden conectar a muchos grupos de servicios diferentes, lo que permite crear y usar diferentes roles y escenarios de clientes.
- Administración de privilegios bajos: los grupos de servicios están diseñados para funcionar con permisos mínimos, lo que garantiza que los usuarios puedan administrar recursos sin necesidad de derechos de acceso excesivos.
Escenarios de ejemplo
Los clientes pueden crear muchas vistas diferentes que apoyen la manera en que organizan sus recursos.
Vista unificada de recursos
- Las organizaciones con varias aplicaciones y entornos pueden usar grupos de servicios para crear una vista centralizada de la información de recursos en distintos entornos. Los recursos de miembro o los contenedores de recursos de varios entornos dentro de diferentes grupos de administración o suscripciones se pueden vincular a un único grupo de servicios, lo que proporciona un punto de referencia unificado para los detalles de los recursos.
- Dado que los grupos de servicios no heredan permisos de sus miembros, los clientes pueden aplicar principios de privilegios mínimos para asignar permisos a los grupos de servicios que permiten ver la información de los recursos. Esta funcionalidad permite escenarios en los que dos usuarios pueden acceder al mismo grupo de servicios, pero solo se permite ver determinados recursos.
Creando inventario
- Los clientes pueden conectar recursos a los grupos de servicios para obtener una vista consolidada de todos los recursos de un tipo o función concretos en todo el entorno.
- Variables de personas
- Con los grupos de servicios, las organizaciones tienen la capacidad de administrar varias jerarquías en los mismos recursos para distintos roles y sus propias vistas individuales. Los clientes pueden usar los mismos recursos para ser miembros de un grupo de servicios de carga de trabajo, un grupo de servicios de departamento y un grupo de servicios con todos los recursos de producción.
Cómo funciona
Los grupos de servicios de Azure son una jerarquía de nivel de inquilino paralelo que permite la agrupación de recursos. La separación de grupos de administración, suscripciones y grupos de recursos permite que los grupos de servicios se conecten muchas veces a distintos recursos y contenedores de recursos sin afectar a las estructuras existentes.
Información sobre los grupos de servicios
- Se crea un grupo de servicios en el proveedor de recursos Microsoft.Management.
- Los grupos de servicios permiten el anidamiento automático para crear hasta 10 "niveles" de profundidad de agrupación. El anidamiento se puede administrar a través de la propiedad "principal" dentro del recurso grupo de servicios.
- Las asignaciones de roles del grupo de servicios solo se pueden heredar a los Grupos de servicios secundarios. No hay herencia a través de las pertenencias a los recursos o contenedores de recursos.
- Hay un límite de 2000 miembros del grupo de servicio procedentes de la misma suscripción.
- En la ventana Vista previa, hay un límite de 10 000 grupos de servicios en un solo inquilino.
- Los grupos de servicios y los identificadores de miembro del grupo de servicio admiten hasta 250 caracteres. Pueden ser caracteres alfanuméricos y especiales: - _ ( ). ~
- Los grupos de servicios requieren un identificador único global. Dos inquilinos de Microsoft Entra no pueden tener un grupo de servicios con identificadores idénticos.
- La pertenencia a grupos de servicios se administra mediante "Microsoft.Relationship/ServiceGroupMember" en el miembro deseado (un recurso, un grupo de recursos o una suscripción) al establecer como destino el grupo de servicios deseado.
Agrupaciones de Azure Resource Manager
Azure ofrece una amplia variedad de contenedores de recursos que permiten a nuestros clientes administrar recursos a muchas escalas diferentes. Los grupos de servicios son solo los más recientes de una familia de contenedores de Azure Resource Manager (ARM) que se usan para organizar el entorno.
En esta tabla se muestra un resumen de las diferencias entre los grupos.
Comparación de escenarios
| Scenario | Grupo de recursos | Subscription | Grupo de administración | Grupo de servicios | Tags |
|---|---|---|---|---|---|
| Requerir herencia de la asignación en el ámbito a cada recurso miembro o descendiente | Supported* | Supported | Supported | No está soportado | No está soportado |
| Consolidación de recursos para la reducción de asignaciones de roles o asignaciones de directivas | Supported | Supported | Supported | No está soportado | No está soportado |
| Agrupación de recursos que se comparten entre límites de ámbito. Ex. Recursos de redes globales en un grupo de recursos o suscripción que se comparten entre varias aplicaciones que tienen sus propias suscripciones o grupos de recursos. | No está soportado | No está soportado | No está soportado | Supported | Supported |
| Crear agrupaciones independientes que permitan agregaciones independientes de métricas | No está soportado | Supported | Supported | Supported | Supported** |
| Imponer restricciones a nivel empresarial o configuraciones organizacionales a lo largo de muchos recursos | Supported* | Supported* | Supported* | No está soportado | Supported*** |
*: Cuando se aplica una directiva a un ámbito, el cumplimiento es para todos los miembros dentro del ámbito. Por ejemplo, en un grupo de recursos solo se aplica a los recursos que contiene.
**: Las etiquetas se pueden aplicar entre ámbitos y se agregan a los recursos individualmente. Azure Policy tiene directivas integradas que pueden ayudar a administrar etiquetas.
: las etiquetas de Azure se pueden usar como criterios en Azure Policy para aplicar directivas a determinados recursos. Las etiquetas de Azure están sujetas a limitaciones.
Hechos importantes sobre los grupos de servicios
- Un solo inquilino puede admitir 10 000 grupos de servicios.
- El árbol del grupo de servicios puede admitir hasta 10 niveles de profundidad. Este límite no incluye el nivel raíz.
- Cada grupo de servicios puede tener muchos elementos secundarios.
- Un solo nombre o identificador de grupo de servicio puede tener hasta 250 caracteres.
- No hay límites de número de miembros de grupos de servicios, pero hay un límite de 2000 relaciones (incluido ServiceGroupMember) dentro de una suscripción.
El grupo de servicios raíz
Los grupos de servicios, de forma similar a los grupos de administración, tienen un único grupo de servicios raíz, que es el grupo principal de todos los grupos de servicios en ese inquilino. El identificador del grupo de servicios raíz es el mismo que su identificador de inquilino.
Los grupos de servicios crean el grupo de servicios raíz en la primera solicitud recibida dentro del inquilino y los usuarios no pueden crear ni actualizar el grupo de servicios raíz. "/providers/microsoft.management/servicegroups/[tenantId]"
El acceso a la raíz debe proporcionarse desde un usuario con permisos "microsoft.authorization/roleassignments/write" en el nivel de inquilino. Por ejemplo, el administrador global del inquilino puede elevar su acceso en el inquilino para tener estos permisos. Detalles sobre cómo elevar los accesos de administrador global de inquilinos
Controles de acceso basados en roles
Hay tres definiciones de roles integradas para admitir grupos de servicios en la versión preliminar.
Note
Los controles de acceso basados en roles personalizados no se admiten durante la versión preliminar.
Administrador de grupos de servicios: este rol integrado administra todos los aspectos de los grupos de servicios y las relaciones y es el rol predeterminado que se asigna a los usuarios cuando crean un grupo de servicios.
Colaborador del grupo de servicios: este rol integrado debe proporcionarse a los usuarios cuando necesiten crear o administrar el ciclo de vida de un grupo de servicios. Este rol permite todas las acciones, excepto las funcionalidades de asignación de roles.
Lector de grupo de servicios: este rol integrado proporciona acceso de solo lectura a la información del grupo de servicios y se puede asignar a otros recursos para visualizar las relaciones conectadas.
Cualquier persona con permisos válidos dentro del tenant puede crear un grupo de servicios en la raíz. El usuario que crea el grupo de servicios se convierte en el "Administrador del grupo de servicios". Para poder editar el grupo de servicios o crear grupos de servicios secundarios, un usuario debe tener el rol de "Colaborador del grupo de servicios" dentro de ese grupo de servicios. Para agregar miembros, los usuarios deben tener "Colaborador del grupo de servicios" en el grupo de servicios y Microsoft.Relationship/write en el recurso.