Su equipo de plataforma quiere eliminar las credenciales de larga duración para CI/CD y el acceso dentro del clúster a los recursos de Azure. Las GitHub Actions deben implementar plantillas de Bicep en Azure sin un secreto de cliente, y las cargas de trabajo de AKS deben acceder a Key Vault y Storage sin almacenar secretos de service principal. ¿Qué debe configurar? Cada respuesta correcta presenta parte de la solución.

La primera opción correcta describe cómo eliminar credenciales de larga duración para CI/CD utilizando GitHub Actions y Azure. Al configurar una credencial federada en Entra ID que confía en el emisor de OIDC de GitHub, se permite que GitHub Actions se autentique directamente con Azure sin necesidad de secretos de cliente, mejorando la seguridad. Se otorga Azure RBAC a la aplicación registrada para controlar los permisos. La segunda opción correcta aborda el acceso dentro del clúster de AKS a recursos de Azure sin almacenar secretos. Azure AD Workload Identity permite que las cargas de trabajo de AKS se autentiquen con Entra ID utilizando identidades de carga de trabajo, eliminando la necesidad de secretos de service principal. Se crea una cuenta de servicio de Kubernetes y se asocia con una aplicación de Entra ID mediante una credencial de identidad federada, permitiendo que los pods usen el SDK de Azure Identity para acceder a recursos como Key Vault y Storage. Las opciones incorrectas implican el uso de secretos de larga duración (PAT de GitHub, service principals con certificados) o tecnologías obsoletas (AAD Pod Identity heredado), lo que contradice el objetivo de eliminar credenciales de larga duración.