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.

Para comprender mejor la diferencia entre los tipos de identidades administradas, consulte ¿Qué son las identidades administradas de recursos de Azure?

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:

  1. 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.

  2. 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.

  • Service Fabric no admite identidades administradas en AzureServiceTokenProvider que está en desuso. En su lugar, use identidades administradas en Service Fabric mediante el SDK de identidad de Azure.

Pasos siguientes