Descripción de las identidades de carga de trabajo

7 minutos

Los flujos de trabajo de implementación, las aplicaciones y el software requieren una manera especial de autenticarse. En esta unidad, aprenderá por qué las identidades de carga de trabajo son importantes para los flujos de trabajo de implementación, cómo encajan en el modelo de seguridad de Azure y cómo funcionan.

¿Por qué un flujo de trabajo necesita autenticarse?

Al implementar un archivo de Bicep, le pide a Azure Resource Manager que cree o modifique los recursos de Azure. En el escenario de ejemplo, ha creado un archivo de Bicep para implementar el sitio web de la empresa de juguetes. El archivo de Bicep declara recursos que incluyen un plan de Azure App Service, una aplicación y una instancia de Application Insights.

Al implementar el archivo, Resource Manager comprueba si los recursos existen. Si no existen, Resource Manager los crea. Si ya existe alguno, Resource Manager garantiza que su configuración coincida con la configuración especificada en el archivo de Bicep.

Todas estas operaciones requieren permiso, ya que acceden a los recursos de Azure y los modifican. Los permisos específicos necesarios para la implementación dependerán de lo que contenga el archivo de Bicep. A fin de implementar el archivo de ejemplo para el sitio web de la empresa de juguetes, debe tener los siguientes permisos dentro del grupo de recursos en el que se va a implementar:

La capacidad de crear implementaciones. Las implementaciones se consideran recursos con un tipo de Microsoft.Resources/deployments.
La capacidad de crear y modificar aplicaciones y planes de App Service.
La capacidad de crear y modificar instancias de Application Insights.

Hasta ahora, es probable que haya implementado los archivos de Bicep mediante la CLI de Azure o Azure PowerShell. Cuando se usan estas herramientas, normalmente emplea su cuenta de usuario y se autentica mediante el explorador. A esto se le llama identidad. Al enviar una implementación, Azure comprueba que la identidad tiene los permisos necesarios para hacer lo que especifica la plantilla de Bicep.

Después de pasar a un flujo de trabajo de implementación de Acciones de GitHub, debe usar un tipo de identidad diferente, ya que el flujo de trabajo ejecuta implementaciones sin su participación directa.

Tipos de identidades

Microsoft Entra ID es el servicio que administra identidades para Azure. Algunos de los principales tipos de identidades son:

Identidades de usuario: un usuario representa a una persona que normalmente inicia sesión de forma interactiva mediante un explorador. Los usuarios suelen tener comprobaciones de seguridad adicionales para realizar al iniciar sesión, como la autenticación multifactor (MFA) y el acceso condicional en función de su ubicación o red.
Grupos: un grupo representa una colección de usuarios. Los grupos no se autentican directamente, pero proporcionan una manera cómoda de asignar permisos a un conjunto de usuarios juntos.
Identidades de carga de trabajo: una carga de trabajo representa un proceso o sistema automatizado que normalmente no tiene un usuario ejecutándolo directamente. Una carga de trabajo puede iniciar sesión en Microsoft Entra ID, pero no hay ninguna persona iniciando sesión e interactuando con el proceso de autenticación. Las entidades de carga de trabajo no tienen MFA ni protecciones similares, porque esas características requieren que una persona realice una acción para demostrar su identidad.

Este módulo se centra en las identidades de carga de trabajo.

Identidades administradas

Una identidad administrada está asociada a un recurso de Azure. Azure administra automáticamente las credenciales. Cuando el recurso necesita acceder a algo, Azure inicia sesión automáticamente con las credenciales.

Las identidades administradas están disponibles para recursos hospedados en Azure, como máquinas virtuales y aplicaciones de App Service. Son una excelente manera de que los recursos de Azure se autentiquen en situaciones como la automatización de la administración de Azure, la conexión a bases de datos y la lectura de datos de secretos desde Azure Key Vault. También puede usar identidades administradas con Azure Arc para otros escenarios.

Cuando se trabaja flujos de trabajo de implementación, normalmente no se pueden usar identidades administradas. Las identidades administradas requieren que sea el propietario y administre los recursos de Azure que ejecutan las implementaciones. Cuando se trabaja con Acciones de GitHub, normalmente se basa en la infraestructura compartida que Microsoft o GitHub proporciona. Sin embargo, al usar una identidad de carga de trabajo con Acciones de GitHub, puede obtener la principal ventaja de las identidades administradas: no es necesario administrar ninguna credencial.

Sugerencia

En otras partes de la solución, si tiene la opción de usar una identidad administrada o usar una entidad de servicio normal, es mejor optar por una identidad administrada. Las identidades administradas son más fáciles trabajar y normalmente son más seguras.

¿Por qué no puede usar simplemente su cuenta de usuario?

Es posible que se pregunte por qué debe crear este nuevo tipo de objeto solo para autenticar un flujo de trabajo de implementación cuando tiene cuentas de usuario que funcionan perfectamente bien.

Las cuentas de usuario no están diseñadas para un uso desatendido. El proceso de autenticación de una cuenta de usuario a menudo comprueba que una persona sea la entidad que intenta iniciar sesión. Cada vez con mayor frecuencia, las organizaciones usan comprobaciones de seguridad adicionales durante la autenticación. Estas comprobaciones incluyen comprobaciones de MFA, CAPTCHA e inspección del dispositivo y la red que usa el usuario para que pueda comprobar la legitimidad de una solicitud de inicio de sesión.

Los flujos de trabajo están diseñados para ejecutar las implementaciones incluso cuando nadie está ejecutándolas activamente. De hecho, la mayoría de las ventajas de los flujos de trabajo de implementación proceden del hecho de que están automatizados y no requieren interacción humana.

Si almacena el nombre de usuario y la contraseña en un flujo de trabajo e intenta usarlos para iniciar sesión, probablemente no funcionarán. Aunque parezca que funcionan, pueden dejar de funcionar fácilmente en el futuro si Microsoft Entra ID o el administrador de la organización agregan más comprobaciones de seguridad al proceso de autenticación de usuario.

Advertencia

También es una mala idea guardar el nombre de usuario y la contraseña en cualquier lugar, ya que otra persona podría obtener acceso a ellos y, a continuación, usarlos para suplantarle.

Por estos motivos, las tareas de Acciones de GitHub integradas que interactúan con Azure no permiten proporcionar las credenciales de una cuenta de usuario. Requieren que use una identidad de carga de trabajo.

¿Cómo funcionan las identidades de carga de trabajo?

Las identidades de carga de trabajo son una característica de Microsoft Entra ID, que es un servicio de identidad global. Muchas empresas usan Microsoft Entra ID y cada empresa se denomina inquilino.

Microsoft Entra ID tiene un concepto de aplicación que representa un sistema, un software, un proceso o algún otro agente no humano. También, puede pensar en un flujo de trabajo de implementación como una aplicación.

Cuando crea una aplicación y le informa de ella a Microsoft Entra ID, se crea un objeto denominado registro de aplicación. Un registro de aplicación representa a la aplicación en Microsoft Entra ID.

Un registro de aplicación puede tener credenciales federadas asociadas. Las credenciales federadas no requieren que almacene ningún secreto. En su lugar, habilitan un servicio compatible como GitHub para usar una aplicación de Microsoft Entra.

Cuando el flujo de trabajo de Acciones de GitHub necesita autenticarse, se pone en contacto con Microsoft Entra ID a través de GitHub. GitHub indica a Microsoft Entra ID el nombre de la organización y el repositorio de GitHub y opcionalmente, también proporciona otra información. Si ha configurado una credencial federada que coincida con los detalles del repositorio, Microsoft Entra autentifica el flujo de trabajo de implementación. El flujo de trabajo puede usar los permisos que ha asignado a la aplicación.

Sugerencia

Al consultar un registro de aplicación en Azure Portal, verá muchas otras funcionalidades y configuraciones que podrían no parecer pertinentes. Esa es la razón por la que las aplicaciones pueden hacer muchas cosas en Microsoft Entra ID que están fuera del ámbito de las implementaciones de autenticación y del flujo de trabajo.

También puede crear una objeto de entidad de servicio en el inquilino de Microsoft Entra. Una entidad de servicio es como una copia de la aplicación para que use su propio inquilino de Microsoft Entra. Las entidades de servicio y las aplicaciones están estrechamente vinculadas. Usará una entidad de servicio más adelante en este módulo cuando conceda permiso de flujo de trabajo para acceder a Azure.

Nota