Introducción a la autenticación de cuentas de Azure Automation

  • Artículo

Importante

Las cuentas de ejecución de Azure Automation, incluidas las cuentas de ejecución clásicas, se retiraron el 30 de septiembre de 2023 y se reemplazaron por identidades administradas. Ya no se podrán crear o renovar cuentas de ejecución a través de Azure Portal. Para obtener más información, consulta migrar de una cuenta de ejecución existente a una identidad administrada.

Azure Automation le permite automatizar tareas en recursos de Azure, locales y de otros proveedores de servicios en la nube como Amazon Web Services (AWS). Puede usar runbooks para automatizar las tareas, o bien una instancia de Hybrid Runbook Worker si tiene que administrar procesos empresariales u operativos fuera de Azure. Para trabajar en cualquiera de estos entornos, se requieren permisos para proteger el acceso a los recursos con los derechos mínimos necesarios.

En este artículo se tratan los distintos escenarios de autenticación que se admiten en Azure Automation y se indica cómo empezar a trabajar según los entornos que haya que administrar.

Cuenta de Automation

Cuando inicia Azure Automation por primera vez, debe crear al menos una cuenta de Automation. Las cuentas de Automation le permiten aislar sus recursos, runbooks, activos y configuraciones de Automation de los recursos de otras cuentas. Puede usar cuentas de Automation para separar los recursos en entornos lógicos independientes o responsabilidades delegadas. Por ejemplo, puede usar una cuenta para desarrollo, otra para producción y otra para su entorno local. O bien, puede dedicar una cuenta de Automation para administrar las actualizaciones del sistema operativo en todas las máquinas con Update Management.

Una cuenta de Azure Automation es diferente de su cuenta Microsoft o de las cuentas creadas en su suscripción de Azure. Para obtener una introducción a la creación de una cuenta de Automation, consulte Creación de una cuenta independiente de Azure Automation.

Recursos de Automation

Los recursos de Automation de cada cuenta de Automation están asociados a una sola región de Azure, pero la cuenta puede administrar todos los recursos de la suscripción de Azure. El principal motivo para crear cuentas de Automation en distintas regiones es si tiene directivas que requieren que los datos y recursos se aíslen en una región específica.

Todas las tareas que se crean en los recursos con Azure Resource Manager y los cmdlets de PowerShell en Azure Automation deben autenticarse en Azure mediante la autenticación basada en credenciales de la identidad organizativa de Microsoft Entra.

Identidades administradas

Una identidad administrada de Microsoft Entra ID permite al runbook acceder fácilmente a otros recursos protegidos por Microsoft Entra. La plataforma Azure administra la identidad y no es necesario que lleve a cabo el aprovisionamiento ni la rotación de los secretos. Para más información sobre las identidades administradas en Microsoft Entra ID, consulte Identidades administradas para recursos de Azure.

Las identidades administradas son la manera recomendada de autenticarse en los runbooks y es el método de autenticación predeterminado para la cuenta de Automation.

Estas son algunas de las ventajas de usar las identidades administradas:

  • El uso de una identidad administrada en lugar de la cuenta de ejecución de Automation simplifica la administración.

  • Las identidades administradas se pueden usar sin ningún costo adicional.

  • No tiene que especificar el objeto de conexión de ejecución en el código del runbook. Puede acceder a los recursos con la identidad administrada de la cuenta de Automation desde un runbook sin crear certificados, conexiones, etc.

Una cuenta de Automation puede autenticarse mediante dos tipos de identidades administradas:

  • Una identidad asignada por el sistema está asociada a la aplicación y se elimina si se elimina la aplicación. Una aplicación solo puede tener una identidad asignada por el sistema.

  • Una identidad asignada por el usuario es un recurso de Azure independiente que puede asignarse a la aplicación. Una aplicación puede tener varias identidades asignadas por el usuario.

Nota:

Las identidades asignadas por el usuario solo se admiten para trabajos en la nube. Para más información sobre las distintas identidades administradas, vea Administración de tipos de identidad.

Para más información acerca del uso de identidades administradas, consulte Habilitación de la identidad administrada para Azure Automation.

Permisos de suscripción

Debe tener el permiso Microsoft.Authorization/*/Write. Este permiso se obtiene mediante la pertenencia a uno de los siguientes roles integrados de Azure:

Para más información sobre los permisos de suscripción clásicos, consulte Administradores de la suscripción clásica de Azure.

Permisos de Microsoft Entra

Para poder renovar la entidad de servicio, debe ser miembro de uno de los siguientes roles integrados de Microsoft Entra:

La pertenencia se puede asignar a TODOS los usuarios del inquilino en el nivel de directorio, que es el comportamiento predeterminado. Puede conceder pertenencia a cualquiera de los roles en el nivel de directorio. Para más información, consulte ¿Quién tiene permiso para agregar aplicaciones a la instancia de Microsoft Entra?

Permisos de la cuenta de Automation

Para poder actualizar la cuenta de Automation, debe ser miembro de uno de los siguientes roles de la cuenta de Automation:

Para obtener más información sobre los modelos de implementación clásico y de Azure Resource Manager, consulte Implementación de Resource Manager e implementación clásica.

Nota:

Las suscripciones del Proveedor de soluciones en la nube (CSP) de Azure solo admiten el modelo de Azure Resource Manager. Los servicios que no son de Azure Resource Manager no están disponibles en el programa. Cuando se usa una suscripción al programa CSP, no se crea la cuenta de ejecución de Azure clásico, sino la cuenta de ejecución de Azure. Para más información acerca de las suscripciones de CSP, consulte Servicios disponibles en las suscripciones de CSP.

Control de acceso basado en rol

El control de acceso basado en roles está disponible en Azure Resource Manager para conceder las acciones permitidas a una cuenta de usuario de Microsoft Entra y a una cuenta de ejecución, y para autenticar la entidad de servicio. Para más información que le ayude a desarrollar su modelo de administración de permisos de Automation, consulte el artículo Control de acceso basado en rol en Azure Automation.

Si tiene controles de seguridad estrictos para la asignación de permisos en los grupos de recursos, debe asignar la pertenencia a la cuenta de ejecución al rol Colaborador en el grupo de recursos.

Nota:

Se recomienda no utilizar el rol Colaborador de Log Analytics para ejecutar trabajos de Automation. En su lugar, cree el rol personalizado Colaborador de Azure Automation y utilícelo para las acciones relacionadas con la cuenta de Automation.

Autenticación de Runbook con Hybrid Runbook Worker

Los runbooks que se ejecutan en una instancia de Hybrid Runbook Worker en su centro de datos o en los servicios de computación de otros entornos de nube, como AWS, no pueden usar el mismo método que se usa normalmente para los runbooks que se autentican en recursos de Azure. Esto se debe a que esos recursos se ejecutan fuera de Azure y, por lo tanto, requieren sus propias credenciales de seguridad definidas en Automatización para la autenticación en los recursos a los que tienen acceso localmente. Para más información sobre la autenticación de runbooks con trabajos de runbook, consulte Ejecución de runbooks en Hybrid Runbook Worker.

Con los runbooks que utilizan instancias de Hybrid Runbook Worker en máquinas virtuales de Azure, puede utilizar la autenticación de runbook con identidades administradas en lugar de cuentas de ejecución para autenticarse en sus recursos de Azure.

Pasos siguientes