Azure Pipelines: actualización de Sprint 227

Características

• Federación de identidades de carga de trabajo en Azure Pipelines (versión preliminar pública)

• Los agentes de canalización se pueden registrar mediante el identificador de Entra de Microsoft en lugar de un PAT

• API REST para entornos

• Impedir ejecuciones de canalización no deseadas

• Compilación de repositorios de GitHub de forma segura de forma predeterminada

• Invalidación deshabilitada del estado de la directiva de cobertura de código en Error cuando se produce un error en la compilación

Federación de identidades de carga de trabajo en Azure Pipelines (versión preliminar pública)

¿Desea dejar de almacenar secretos y certificados en conexiones de servicio de Azure? ¿Quiere dejar de preocuparse por rotar estos secretos cada vez que expiren? Ahora anunciamos una versión preliminar pública de la federación de identidades de carga de trabajo para las conexiones de servicio de Azure.La federación de identidades de carga de trabajo usa una tecnología estándar del sector, Open ID Conectar (OIDC) para simplificar la autenticación entre Azure Pipelines y Azure. En lugar de secretos, se utiliza un sujeto de federación para facilitar esta autenticación.

Como parte de esta característica, la conexión del servicio Azure (ARM) se ha actualizado con otro esquema para admitir la federación de identidades de carga de trabajo. Esto permite que las tareas de canalización que usan la conexión de servicio de Azure se autentiquen mediante un sujeto de federación (sc://<org>/<project>/<service connection name>). Las principales ventajas de usar este esquema en los esquemas de autenticación existentes son las siguientes:

• Administración simplificada: ya no se van a generar, copiar y almacenar secretos de entidades de servicio de Azure AD en Azure DevOps. Los secretos que se usan en otros esquemas de autenticación de las conexiones de servicio de Azure (por ejemplo, la entidad de servicio) expiran después de un período determinado (dos años actualmente). Cuando expiran, se produce un error en las canalizaciones. Tiene que volver a generar un nuevo secreto y actualizar la conexión de servicio. El cambio a la federación de identidades de carga de trabajo elimina la necesidad de administrar estos secretos y mejora la experiencia general de creación y administración de conexiones de servicio.
• Seguridad mejorada: con la federación de identidades de carga de trabajo, no hay ningún secreto persistente implicado en la comunicación entre Azure Pipelines y Azure. Como resultado, las tareas que se ejecutan en trabajos de canalización no pueden filtrar ni filtrar secretos que tengan acceso a los entornos de producción. Esto a menudo ha sido una preocupación para nuestros clientes.

Puede aprovechar estas características de dos maneras:

• Use el nuevo esquema de federación de identidad de carga de trabajo cada vez que cree una nueva conexión de servicio de Azure. Al avanzar, este será el mecanismo recomendado.
• Convierta las conexiones de servicio de Azure existentes (que se basan en secretos) al nuevo esquema. Puede realizar esta conversión una conexión cada vez. Lo mejor de todo es que no tiene que modificar ninguna de las canalizaciones que usan esas conexiones de servicio. Aplicarán automáticamente el nuevo esquema una vez completada la conversión.

Para crear una nueva conexión de servicio de Azure mediante la federación de identidades de carga de trabajo, simplemente seleccione Federación de identidades de carga de trabajo (automática) o (manual) en la experiencia de creación de la conexión de servicio de Azure:

Para convertir una conexión de servicio de Azure creada anteriormente, seleccione la acción "Convertir" después de seleccionar la conexión:

Todas las tareas de Azure que se incluyen con Azure Pipelines ahora admiten este nuevo esquema. Sin embargo, si usa una tarea de Marketplace o una tarea personalizada de crecimiento doméstico para realizar la implementación en Azure, es posible que aún no admita la federación de identidades de carga de trabajo. En estos casos, le pedimos que actualice la tarea para admitir la federación de identidades de carga de trabajo para mejorar la seguridad. Puede encontrar una lista completa de las tareas admitidas aquí.

En esta versión preliminar, solo se admite la federación de identidades de carga de trabajo para las conexiones de servicio de Azure. Este esquema no funciona con ningún otro tipo de conexiones de servicio. Consulte nuestros documentos para obtener más información.

Esta entrada de blog contiene más detalles.

Los agentes de canalización se pueden registrar mediante el identificador de Entra de Microsoft en lugar de un PAT

El agente de canalización ahora admite más argumentos para usar una entidad de servicio o un usuario para registrar un agente. Debe conceder a la identidad usada acceso al grupo de agentes en su configuración de seguridad. Esto elimina la necesidad de usar un token de acceso personal (PAT) para la configuración de un solo uso de los agentes.

Registro de un agente mediante una entidad de servicio

Para usar una entidad de servicio para registrar un agente de Pipelines con Azure DevOps Services, proporcione los argumentos siguientes:

--auth 'SP' --clientid 12345678-1234-1234-abcd-1234567890ab --clientsecret --tenantid 12345678-1234-1234-abcd-1234567890ab

Uso de una entidad de servicio en la extensión de máquina virtual del agente

Las máquinas virtuales de Azure se pueden incluir en grupos de implementación mediante una extensión de máquina virtual. La extensión de máquina virtual se ha actualizado para usar una entidad de servicio en lugar de un PAT para registrar el agente:

"settings": {
  "userServicePrincipal": true     
}
"protectedSettings": {
  "clientId": "[parameters('clientId')]"      
  "clientSecret": "[parameters('clientSecret')]"      
  "tenantId": "[parameters('tenantId')]"      
}

Registro de un agente de forma interactiva mediante el flujo de código de dispositivo

Puede usar un explorador web para completar fácilmente la configuración. Al ejecutar el script de configuración del agente, escriba "AAD" para el tipo de autenticación. El script le guiará por los pasos siguientes, incluido dónde ir a la web y qué código escribir. Después de escribir el código en la web, vuelva a la consola para terminar de configurar el agente.

API REST para entornos

Un entorno es una colección de recursos que puede tener como destino las implementaciones desde una canalización. Los entornos proporcionan historial de implementación, rastreabilidad para elementos de trabajo y confirmaciones y mecanismos de control de acceso.

Sabemos que desea crear entornos mediante programación, por lo que hemos publicado documentación para su API REST.

Impedir ejecuciones de canalización no deseadas

En la actualidad, si la canalización de YAML no especifica una trigger sección, se ejecuta para los cambios insertados en su repositorio. Esto puede crear confusión sobre por qué se ejecutó una canalización y provocará muchas ejecuciones no deseadas.

Hemos agregado una configuración de canalizaciones de nivel de proyecto y organización denominada Deshabilitar desencadenador de CI de YAML implícito que le permite cambiar este comportamiento. Puede optar por no desencadenar canalizaciones si falta su sección de desencadenador.

Compilación de repositorios de GitHub de forma segura de forma predeterminada

En el último sprint, se introdujo un control centralizado para compilar solicitudes de incorporación de cambios a partir de repositorios de GitHub bifurcados.

Con este sprint, habilitamos la Securely build pull requests from forked repositories opción en el nivel de organización para las nuevas organizaciones. Las organizaciones existentes no se ven afectadas.

Invalidación deshabilitada del estado de la directiva de cobertura de código en Error cuando se produce un error en la compilación

Anteriormente, el estado de la directiva de cobertura de código se invalidaba en "Failed" si se produjo un error en la compilación en la solicitud de incorporación de cambios. Esto fue un bloqueador para algunos de ustedes que tenían la compilación como una comprobación opcional y la directiva de cobertura de código como una comprobación necesaria para las solicitudes de incorporación de cambios, lo que da lugar a que se bloqueen las solicitudes de incorporación de cambios.

Con este sprint, la directiva de cobertura de código no se invalidará en "Failed" si se produce un error en la compilación. Esta característica se habilitará para todos los clientes.

Pasos siguientes

Nota:

Estas características se implementarán en las próximas dos a tres semanas.

Vaya a Azure DevOps y eche un vistazo.

Vaya a Azure DevOps.

Cómo enviar sus comentarios

Nos encantaría escuchar lo que piensas sobre estas características. Use el menú de ayuda para notificar un problema o proporcionar una sugerencia.

También puede obtener consejos y sus preguntas respondidas por la comunidad en Stack Overflow.