Compartir a través de

Conceptos de federación de identidad de carga de trabajo

Obtenga información sobre cómo la federación de identidades de carga de trabajo permite el acceso seguro a los recursos protegidos de Microsoft Entra sin administrar secretos. En este artículo se proporciona información general sobre sus ventajas y escenarios admitidos.

Puede usar la federación de identidades de carga de trabajo en escenarios como Acciones de GitHub, cargas de trabajo que se ejecutan en Kubernetes o cargas de trabajo que se ejecutan en plataformas de proceso fuera de Azure.

¿Por qué usar la federación de identidades de carga de trabajo?

Vea este vídeo para saber por qué usaría la federación de identidades de carga de trabajo.

Normalmente, una carga de trabajo de software (como una aplicación, un servicio, un script o una aplicación basada en contenedores) necesita una identidad para autenticarse y acceder a los recursos o comunicarse con otros servicios. Cuando estas cargas de trabajo se ejecutan en Azure, puede usar identidades administradas y la plataforma Azure administra las credenciales. Para una carga de trabajo de software que se ejecute fuera de Azure, o aquellas que se ejecuten en Azure y utilicen registros de aplicaciones para sus identidades, es necesario usar credenciales de aplicación (ya sea un secreto o un certificado) para acceder a los recursos protegidos por Microsoft Entra (como Azure, Microsoft Graph, Microsoft 365 o recursos de terceros). Estas credenciales suponen un riesgo para la seguridad y se deben almacenar de forma segura y cambiar periódicamente. También corre el riesgo de tiempo de inactividad del servicio si las credenciales expiran.

Usas la federación de identidades de carga de trabajo para configurar una identidad administrada asignada por el usuario o un registro de aplicaciones en Microsoft Entra ID con el fin de confiar en tokens de un proveedor de identidad externo (IdP), como GitHub o Google. El registro de aplicaciones o las identidades administradas asignadas por el usuario en Microsoft Entra ID se convierten en una identidad para cargas de trabajo de software que se ejecutan, por ejemplo, en flujos de trabajo locales de Kubernetes o Acciones de GitHub. Una vez creada esa relación de confianza, la carga de trabajo de software externa intercambia tokens de confianza desde el IdP externo por tokens de acceso de la plataforma de identidad de Microsoft. La carga de trabajo de software utiliza ese token de acceso para acceder a los recursos protegidos de Microsoft Entra a los que se ha concedido acceso a la carga de trabajo. Se elimina la carga de mantenimiento de administrar manualmente las credenciales y elimina el riesgo de filtración de secretos o de que los certificados expiren.

Escenarios admitidos

Se admiten los siguientes escenarios para acceder a recursos protegidos de Microsoft Entra mediante la federación de identidades de carga de trabajo:

  • Cargas de trabajo que se ejecutan en cualquier clúster de Kubernetes (Azure Kubernetes Service (AKS), Amazon Web Services EKS, Google Kubernetes Engine (GKE) o local). Establezca una relación de confianza entre la identidad administrada asignada por el usuario o la aplicación en Microsoft Entra ID y una carga de trabajo de Kubernetes (según se describe en el resumen de la identidad de carga de trabajo).
  • Acciones de GitHub. En primer lugar, configure una relación de confianza entre la identidad administrada asignada por el usuario o la aplicación en microsoft Entra ID y un repositorio de GitHub en el Centro de administración de Microsoft Entra o mediante Microsoft Graph. A continuación, configure un flujo de trabajo de Acciones de GitHub para obtener un token de acceso del proveedor de identidades de Microsoft y acceder a los recursos de Azure.
  • Cargas de trabajo que se ejecutan en plataformas de computación de Azure mediante identidades de aplicación. En primer lugar, asigne una identidad administrada asignada por el usuario a la máquina virtual de Azure o a App Service. A continuación, configure una relación de confianza entre la aplicación y la identidad asignada por el usuario.
  • Google Cloud. En primer lugar, configure una relación de confianza entre la identidad administrada asignada por el usuario o la aplicación en Microsoft Entra ID y una identidad en Google Cloud. A continuación, configure la carga de trabajo de software que se ejecuta en Google Cloud para obtener un token de acceso del proveedor de identidades de Microsoft y acceder a recursos protegidos de Microsoft Entra. Consulte Acceso a los recursos protegidos de Microsoft Entra desde una aplicación en Google Cloud.
  • Cargas de trabajo que se ejecutan en Amazon Web Services (AWS). En primer lugar, configure una relación de confianza entre la identidad administrada asignada por el usuario o la aplicación en Microsoft Entra ID y una identidad en Amazon Cognito. A continuación, configure la carga de trabajo de software que se ejecuta en AWS para obtener un token de acceso del proveedor de identidades de Microsoft y acceder a recursos protegidos de Microsoft Entra. Consulte Federación de identidades de carga de trabajo con AWS.
  • Otras cargas de trabajo que se ejecutan en plataformas de proceso fuera de Azure. Configure una relación de confianza entre la identidad administrada asignada por el usuario o aplicación en Microsoft Entra ID y el IdP externo para la plataforma de computación. Puede usar tokens emitidos por esa plataforma para autenticarse con la plataforma de identidad de Microsoft y llamar a las API del ecosistema de Microsoft. Utilice el flujo de credenciales de cliente para obtener un token de acceso de la plataforma de identidad de Microsoft, pasando el JWT del proveedor de identidades en lugar de crear uno mismo al utilizar un certificado almacenado.
  • SPIFFE y SPIRE son un conjunto de estándares independientes de la plataforma y de código abierto para proporcionar identidades a las cargas de trabajo de software implementadas entre plataformas y proveedores en la nube. En primer lugar, configure una relación de confianza entre la identidad administrada asignada por el usuario o la aplicación en Microsoft Entra ID y un id. de SPIFFE para una carga de trabajo externa. A continuación, configure la carga de trabajo de software externa para obtener un token de acceso del proveedor de identidades de Microsoft y acceder a recursos protegidos de Microsoft Entra. Consulte Federación de identidades de carga de trabajo con SPIFFE y SPIRE.
  • Crear una conexión de servicio en Azure Pipelines. Cree una conexión de servicio de Azure Resource Manager mediante la federación de identidades de carga de trabajo.

Nota:

Es posible que los tokens emitidos por Microsoft Entra ID no se usen para los flujos de identidad federada. El flujo de credenciales de identidad federada no admite tokens emitidos por Microsoft Entra ID.

Cómo funciona

Cree una relación de confianza entre el IdP externo y una identidad administrada asignada por el usuario o una aplicación en microsoft Entra ID. La credencial de identidad federada se usa para indicar qué token del IdP externo debe ser de confianza para la aplicación o identidad administrada. Puede configurar una identidad federada:

Nota:

Los valores de credenciales de identidad federada issuer, subject, y audience deben coincidir entre mayúsculas y minúsculas con los valores correspondientes issuer, subject y audience contenidos en el token que envía a Microsoft Entra ID por el IdP externo para que el escenario sea autorizado. Para obtener más información sobre este cambio, visite Novedades para la autenticación.

Sin embargo, el flujo de trabajo para intercambiar un token externo por un token de acceso es el mismo para todos los escenarios. En el diagrama siguiente se muestra el flujo de trabajo general de una carga de trabajo que intercambia un token externo por un token de acceso y, luego, accede a los recursos protegidos de Microsoft Entra.

Diagrama que muestra un token externo intercambiado para un token de acceso y acceso a Azure

  1. La carga de trabajo externa (por ejemplo, un flujo de trabajo de Acciones de GitHub) solicita un token del IdP externo (por ejemplo, GitHub).
  2. El IdP externo emite un token a la carga de trabajo externa.
  3. La carga de trabajo externa (la acción de inicio de sesión en un flujo de trabajo de GitHub, por ejemplo) envía el token a la plataforma de identidad de Microsoft y solicita un token de acceso.
  4. La plataforma de identidad de Microsoft comprueba la relación de confianza en la identidad administrada asignada por el usuario o el registro de aplicaciones y valida el token externo en la dirección URL del emisor de OpenID Connect (OIDC) en el IdP externo.
  5. Cuando se cumplen las comprobaciones, la plataforma de identidad de Microsoft emite un token de acceso a la carga de trabajo externa.
  6. La carga de trabajo externa accede a los recursos protegidos de Microsoft Entra mediante el token de acceso de la plataforma de identidad de Microsoft. Un flujo de trabajo de Acciones de GitHub, por ejemplo, usa el token de acceso para publicar una aplicación web a Azure App Service.

La plataforma de identidad de Microsoft almacena solo las 100 primeras claves de firma cuando se descargan del punto de conexión OIDC del proveedor de identidades externo. Si el proveedor de identidades externo expone más de 100 claves de firma, puede sufrir errores al usar la federación de identidades de carga de trabajo.

Consulte también