Microsoft ha pasado la compatibilidad con identidades administradas para los grupos de hosts de Azure Virtual Desktop a disponibilidad general, según la página de novedades de Azure Virtual Desktop. No es una GA de mero trámite: viene acompañada de una señal clara sobre hacia dónde se dirige la administración de los grupos de hosts, y esconde una tarea pendiente para todos los operadores de AVD.

Para los responsables de TI, la conclusión es doble: la automatización de AVD ya puede funcionar sin claves, y el periodo de gracia para adoptar ese modelo es limitado.

1. Qué está ya disponible de forma general

La compatibilidad con identidades administradas para los grupos de hosts de AVD está en GA en los escenarios que importan para las operaciones del día a día:

  • Configuración de hosts de sesión: aprovisionamiento y configuración de hosts de sesión sin credenciales incrustadas.
  • Escalado automático: planes de escalado que actúan sobre los grupos de hosts con una identidad administrada.
  • Start VM on Connect: encendido de los hosts de sesión a medida que se conectan los usuarios, sin secretos almacenados.
  • Azure Virtual Desktop para Azure local: la presencia híbrida queda cubierta por el mismo modelo.

Por qué importa: Estos son precisamente los flujos que históricamente empujaban a los operadores hacia entidades de servicio con secretos de cliente guardados en la automatización. Cada uno de esos secretos era una tarea de rotación y un riesgo de filtración.

2. Por qué la identidad administrada es la opción predeterminada correcta

Las identidades administradas son credenciales nativas de Azure: no hay material secreto que almacenar, rotar o confirmar por accidente en un repositorio. En AVD, esto significa que la automatización que aprovisiona, escala y enciende tus hosts de sesión se autentica sin claves, con un acceso regido por la asignación de roles y no por la posesión de una cadena de texto.

Por qué importa: La higiene de credenciales es higiene de cumplimiento. Eliminar los secretos estáticos de la automatización de los grupos de hosts refuerza tu historial de auditoría y elimina toda una categoría de incidentes del tipo «un secreto caducado rompió el escalado automático», esos que aparecen a las 8 de la mañana de un lunes cuando los usuarios no consiguen una sesión.

3. El requisito que viene: planifica la migración ahora

Escondida en el mismo anuncio está la parte que merece una entrada en el calendario: en una futura actualización del servicio, los grupos de hosts configurados con una configuración de hosts de sesión necesitarán una identidad administrada para poder agregar hosts de sesión al grupo de hosts.

Dicho de otro modo, lo que hoy es opcional se impondrá mañana, y esa imposición llegará justo en el momento en que escales horizontalmente o sustituyas hosts de sesión, que es el peor momento para descubrirlo.

Qué hacer ahora:

  • Haz un inventario de los grupos de hosts que usan una configuración de hosts de sesión.
  • Habilita una identidad administrada en esos grupos de hosts y valida que agregar un host de sesión funciona con el nuevo modelo.
  • Actualiza los runbooks de aprovisionamiento y la IaC para que los nuevos grupos de hosts nazcan con identidad administrada en lugar de migrarse a ella más adelante.

Conclusión

La llegada a GA de la compatibilidad con identidades administradas elimina la última excusa para mantener una automatización de AVD basada en credenciales, y el requisito futuro anunciado convierte el «deberías hacerlo» en «tendrás que hacerlo». Los operadores que se muevan ahora tendrán una transición tranquila y sin sobresaltos; el resto se encontrará con un escalado horizontal fallido a una hora inoportuna.

¿Necesitas ayuda para modernizar las operaciones de Azure Virtual Desktop antes de que llegue el requisito? Habla con el equipo de asesoría de Big Hat Group.