Uso de identidades administradas para Azure con Service Fabric
Artículo
Un desafío común al compilar aplicaciones en la nube es cómo administrar de forma segura las credenciales en el código para autenticarse en varios servicios sin guardarlos localmente en una estación de trabajo de desarrollador ni en el control de código fuente. Las identidades administradas para Azure resuelven este problema para todos los recursos de Microsoft Entra ID proporcionándoles identidades administradas automáticamente dentro de Microsoft Entra ID. Puede usar la identidad de un servicio para autenticarse en cualquier servicio que admita la autenticación de Microsoft Entra, incluido Key Vault, sin necesidad de almacenar ninguna credencial en el código.
Las identidades administradas para recursos de Azure se incluyen gratuitamente en Microsoft Entra ID con las suscripciones de Azure. No hay ningún costo adicional.
Nota
Las identidades administradas para recursos de Azure es el nombre con el que ahora se conoce al servicio Managed Service Identity (MSI).
Conceptos
Las identidades administradas para Azure se basan en varios conceptos clave:
Id. de cliente: identificador único que genera Microsoft Entra ID y que está asociado a una aplicación y entidad de servicio durante su aprovisionamiento inicial (consulte también Id. de aplicación [cliente]).
Id. de entidad de seguridad: identificador de objeto del objeto de entidad de servicio de la identidad administrada que se usa para conceder acceso basado en roles a los recursos de Azure.
Entidad de servicio: objeto de Microsoft Entra que representa la proyección de una aplicación de Microsoft Entra en un inquilino determinado (consulte también Entidad de servicio).
Hay dos tipos de identidades administradas:
Las identidades administradas asignadas por el sistema se habilitan directamente en las instancias de servicio de Azure. El ciclo de vida de una identidad administrada asignada por el sistema es único para la instancia de servicio de Azure en que está habilitada.
Las identidades administrada asignadas por el usuario se crean como recursos de Azure independientes. La identidad se puede asignar a una o varias instancias de servicio de Azure y se administra de forma independiente de los ciclos de vida de esas instancias.
Escenarios admitidos para las aplicaciones de Service Fabric
Las identidades administradas de Service Fabric solo se admiten en clústeres de Service Fabric implementados en Azure y solo para aplicaciones implementadas como recursos de Azure. No se puede asignar una identidad a una aplicación no implementada como un recurso de Azure. En términos conceptuales, la compatibilidad con identidades administradas en el clúster de Azure Service Fabric consta de dos fases:
Asigne una o más identidades administradas al recurso de la aplicación; una aplicación puede tener asignada una única identidad asignada por el sistema y hasta 32 identidades asignadas por el usuario, respectivamente.
Dentro de la definición de la aplicación, asigne una de las identidades asignadas a la aplicación a cualquier servicio individual que contenga la aplicación.
La identidad asignada por el sistema de una aplicación es única de esa aplicación, mientras que una identidad asignada por el usuario es un recurso independiente, que se puede asignar a varias aplicaciones. Dentro de una aplicación, se puede asignar una identidad (ya sea asignada por el sistema o asignada por el usuario) a varios servicios de la aplicación, pero cada servicio individual solo puede tener asignada una identidad. Por último, se debe asignar una identidad explícitamente a un servicio para que tenga acceso a esta característica. De hecho, la asignación de las identidades de una aplicación a los servicios que la componen permite el aislamiento en la aplicación. Un servicio solo puede usar la identidad que se le ha asignado.
Se admiten los escenarios siguientes para esta característica:
Implementación de una nueva aplicación con uno o más servicios, y con una o varias identidades asignadas.
Asignación de una o varias identidades administradas a una aplicación existente (implementada en Azure) para acceder a los recursos de Azure.
Los escenarios siguientes no se admiten o no son recomendables. Estas acciones no se pueden bloquear, pero pueden producir interrupciones en las aplicaciones:
Eliminación o cambio de las identidades asignadas a una aplicación. Si tiene que realizar cambios, envíe implementaciones independientes para agregar primero una nueva asignación de identidad y, después, quitar una ya asignada. La eliminación de una identidad de una aplicación existente puede tener efectos no deseados, como dejar la aplicación en un estado no actualizable. Es seguro eliminar la aplicación por completo si es necesario eliminar una identidad. Al eliminar la aplicación, se elimina cualquier identidad asignada por el sistema asociada a la aplicación y se quitan todas las asociaciones con las identidades asignadas por el usuario asignadas a la aplicación.
Muestre las características de Microsoft Entra ID para modernizar las soluciones de identidad, implementar soluciones híbridas e implementar la gobernanza de identidades.
Veremos cómo configurar y usar una aplicación con identidad administrada en un clúster administrado de Azure Service Fabric implementado con una plantilla de Azure Resource Manager (ARM).
Cómo usar identidades administradas en el código de aplicación de Azure Service Fabric para acceder a servicios de Azure en un clúster administrado de Service Fabric.