Concesión de acceso a una identidad de carga de trabajo a Azure

  • 6 minutos

Por sí misma, una identidad de carga de trabajo no puede hacer nada en su entorno de Azure, al igual que el modo en que 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 identidades de carga de trabajo para que implementen y configuren recursos de Azure, a la vez que evita conceder permisos innecesarios.

Autorización de identidad de carga de trabajo

Hasta ahora, se ha centrado en qué son las identidades de carga de trabajo y cómo se pueden usar para comprobar la identidad de un flujo de trabajo de implementación para Microsoft Entra ID. Todo esto se trata de la autenticación.

Una vez que Microsoft Entra ID ha autenticado una identidad de carga de trabajo, la siguiente pregunta es: ¿qué puede hacer esta identidad de carga de trabajo? 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 identidad de carga de trabajo acceso a un grupo de recursos, una suscripción o un grupo de administración específicos.

Nota:

Todo lo que está haciendo aquí es usar el sistema de Azure RBAC para garantizar el acceso y crear y gestionar los recursos de Azure, como sus cuentas de almacenamiento, plan de App Service de Azure y las 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 a fin de conceder permisos a las identidades de carga de trabajo para administrar Microsoft Entra ID. Este módulo no trata este tema en profundidad, pero tenga en cuenta que el término rol se usa para ambas situaciones en alguna documentación.

Selección de la asignación de roles adecuada para el flujo de trabajo

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 trabaje con una identidad de carga de trabajo, asigne funciones. Para asignar un rol, primero debe crear una entidad de servicio, lo que le permite conceder los roles de aplicación en Azure. Después de crear el servicio principal, puede continuar trabajando con la ID del registro de la aplicación.

Para crear una entidad de servicio, use el comando az ad sp create y especifique el identificador de aplicación del registro de aplicación:

az ad sp create --id A123b4567c-1234-1a2b-2b1a-1234abc12345

Para crear una entidad de servicio, use el cmdlet New-AzADServicePrincipal y especifique el identificador de aplicación del registro de aplicación:

New-AzADServicePrincipal -AppId A123b4567c-1234-1a2b-2b1a-1234abc12345

Rol

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

  • Lector: Permite a la persona asignada leer información sobre los recursos, pero no modificarlos ni eliminarlos.
  • Colaborador: 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: permite el control total sobre los recursos, incluida la concesión de acceso a otras entidades de seguridad.

Precaución

Conceda identidades de carga de trabajo solo con un mínimo de permisos necesarios para hacer su trabajo. La mayoría de las veces, el rol Propietario es demasiado permisivo para un flujo de trabajo de implementación.

También hay muchos roles específicos que dan acceso simplemente a un subconjunto de la funcionalidad. Incluso 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 con exactitud que permisos necesita añadir a una definición de role personalizada. De forma accidental podría hacer dichas definiciones demasiado restrictivas o demasiado permisivas.

Si no está seguro de lo qué hacer, es mejor usar una de las definiciones de roles incorporadas. 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 identidad de la carga de trabajo puede modificar. Los ámbitos habituales incluyen:

  • Recurso único: puede conceder acceso a simplemente un recurso específico. Normalmente, los flujos de trabajo de implementación no usan este ámbito porque un flujo de trabajo 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 muchos flujo de trabajo 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 un flujo de trabajo 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 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 tiene 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 el flujo de trabajo solo va a implementar archivos básicos 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 los flujos de trabajo solo necesitan implementar recursos en un grupo de recursos, por lo que no deben tener asignaciones de roles con ámbito de suscripción.

  • Para muchos flujos de trabajo, 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 el flujo de trabajo y todo lo que podría hacer en el futuro. Por ejemplo, podría considerar el crear una definición de rol personalizado para su utilización en la tasa de trabajo del sitio web y conceder permisos solo 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 el flujo de trabajo 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, podría asignar una identidad de la carga de trabajo a la función de Reader con un ámbito de toda la suscripción. Por separado, podría asignar la misma identidad de la carga de trabajo al rol de Contributor para un grupo de recurso específico. Cuando la identidad de carga de trabajo 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 identidades de carga de trabajo independientes para cada entorno. Conceda a cada identidad de la carga de trabajo el conjunto mínimo de permisos que necesita para su utilización. Tenga especialmente cuidado en evitar los permisos mixtos para la implementación de producción con permisos para las implementaciones de ambientes no productivos.

Creación de una asignación de roles para una identidad de carga de trabajo

Para crear una asignación de roles para una identidad de carga de trabajo, use el comando az role assignment create. Debe especificar el usuario asignado, el rol y el ámbito:

az role assignment create \
  --assignee A123b4567c-1234-1a2b-2b1a-1234abc12345 \
  --role Contributor \
  --scope "/subscriptions/B123a4567c-1234-2b1a-1b2b-11a2b01b2b3c0/resourceGroups/ToyWebsite" \
  --description "The deployment workflow for the company's website needs to be able to create resources within the resource group."

Ahora se analizará cada argumento:

  • --assignee especifica la identidad de la carga de trabajo. Puede especificar esto de varias formas, pero usar la ID de la aplicación es un procedimiento recomendado porque evita ambigüedad.
  • --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.

Para crear una asignación de roles para una identidad de carga de trabajo, use el cmdlet New-AzRoleAssignment. Especifique el beneficiario, el rol y el ámbito:

New-AzRoleAssignment `
  -ApplicationId A123b4567c-1234-1a2b-2b1a-1234abc12345 `
  -RoleDefinitionName Contributor `
  -Scope '/subscriptions/B123a4567c-1234-2b1a-1b2b-11a2b01b2b3c0/resourceGroups/ToyWebsite' `
  -Description "The deployment workflow 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 identidad de carga de trabajo.
  • -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.

Conceda acceso usando Bicep

Las asignaciones de roles son recursos de Azure. Esto significa que puede crear una asignación de roles mediante Bicep. Puede hacer esto si inicializa sus grupos de recursos usando Bicep, luego implemente los recursos en el grupo de recurso usando una identidad de carga de trabajo. Este es un ejemplo de definición de Bicep para la asignación de rol previo:

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

Ahora se analizará cada argumento:

  • name es un identificador único a nivel global (GUID) para la asignación del rol. Se recomienda usar la guid() función en Bicep para crear un GUID. Para asegurarse de que crea un nombre único para cada asignación del rol, use la ID principal, la ID de definición del rol, y el ámbito como argumentos principales para la función.

  • principalType se debe establecer en ServicePrincipal.

  • roleDefinitionId es el ID de recurso completo para la definición de rol que está asignando. Usted principalmente trabaja con roles incorporados, por lo que encontrará la ID de la definición del rol en la documentación de funciones incorporadas en Azure.

    Por ejemplo, el rol Colaborador tiene el identificador de definición de rol b24988ac-6180-42a0-ab88-20f7382dd24c. Cuando lo especifica en su archivo Bicep, usted usa un recurso completo cualificado de ID, tal como/subscriptions/B123a4567c-1234-2b1a-1b2b-11a2b01b2b3c0/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.