La seguridad avanzada y la identidad administrada de GitHub y la compatibilidad con la entidad de servicio para Azure DevOps ahora están disponibles con carácter general.
Nos complace anunciar que la compatibilidad con La identidad administrada y la identidad avanzada de GitHub para Azure DevOps ya están disponibles con carácter general.
En GitHub Advanced Security, también hemos mejorado el análisis de código para incluir todas las entradas proporcionadas por el usuario en la tarea CodeQL Initialize . Además, ampliamos la compatibilidad con CodeQL para incluir Swift.
En Boards, publicamos reglas de Automatización de equipos en versión preliminar privada. Ahora, puede configurar cada nivel de trabajo pendiente para automatizar la apertura y cierre o resolución de elementos de trabajo en función de los estados de sus elementos secundarios. Consulte las notas de la versión si está interesado en inscribirse en la versión preliminar privada.
Vaya a la lista de características siguiente para obtener información sobre estas características.
General
- Compatibilidad con identidades administradas y entidades de servicio para Azure DevOps ahora en disponibilidad general (GA)
- Nuevos ámbitos de Azure DevOps disponibles para aplicaciones de flujo delegadas de OAuth de Microsoft Identity
GitHub Advanced Security para Azure DevOps
- Cambios en la tarea y las variables de entrada de usuario de Análisis de código (CodeQL)
- La tarea Publicar ya no es necesaria para configurar el examen de código
- El análisis de código codeQL ahora admite Swift
Azure Boards
Azure Pipelines
- Los registros de canalización ahora contienen uso de recursos
- El agente de Azure Pipelines ahora admite Alpine Linux
General
Compatibilidad con identidades administradas y entidades de servicio para Azure DevOps ahora en disponibilidad general (GA)
La compatibilidad con identidades administradas y entidades de servicio de Microsoft Entra ID en Azure DevOps ahora ha alcanzado la disponibilidad general (GA).
En la actualidad, muchos escenarios de integración de aplicaciones se basan en tokens de acceso personal (PAT) para integrarse con Azure DevOps. Aunque es fácil de usar, los PAT se pueden filtrar fácilmente, lo que podría permitir que los actores malintencionados se autentiquen como usuarios eficaces. Para evitar el acceso no deseado, los PAT suelen requerir un mantenimiento lento a través de rotaciones de credenciales normales.
Ahora puede habilitar las aplicaciones para que usen identidades administradas y entidades de servicio para integrarse con Azure DevOps a través de las API REST y las bibliotecas cliente. Esta característica altamente solicitada ofrece a los clientes de Azure DevOps una alternativa más segura a los PAT. Las identidades administradas ofrecen la posibilidad de que las aplicaciones que se ejecutan en recursos de Azure obtengan tokens de Azure AD sin necesidad de administrar credenciales en absoluto.
Las identidades administradas y las entidades de servicio se pueden configurar en Azure DevOps y conceder permisos a recursos específicos (proyectos, repositorios, canalizaciones), al igual que los usuarios normales. Esto permite a las aplicaciones que usan identidades administradas o entidades de servicio conectarse a Azure DevOps y realizar acciones en nombre de sí mismas, en lugar de en nombre de un usuario, como hace PAT. Los equipos ahora pueden administrar mejor sus servicios colectivamente, en lugar de confiar en cualquier individuo para proporcionar un token para la autenticación. Obtenga más información sobre la versión de disponibilidad general en nuestro anuncio de entrada de blog público y nuestra documentación de características.
Nuevos ámbitos de Azure DevOps disponibles para aplicaciones de flujo delegadas de OAuth de Microsoft Identity
Hemos agregado nuevos ámbitos de Azure DevOps para aplicaciones de OAuth delegadas en la plataforma de identidad de Microsoft, también conocidas coloquialmente como aplicaciones de OAuth id. de Microsoft Entra. Estos nuevos ámbitos permitirán a los desarrolladores de aplicaciones anunciar específicamente qué permisos esperan solicitar al usuario para realizar tareas de aplicación. Esta característica muy solicitada permite a los desarrolladores de aplicaciones solicitar a sus usuarios únicamente los permisos que necesitan para su aplicación.
Anteriormente, user_impersonation era el único ámbito disponible para que los desarrolladores de aplicaciones elijan. Este ámbito proporciona a la aplicación acceso completo a todas las API de Azure DevOps, lo que significa que podrá hacer todo lo que el usuario pueda hacer en todas las organizaciones a las que pertenece el usuario. Ahora con ámbitos más granulares disponibles, puede descansar fácilmente que las aplicaciones solo pueden solicitar y acceder únicamente a las API a las que los ámbitos solicitados les han concedido permiso para acceder.
Obtenga más información sobre estos nuevos ámbitos en nuestra publicación de blog pública y documentación sobre características.
GitHub Advanced Security para Azure DevOps
Cambios en la tarea y las variables de entrada de usuario de Análisis de código (CodeQL)
Todas las entradas proporcionadas por el usuario ahora se especifican en la tarea CodeQL Initialize, que es responsable de configurar el entorno de análisis codeQL usado para el análisis de código con CodeQL "AdvancedSecurity-Codeql-Init@1". Consulte la documentación sobre la configuración de La seguridad avanzada de GitHub para las características de Azure DevOps para más información sobre la configuración de Seguridad avanzada de GitHub para Azure DevOps.
Además, las entradas de usuario tienen prioridad sobre los valores establecidos por variables. Por ejemplo, si establece la variable de lenguaje como advancedsecurity.codeql.language: Java y posteriormente, durante la fase de inicialización de CodeQL, especifique el idioma como entrada con Language: cpp, la entrada cpp invalidará la variable Java para el idioma. Asegúrese de que las entradas están configuradas con precisión.
La tarea Publicar ya no es necesaria para configurar el examen de código
Anteriormente, al configurar el análisis de código, era necesario incluir la tarea de publicación (AdvancedSecurity-Publish@1) en la canalización YAML o en la canalización clásica. Con esta actualización, hemos eliminado la necesidad de la tarea de publicación y los resultados ahora se publican directamente en el servicio de seguridad avanzada dentro de la tarea de análisis (AdvancedSecurity-Codeql-Analyze@1).
A continuación se muestra la tarea require para el examen de código.
Para obtener más información, consulte la documentación de configuración del examen de código.
El análisis de código codeQL ahora admite Swift
Estamos ampliando nuestra compatibilidad con el análisis de código codeQL para incluir Swift. Esto significa que los desarrolladores que trabajan en aplicaciones y bibliotecas Swift para plataformas apple ahora pueden aprovechar nuestro análisis de seguridad de código de primera clase. Nuestras funcionalidades actuales incluyen la detección de problemas como la inserción de rutas de acceso, capturas de vistas web de riesgo, varios usos criptográficos y otras formas de control o procesamiento no seguros de datos de usuario sin filtrar.
Swift forma parte de nuestra lista de lenguajes de programación compatibles, que incluye C/C++, Java/Kotlin, JavaScript/TypeScript, Python, Ruby, C#y Go. Por completo, estos lenguajes nos permiten realizar casi 400 comprobaciones completas en el código, todo ello manteniendo una tasa baja de falsos positivos y garantizando una alta precisión.
Consulte la documentación sobre la configuración de Las características de Seguridad avanzada de GitHub para Azure DevOps para más información sobre la configuración de Seguridad avanzada de GitHub para Azure DevOps para los repositorios.
Azure Boards
Reglas de Automatización de equipos (versión preliminar privada)
Importante
A partir del 9/11/2023, no estamos llevando ninguna nueva organización a la versión preliminar privada. Hemos tenido excelentes comentarios con solo un par de errores menores para resolver. Estamos trabajando en esos errores y publicaremos la característica a todos los usuarios en los próximos sprints.
Ahora puede configurar cada nivel de trabajo pendiente para automatizar la apertura y cierre o resolución de elementos de trabajo en función de los estados de sus elementos secundarios. Hay dos escenarios principales que estamos intentando resolver.
Cuando se activa un solo elemento secundario, active el elemento primario.
Cuando se cierran todos los elementos secundarios, cierre el elemento primario (o resuélvalo).
Para habilitar esta configuración, haga clic en la configuración de nivel de trabajo pendiente del equipo. A continuación, vaya a la pestaña Reglas de automatización > para ver las dos reglas diferentes que puede aplicar al trabajo pendiente. Cada nivel de trabajo pendiente (requisitos, características, epopeyas) se puede configurar para la forma en que el equipo quiere trabajar.
Por ejemplo, cuando cualquier tarea secundaria está establecida en Activo, active el artículo de usuario primario. A continuación, cuando se completen todas las tareas, establezca user story (Historia del usuario) en Closed (Cerrado).
Si está interesado en inscribirse en la versión preliminar privada, envíenos un correo electrónico con el nombre de su organización (dev.azure.com/{nombre de la organización}). Comprenda que limitaremos el número de organizaciones a la versión preliminar. Nuestra esperanza es obtener algunas organizaciones para proporcionar comentarios y, a continuación, liberar a todos los usuarios dentro de los sprints de 2 a 3.
Las características se priorizaron en función de este vale de sugerencia de la Comunidad de desarrolladores.
Nota:
Esta característica solo estará disponible con la versión preliminar de New Boards Hubs.
Azure Pipelines
Los registros de canalización ahora contienen uso de recursos
Los registros de canalización de Azure ahora pueden capturar métricas de uso de recursos, como memoria, uso de CPU y espacio en disco disponible. Los registros también incluyen recursos usados por el agente de canalización y los procesos secundarios, incluidas las tareas que se ejecutan en un trabajo.
Si sospecha que el trabajo de canalización puede encontrarse con restricciones de recursos, habilite los registros detallados para que se inserte información de uso de recursos en los registros de canalización. Esto funciona en cualquier agente, independientemente del modelo de hospedaje.
El agente de Azure Pipelines ahora admite Alpine Linux
El agente de canalización v3.227 ahora admite las versiones 3.13 y posteriores de Alpine Linux . Alpine Linux es una imagen popular para contenedores (base). Puede encontrar el agente en la página de versiones . Las versiones de Alpine Linux del agente tienen un prefijo vsts-agent-linux-musl , por ejemplo, vsts-agent-linux-musl-x64-3.227.1.tar.gz.
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.
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.
Gracias,
Rajesh Ramamurthy