Améliorations apportées à la sécurité des pipelines

Avec cette mise à jour, nous incluons des améliorations pour renforcer la sécurité dans Azure DevOps. Vous pouvez maintenant utiliser une identité managée affectée par le système lors de la création de connexions de service Docker Registry pour Azure Container Registry. En outre, nous avons amélioré la gestion des accès pour les pools d’agents afin de vous permettre de spécifier l’utilisation des ressources dans un pipeline YAML. Enfin, nous limitons le jeton d’accès GitHub pour les dépôts GitHub publics pour avoir une étendue en lecture seule.

Pour plus d’informations, consultez les notes de publication.

Azure Boards

• Copier des liens de commentaire

Azure Pipelines

• Les connexions de service Container Registry peuvent désormais utiliser des identités managées Azure
• Événements du journal d’audit liés à l’autorisation de pipeline
• Vérifiez que votre organisation utilise uniquement des pipelines YAML
• Nouvelle étendue PAT requise pour mettre à jour le Paramètres général du pipeline
• Gestion des accès affiné pour les pools d’agents
• Empêcher d’accorder à tous les pipelines l’accès aux ressources protégées
• Amélioration de la sécurité lors de la création de demandes de tirage à partir de référentiels GitHub forked
• L’étiquette macos la plus récente pointe vers l’image macos-12
• L’étiquette Ubuntu la plus récente pointe vers l’image ubuntu-22.04

Azure Boards

Copier des liens de commentaire

Vous pouvez maintenant utiliser l’action Copier le lien pour copier un lien vers un commentaire d’élément de travail spécifique. Vous pouvez ensuite coller ce lien dans un autre commentaire ou description d’élément de travail. Lorsque vous cliquez dessus, l’élément de travail est ouvert et le commentaire est mis en surbrillance.

Cette fonctionnalité a été hiérarchisée en fonction de ce ticket de suggestion de la communauté.

Remarque

Cette fonctionnalité sera disponible uniquement avec la préversion de New Boards Hubs.

Azure Pipelines

Les connexions de service Container Registry peuvent désormais utiliser des identités managées Azure

Vous pouvez utiliser une identité managée affectée par le système lors de la création de connexions de service Docker Registry pour Azure Container Registry. Cela vous permet d’accéder à Azure Container Registry à l’aide d’une identité managée associée à un agent Azure Pipelines auto-hébergé, ce qui élimine la nécessité de gérer les informations d’identification.

Remarque

L’identité managée utilisée pour accéder à Azure Container Registry a besoin de l’attribution RBAC (Role Based Access Control) Azure appropriée, par exemple, AcrPull ou AcrPush.

Événements du journal d’audit liés aux autorisations de pipeline

Lorsque vous limitez les autorisations de pipeline d’une ressource protégée, telles qu’une connexion de service, le journal des événements d’audit associé indique désormais correctement que la ressource n’a pas été autorisée pour son projet.

Vérifiez que votre organisation utilise uniquement des pipelines YAML

Azure DevOps vous permet désormais de vous assurer que votre organisation utilise uniquement des pipelines YAML, en désactivant la création de pipelines de build classiques, de pipelines de mise en production classiques, de groupes de tâches et de groupes de déploiement. Vos pipelines classiques existants continueront à s’exécuter, et vous pourrez les modifier, mais vous ne pourrez pas en créer de nouveaux.

Vous pouvez désactiver la création de pipelines classiques au niveau de l’organisation ou du projet, en activant les bascules correspondantes. Les bascules sont disponibles dans Project/Organization Paramètres -> Pipelines -> Paramètres.

L’état des bascules est désactivé par défaut, et vous aurez besoin de droits d’administrateur pour modifier l’état. Si le bouton bascule est activé au niveau de l’organisation, la désactivation est appliquée pour tous les projets. Sinon, chaque projet est libre de choisir s’il faut appliquer ou non la désactivation.

Lors de la désactivation de la création de pipelines classiques, les API REST liées à la création de pipelines classiques, de groupes de tâches et de groupes de déploiement échouent. Les API REST qui créent des pipelines YAML fonctionnent.

La désactivation de la création de pipelines classiques est opt-in pour les organisations existantes. Pour les nouvelles organisations, il est choisi pour le moment.

Nouvelle étendue PAT requise pour mettre à jour le Paramètres général du pipeline

L’appel du Paramètres général - Mettre à jour l’API REST nécessite désormais un pat avec étendue Project et Team -> Lecture et écriture.

Gestion des accès affiné pour les pools d’agents

Les pools d’agents vous permettent de spécifier et de gérer les machines sur lesquelles vos pipelines s’exécutent.

Auparavant, si vous utilisiez un pool d’agents personnalisé, la gestion des pipelines qui peuvent y accéder était grossière. Vous pouvez autoriser tous les pipelines à l’utiliser, ou vous pouvez exiger que chaque pipeline demande l’autorisation. Malheureusement, une fois que vous avez accordé une autorisation d’accès au pipeline à un pool d’agents, vous n’avez pas pu le révoquer à l’aide de l’interface utilisateur des pipelines.

Azure Pipelines fournit désormais une gestion d’accès affinée pour les pools d’agents. L’expérience est similaire à celle de la gestion des autorisations de pipeline pour les Connecter ions de service.

Empêcher d’accorder à tous les pipelines l’accès aux ressources protégées

Lorsque vous créez une ressource protégée telle qu’une connexion de service ou un environnement, vous avez la possibilité de sélectionner l’autorisation Accorder l’accès à tous les pipelines case activée box. Jusqu’à présent, cette option a été case activée par défaut.

Bien qu’il soit plus facile pour les pipelines d’utiliser de nouvelles ressources protégées, l’inverse est qu’il favorise accidentellement l’octroi d’un trop grand nombre de pipelines le droit d’accéder à la ressource.

Pour promouvoir un choix sécurisé par défaut, Azure DevOps quitte désormais la case activée box non sécurisée.

Amélioration de la sécurité lors de la création de demandes de tirage à partir de référentiels GitHub forked

Vous pouvez utiliser Azure DevOps pour générer et tester votre dépôt GitHub public. Disposer d’un dépôt GitHub public vous permet de collaborer avec des développeurs à travers le monde, mais présente des problèmes de sécurité liés à la création de demandes de tirage (PR) à partir de dépôts dupliqués.

Pour empêcher les PR de dépliquer les référentiels GitHub de faire des modifications non souhaitées dans vos référentiels, Azure DevOps limite désormais le jeton d’accès GitHub à avoir une étendue en lecture seule.

L’étiquette macos la plus récente pointe vers l’image macos-12

L’image monterey macos-12 est prête à être la version par défaut de l’étiquette « macos-latest » dans les agents hébergés par Microsoft Azure Pipelines. Jusqu’à présent, cette étiquette pointait vers les agents macos-11 Big Sur.

Pour obtenir la liste complète des différences entre macos-12 et macos-11, consultez le problème GitHub. Pour obtenir la liste complète des logiciels installés sur l’image, case activée ici.

L’étiquette Ubuntu la plus récente pointe vers l’image ubuntu-22.04

L’image ubuntu-22.04 est prête à être la version par défaut de l’étiquette ubuntu-latest dans les agents hébergés par Microsoft Azure Pipelines. Jusqu’à présent, cette étiquette pointait vers les agents ubuntu-20.04.

Pour obtenir la liste complète des différences entre ubuntu-22.04 et ubuntu-20.04, consultez le problème GitHub. Pour obtenir la liste complète des logiciels installés sur l’image, case activée ici.

Étapes suivantes

Notes

Ces fonctionnalités seront déployées au cours des deux à trois prochaines semaines.

Accédez à Azure DevOps et jetez un coup d’œil.

Accéder à Azure DevOps

Comment fournir des commentaires

Nous aimerions savoir ce que vous pensez de ces fonctionnalités. Utilisez le menu Aide pour signaler un problème ou faire une suggestion.

Vous pouvez également obtenir des conseils et répondre à vos questions par la communauté sur Stack Overflow.

Merci,

Vijay Machiraju