Autenticación sin PAT desde tareas de canalización a las API de Azure DevOps

Las tareas de una canalización usan un token de acceso de trabajo, disponible a través de la variable integrada System.AccessToken o PAT para acceder a los recursos de Azure DevOps. Por ejemplo, una tarea de "restauración" utiliza este token para autenticarse en el repositorio. Del mismo modo, un script de PowerShell puede usar este token para acceder a las API REST de Azure DevOps. Sin embargo, los permisos de este token se basan en la identidad de servicio de compilación de proyectos, lo que significa que todos los tokens de acceso de trabajo de un proyecto tienen permisos idénticos. Esto concede acceso excesivo en todas las canalizaciones del proyecto.

El uso de PAT para acceder a los recursos de Azure DevOps es común, especialmente cuando una tarea necesita acceder a esos recursos a través de los límites de la organización. Por ejemplo, una tarea de autenticación de NuGet usa un token PAT para autenticarse en un feed de otra organización. Los PAT son un antipatrón para la seguridad, ya que tienden a crearse con permisos amplios y se mantienen durante mucho tiempo, lo que aumenta el riesgo de filtración.

Para mejorar la seguridad en estos escenarios, se introduce un nuevo tipo de conexión de servicio denominado "Conexión de servicio de Azure DevOps". Usa un principal de servicio de Azure que se puede agregar como usuario en Azure DevOps con permisos específicos. Esto le permite autenticarse en recursos de una tarea de canalización mediante esta conexión de servicio y restringir el acceso a canalizaciones específicas. En primer lugar, presentaremos el nuevo tipo de conexión y algunas tareas que funcionan con él. Ampliaremos gradualmente la lista de tareas que pueden usar el tipo de conexión a lo largo del tiempo.