Concesión de acceso a Azure para una entidad de servicio

Completado

Por sí sola, una entidad de servicio no puede hacer nada en su entorno de Azure. Tal como sucede cuando un usuario no puede trabajar con los recursos de Azure a menos que esté autorizado para hacerlo. En esta unidad, aprenderá a autorizar a las entidades de servicio para que implementen y configuren recursos de Azure, a la vez que evita conceder permisos innecesarios.

Nota:

Los comandos de esta unidad se muestran para ilustrar conceptos. No los ejecute todavía. Pronto va a practicar lo que aprenderá aquí.

Autorización de la entidad de servicio

Hasta ahora, se ha centrado en qué son las entidades de servicio y cómo se pueden usar para comprobar la identidad de una canalización para Microsoft Entra ID. Todo esto se trata de la autenticación.

Una vez que Microsoft Entra ID ha autenticado una entidad de servicio, la siguiente pregunta es: ¿qué puede hacer esta entidad de servicio? Este es el concepto de autorización. Y es responsabilidad del sistema de control de acceso basado en roles (RBAC) de Azure, a veces denominado administración de identidades y acceso (IAM). Mediante Azure RBAC, puede conceder a una entidad de servicio acceso a un grupo de recursos, una suscripción o un grupo de administración específicos.

Nota:

Todo lo que hace en este caso es usar el sistema Azure RBAC a fin de conceder acceso para crear y administrar recursos de Azure, como sus cuentas de almacenamiento, plan de App Service y redes virtuales. Microsoft Entra ID también tiene su propio sistema de roles, que a veces se denominan roles de directorio. Estos roles se usan para conceder permisos a las entidades de servicio para administrar Microsoft Entra ID. Este módulo no trata este tema en profundidad, pero tenga en cuenta que el término rol se puede usar para ambas situaciones en alguna documentación.

Selección de la asignación de roles adecuada para la canalización

Una asignación de roles tiene tres partes clave: a quién se asigna el rol (la persona asignada), lo que puede hacer (el rol) y a qué recurso o recursos se aplica la asignación de roles (el ámbito).

Persona asignada

Cuando se trabaja con una entidad de servicio, debe asignar roles para la misma. Use el identificador de aplicación de la entidad de servicio para identificar la entidad adecuada para esa persona asignada.

Role

Averiguar qué rol asignar puede requerir más esfuerzo. En Azure, hay algunos roles comunes:

• Lector, que permite a la persona asignada leer información sobre los recursos, pero no modificarlos ni eliminarlos.
• Colaborador, que permite a la persona asignada crear recursos y leer y modificar los existentes. Sin embargo, los colaboradores no pueden conceder a otras entidades de seguridad acceso a los recursos.
• Propietario, que permite el control total sobre los recursos, incluida la concesión de acceso a otras entidades de seguridad.

Precaución

Solo debe conceder a las entidades de servicio los permisos mínimos que necesitan para realizar su trabajo. La mayoría de las veces, el rol Propietario es demasiado permisivo para una canalización de implementación.

También hay una gran cantidad de roles específicos que proporcionan acceso solo a un subconjunto de funcionalidades. También puede crear su propia definición de roles personalizada para especificar la lista exacta de permisos que quiere asignar.

Nota:

Las definiciones de roles personalizados pueden ser una manera eficaz de conceder permisos a los recursos de Azure, pero puede resultar difícil trabajar con ellos. No siempre es fácil determinar exactamente qué permisos necesita agregar a una definición de rol personalizado, y es posible que las definiciones de roles se vuelvan accidentalmente demasiado restrictivas o demasiado permisivas. Si no está seguro de qué hacer, es mejor usar una de las definiciones de roles integrados en su lugar. Las definiciones de roles personalizados están fuera del ámbito de este módulo.

Ámbito

Debe determinar la extensión con la que se asigna el rol. Esta decisión afecta al número de recursos que la entidad de servicio puede modificar. Los ámbitos habituales incluyen:

• Recurso único: puede conceder acceso solo a un recurso específico. Normalmente, las canalizaciones de implementación no usan este ámbito porque una canalización crea recursos que aún no existen o vuelve a configurar varios recursos.
• Grupo de recursos: puede conceder acceso a todos los recursos de un grupo de recursos. Los colaboradores y propietarios también pueden crear recursos dentro del grupo. Esta es una buena opción para muchas canalizaciones de implementación.
• Suscripción: puede conceder acceso a todos los recursos de una suscripción. Si tiene varias aplicaciones, cargas de trabajo o entornos en una sola suscripción, puede conceder permisos en el ámbito de la suscripción. Sin embargo, esto suele ser demasiado permisivo para una canalización de implementación. En su lugar, debe considerar la posibilidad de determinar el ámbito de las asignaciones de roles a los grupos de recursos, a menos que el propio flujo de trabajo de implementación necesite crear grupos de recursos.

Recuerde que las asignaciones de roles se heredan. Si asigna un rol en una suscripción, la persona asignada tendrá acceso a todos los grupos de recursos y recursos dentro de esa suscripción.

Selección de la asignación de roles adecuada

Ahora que comprende los componentes de una asignación de roles, puede decidir los valores adecuados para sus escenarios. A continuación se mencionan algunas directrices generales que debe tener en cuenta:

• Use el rol menos permisivo que pueda. Si la canalización solo va a implementar plantillas básicas de Bicep y no administrará las asignaciones de roles, no use el rol Propietario.
• Use el ámbito más reducido que pueda. La mayoría de las canalizaciones solo necesitan implementar recursos en un grupo de recursos, por lo que no deben tener asignaciones de roles con ámbito de suscripción.
• Para muchas canalizaciones, una buena opción predeterminada para la asignación de roles es el rol Colaborador en el ámbito del grupo de recursos.
• Tenga en cuenta todo lo que hace la canalización y todo lo que podría hacer en el futuro. Por ejemplo, puede considerar la posibilidad de crear una definición de rol personalizado para la canalización de implementación del sitio web y concederle solo permisos para App Service y Application Insights. El próximo mes, quizá necesite agregar una cuenta de Azure Cosmos DB al archivo de Bicep, pero el rol personalizado bloqueará la creación de recursos de Azure Cosmos DB. En su lugar, a menudo es mejor usar un rol integrado o una combinación de roles integrados para evitar tener que cambiar repetidamente las definiciones de roles. Considere la posibilidad de usar Azure Policy para aplicar los requisitos de gobernanza a los servicios, SKU y ubicaciones permitidos.
• Pruebe la canalización para comprobar que la asignación de roles funcione.

Combinación y coincidencia de asignaciones de roles

Puede crear varias asignaciones de roles que proporcionen permisos diferentes en distintos ámbitos. Por ejemplo, puede asignar a una entidad de servicio el rol Lector con un ámbito de toda la suscripción y, a continuación, asignar por separado a la misma entidad de servicio el rol Colaborador para un grupo de recursos específico. Cuando la entidad de servicio intenta trabajar con el grupo de recursos, se aplica la asignación más permisiva.

Trabajar con varios entornos

Es probable que trabaje con varios entornos, como entornos de desarrollo, prueba y producción para las aplicaciones. Los recursos de cada entorno deben implementarse en diferentes suscripciones o grupos de recursos.

Debe crear entidades de servicio independientes para cada entorno y conceder a cada una el conjunto mínimo de permisos que necesita para sus implementaciones. Tenga especial cuidado y evite mezclar los permisos para las implementaciones de producción con los de las implementaciones en entornos que no son de producción.

Creación de una asignación de roles para una entidad de servicio

Cree una asignación de roles para una entidad de servicio con el comando az role assignment create. Debe especificar el usuario asignado, el rol y el ámbito:

az role assignment create \
  --assignee 00001111-aaaa-2222-bbbb-3333cccc4444 \
  --role Contributor \
  --scope "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/ToyWebsite" \
  --description "The deployment pipeline for the company's website needs to be able to create resources within the resource group."

Ahora se analizará cada argumento:

• --assignee especifica el valor de la entidad de servicio. Para evitar ambigüedades, se recomienda usar el identificador de aplicación.
• --role especifica el rol. Si usa un rol integrado, puede especificarlo por nombre. Si usa una definición de rol personalizado, especifique el identificador de definición de rol completo.
• --scope especifica el ámbito. Suele ser un identificador de recurso para un único recurso, un grupo de recursos o una suscripción.
• --description es una descripción legible de la asignación de roles.

Cree una asignación de roles para una entidad de servicio con el cmdlet New-AzRoleAssignment. Debe especificar el usuario asignado, el rol y el ámbito:

New-AzRoleAssignment `
  -ApplicationId 00001111-aaaa-2222-bbbb-3333cccc4444 `
  -RoleDefinitionName Contributor `
  -Scope '/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/ToyWebsite' `
  -Description "The deployment pipeline for the company's website needs to be able to create resources within the resource group."

Ahora analizaremos cada argumento:

• -ApplicationId especifica el identificador de registro de aplicación de la entidad de servicio.
• -RoleDefinitionName especifica el nombre de un rol integrado. Si usa una definición de rol personalizado, especifique el identificador de definición de rol completo mediante el argumento -RoleDefinitionId en su lugar.
• -Scope especifica el ámbito. Suele ser un identificador de recurso para un único recurso, un grupo de recursos o una suscripción.
• -Description es una descripción legible de la asignación de roles.

Sugerencia

Se recomienda proporcionar una justificación para las asignaciones de roles mediante una descripción. Una descripción ayuda a todos los usuarios que revisan las asignaciones de roles más adelante a comprender su finalidad y a comprender cómo eligió el usuario asignado, el rol y el ámbito.

Nota:

Las asignaciones de roles pueden tardar unos minutos en activarse.

Creación de una entidad de servicio y una asignación de roles en una operación

También puede crear una asignación de roles al mismo tiempo que crea una entidad de servicio. El código es similar al comando que usó para crear una entidad de servicio en las unidades anteriores, pero con algunos argumentos adicionales:

az ad sp create-for-rbac \
  --name MyPipeline \
  --role Contributor \
  --scopes "/subscriptions/f0750bbe-ea75-4ae5-b24d-a92ca601da2c/resourceGroups/ToyWebsite"

$servicePrincipal = New-AzADServicePrincipal `
  -DisplayName MyPipeline `
  -Role Contributor `
  -Scope '/subscriptions/f0750bbe-ea75-4ae5-b24d-a92ca601da2c/resourceGroups/ToyWebsite'

Concesión de acceso mediante Bicep

Las asignaciones de roles son recursos de Azure. Esto significa que puede crear una asignación de roles mediante Bicep. Puede hacerlo si inicializa sus grupos de recursos mediante Bicep y, a continuación, implementa los recursos en el grupo de recursos mediante una entidad de servicio. Esta es una definición de Bicep de ejemplo para la asignación de roles anterior:

resource roleAssignment 'Microsoft.Authorization/roleAssignments@2023-04-01-preview' = {
  name: guid(principalId, roleDefinitionId, resourceGroup().id)
  properties: {
    principalType: 'ServicePrincipal'
    roleDefinitionId: subscriptionResourceId('Microsoft.Authorization/roleDefinitions', roleDefinitionId)
    principalId: principalId
    description: 'The deployment pipeline for the company\'s website needs to be able to create resources within the resource group.'
  }
}

Ahora analizaremos cada argumento:

• namees un identificador único para la asignación de roles. Debe tener el formato de un identificador único global (GUID). Se recomienda usar la función guid() de Bicep para crear un GUID y usar el identificador de entidad de seguridad, el identificador de definición de roles y el ámbito como argumentos de inicialización de la función, a fin de asegurarse de que se cree un nombre único para cada asignación de roles.
• principalType se debe establecer en ServicePrincipal.
• roleDefinitionId es el identificador de recurso completo para la definición de roles que se va a asignar. Principalmente trabaja con roles integrados, y encontrará el identificador de definición de roles en la documentación de roles integrados de Azure. Por ejemplo, el rol Colaborador tiene el identificador de definición de rol b24988ac-6180-42a0-ab88-20f7382dd24c. Cuando se especifica en el archivo de Bicep, se expresa mediante un identificador de recurso completo, como /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c.
• principalId es el identificador de objeto de la entidad de servicio. Asegúrese de no usar el identificador de aplicación ni el identificador de objeto del registro de la aplicación.
• description es una descripción legible de la asignación de roles.