Información sobre las entidades de servicio
Las entidades de servicio proporcionan una manera de autenticar canalizaciones, aplicaciones y software. En esta unidad, aprenderá por qué las entidades de servicio son importantes para las canalizaciones de implementación, cómo encajan en el modelo de seguridad de Azure y cómo funcionan.
¿Por qué una canalización necesita autenticarse?
Al implementar una plantilla de Bicep, le pide a Azure Resource Manager que cree o modifique los recursos de Azure. En este escenario de ejemplo, ha creado una plantilla de Bicep para implementar el sitio web de la empresa de juguetes. La plantilla de Bicep declara recursos que incluyen un plan de Azure App Service, una aplicación y una instancia de Application Insights.
Al implementar la plantilla, 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 la plantilla.
Todas estas operaciones requieren permisos, 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 la plantilla. A fin de implementar la plantilla de Bicep 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 las plantillas 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 mover una canalización, debe usar un tipo de identidad diferente, ya que la canalización ejecuta implementaciones sin su participación directa.
Tipos de entidades de seguridad
Microsoft Entra ID es el servicio que administra identidades para Azure. Microsoft Entra ID tiene varios tipos de identidades, que también se denominan entidades de seguridad:
- 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.
- 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.
- Una entidad de servicio representa un proceso o sistema automatizado que normalmente no tiene un usuario ejecutándolo directamente.
- Una identidad administrada es un tipo especial de entidad de servicio que está diseñado para situaciones en las que una persona no está implicada en el proceso de autenticación.
Entidades de servicio
Una entidad de servicio es un tipo de cuenta. 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 servicio no tienen MFA ni protecciones similares, porque requieren que una persona realice una acción para demostrar su identidad.
En Microsoft Entra ID, una entidad de servicio se identifica mediante un id. de aplicación y una credencial. El identificador de aplicación es un identificador único global (GUID). Para las canalizaciones, la credencial suele ser una contraseña segura denominada clave. Como alternativa, puede usar un certificado como credencial.
Identidades administradas
En contraste con otros tipos de entidad de servicio, una identidad administrada no requiere que conozca ni mantenga sus credenciales. 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 con canalizaciones, normalmente no se pueden usar identidades administradas. Esto se debe a que las identidades administradas requieren que sea el propietario y administre los recursos de Azure que ejecutan las implementaciones. Cuando se trabaja con Azure Pipelines, normalmente se basa en la infraestructura compartida proporcionada por Microsoft.
Nota:
Hay algunas situaciones en las que las canalizaciones pueden usar identidades administradas. En Azure Pipelines, puede crear un agente autohospedado para ejecutar los scripts y el código de la canalización mediante su propia máquina virtual basada en Azure. Dado que es el propietario de la máquina virtual, puede asignarle una identidad administrada y usarla desde la canalización.
Sin embargo, la mayoría de las veces, las canalizaciones se ejecutan mediante un agente hospedado, que es un servidor que Microsoft administra. Actualmente los agentes hospedados no son compatibles con las identidades administradas.
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. Es más fácil trabajar con ellas 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 una canalizació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.
Las canalizaciones están diseñadas para ejecutar las implementaciones incluso cuando nadie está ejecutándolas activamente. De hecho, la mayoría de las ventajas de las canalizaciones proceden del hecho de que están completamente automatizadas y no requieren interacción humana. Si almacena el nombre de usuario y la contraseña en una canalización 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 canalización integradas que interactúan con Azure no permiten proporcionar las credenciales de una cuenta de usuario. Requieren que use una entidad de servicio.
¿Cómo funcionan las entidades de servicio?
Es posible que vea en uso algunos términos diferentes al trabajar con entidades de servicio o con herramientas como Azure Portal o Microsoft Graph API. Aunque no es esencial comprender estos términos solo para usar entidades de servicio en una canalización, resulta útil conocerlos un poco.
Las entidades de servicio son una característica de Microsoft Entra ID. Microsoft Entra ID 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 una canalización de implementación como una aplicación.
En Microsoft Entra ID, las aplicaciones pueden hacer muchas cosas que están fuera del ámbito de las implementaciones de autenticación y canalizació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.
Las entidades de servicio y las aplicaciones están estrechamente vinculadas. Cada vez que se agrega un registro de aplicación a un inquilino de Microsoft Entra, se crea un objeto de entidad de servicio en ese inquilino de Microsoft Entra. Al consultar una entidad de servicio en Azure Portal, verá muchas otras funcionalidades y configuraciones que podrían no parecer pertinentes. Gran parte de esto se debe a que las entidades de servicio están vinculadas a las aplicaciones.
Al crear una entidad de servicio, la mayoría de las herramientas que usa también crean un registro de aplicación al mismo tiempo. Por lo tanto, es posible que no note que hay dos objetos diferentes.
Uno de los tipos de entidad de servicio no está asociado a un registro de aplicación: una identidad administrada. Como se mencionó anteriormente, Azure administra la configuración y las credenciales de una identidad administrada.
Nota:
A veces, una entidad de servicio se denomina aplicación empresarial. Algunas herramientas usan un nombre y otras usan el otro. También puede ver entidades de servicio llamadas aplicaciones administradas en el directorio local, pero no son lo mismo que las identidades administradas.
En resumen, al crear una entidad de servicio, primero se crea un registro de aplicación y, a continuación, se crea una entidad de servicio para que ese registro de aplicación la use. La mayoría de las herramientas con las que trabaja lo harán automáticamente, por lo que ni siquiera se dará cuenta de ello. Es posible que no use todas las características de Microsoft Entra cuando trabaje con canalizaciones de implementación. Aún así, dado que las entidades de servicio están relacionadas con las aplicaciones, se aplica la estructura de objetos de Microsoft Entra.