Fédération des identités de charge de travail pour la préversion publique d’Azure Pipelines
Nous sommes heureux d’annoncer que la fédération des identités de charge de travail pour Azure Pipelines est désormais en préversion publique ! Les connexions de service Azure (ARM) ont été mises à jour avec un schéma supplémentaire pour prendre en charge la fédération des identités de charge de travail.
Consultez les notes de publication pour découvrir comment vous pouvez vous inscrire à la préversion publique.
Azure Boards
Azure Pipelines
Fédération des identités de charge de travail dans Azure Pipelines (préversion publique)
Les agents de pipeline peuvent être inscrits à l’aide de l’ID Microsoft Entra au lieu d’un PAT
Générer des référentiels GitHub en toute sécurité par défaut
Azure Repos
Azure Boards
Limites pour les chemins d’itération et de zone
Les limites jouent un rôle important dans le maintien de l’intégrité et de l’efficacité d’un service mondial important. Dans ce sprint, nous introduisons des limites strictes de 10 000 par projet pour les chemins d’itération et de zone. Visitez la page Suivi, processus et limites du projet pour en savoir plus sur les différentes limites du service.
Azure Pipelines
Fédération des identités de charge de travail dans Azure Pipelines (préversion publique)
Voulez-vous arrêter de stocker des secrets et des certificats dans les connexions de service Azure ? Vous voulez cesser de vous soucier de la rotation de ces secrets chaque fois qu’ils expirent ? Nous annonçons maintenant une préversion publique de la fédération des identités de charge de travail pour les connexions de service Azure.La fédération des identités de charge de travail utilise une technologie standard, Open ID Connecter (OIDC), pour simplifier l’authentification entre Azure Pipelines et Azure. Au lieu de secrets, un sujet de fédération est utilisé pour faciliter cette authentification.
Dans le cadre de cette fonctionnalité, la connexion de service Azure (ARM) a été mise à jour avec un autre schéma pour prendre en charge la fédération des identités de charge de travail. Cela permet aux tâches de pipeline qui utilisent la connexion de service Azure de s’authentifier à l’aide d’un objet de fédération (sc://<org>/<project>/<service connection name>). Les principaux avantages de l’utilisation de ce schéma sur les schémas d’authentification existants sont les suivants :
- Gestion simplifiée : vous ne devez plus générer, copier et stocker des secrets à partir de principaux de service dans Azure AD vers Azure DevOps. Les secrets utilisés dans d’autres schémas d’authentification des connexions de service Azure (par exemple, le principal de service) expirent après une certaine période (deux ans actuellement). Lorsqu’ils expirent, les pipelines échouent. Vous devez régénérer un nouveau secret et mettre à jour la connexion de service. Le passage à la fédération des identités de charge de travail élimine la nécessité de gérer ces secrets et améliore l’expérience globale de création et de gestion des connexions de service.
- Sécurité améliorée : avec la fédération des identités de charge de travail, il n’existe aucun secret persistant impliqué dans la communication entre Azure Pipelines et Azure. Par conséquent, les tâches exécutées dans des travaux de pipeline ne peuvent pas fuiter ou exfiltrer des secrets qui ont accès à vos environnements de production. Cela a souvent été une préoccupation pour nos clients.
Vous pouvez tirer parti de ces fonctionnalités de deux façons :
- Utilisez le nouveau schéma de fédération d’identité de charge de travail chaque fois que vous créez une connexion de service Azure. À l’avenir, ce sera le mécanisme recommandé.
- Convertissez vos connexions de service Azure existantes (basées sur des secrets) dans le nouveau schéma. Vous pouvez effectuer cette conversion une connexion à la fois. Mieux encore, vous n’avez pas besoin de modifier les pipelines qui utilisent ces connexions de service. Ils appliqueront automatiquement le nouveau schéma une fois la conversion terminée.
Pour créer une connexion de service Azure à l’aide de la fédération d’identité de charge de travail, sélectionnez simplement la fédération des identités de charge de travail (automatique) ou (manuelle) dans l’expérience de création de connexion de service Azure :
Pour convertir une connexion de service Azure créée précédemment, sélectionnez l’action « Convertir » après avoir sélectionné la connexion :
Toutes les tâches Azure incluses dans Azure Pipelines prennent désormais en charge ce nouveau schéma. Toutefois, si vous utilisez une tâche à partir de la Place de marché ou d’une tâche personnalisée locale à déployer sur Azure, il peut ne pas encore prendre en charge la fédération des identités de charge de travail. Dans ces cas, nous vous demandons de mettre à jour votre tâche pour prendre en charge la fédération des identités de charge de travail afin d’améliorer la sécurité. Vous trouverez ici la liste complète des tâches prises en charge.
Pour cette préversion, nous prenons en charge la fédération des identités de charge de travail uniquement pour les connexions de service Azure. Ce schéma ne fonctionne pas avec d’autres types de connexions de service. Pour plus d’informations, consultez notre documentation.
Ce billet de blog contient plus de détails.
Les agents de pipeline peuvent être inscrits à l’aide de l’ID Microsoft Entra au lieu d’un PAT
L’agent de pipeline prend désormais en charge davantage d’arguments pour utiliser un principal de service ou un utilisateur pour inscrire un agent. Vous devez accorder à l’identité l’accès utilisé au pool d’agents dans ses paramètres de sécurité. Cela supprime la nécessité d’utiliser un jeton d’accès personnel (PAT) pour la configuration ponctuelle des agents.
Inscrire un agent à l’aide d’un principal de service
Pour utiliser un principal de service pour inscrire un agent Pipelines auprès d’Azure DevOps Services, fournissez les arguments suivants :
--auth 'SP' --clientid 00001111-aaaa-2222-bbbb-3333cccc4444 --clientsecret --tenantid aaaabbbb-0000-cccc-1111-dddd2222eeee
Utiliser un principal de service dans l’extension de machine virtuelle agent
Les machines virtuelles Azure peuvent être incluses dans des groupes de déploiement à l’aide d’une extension de machine virtuelle. L’extension de machine virtuelle a été mise à jour pour utiliser un principal de service au lieu d’un PAT pour inscrire l’agent :
"settings": {
"userServicePrincipal": true
}
"protectedSettings": {
"clientId": "[parameters('clientId')]"
"clientSecret": "[parameters('clientSecret')]"
"tenantId": "[parameters('tenantId')]"
}
Inscrire un agent de manière interactive à l’aide du flux de code de l’appareil
Vous pouvez utiliser un navigateur web pour effectuer facilement la configuration. Lorsque vous exécutez le script de configuration de l’agent, entrez « AAD » pour le type d’authentification. Le script vous guidera tout au long des étapes suivantes, notamment l’emplacement où accéder sur le web et le code à entrer. Après avoir entré votre code sur le web, revenez à la console pour terminer la configuration de l’agent.
API REST pour les environnements
Un environnement est une collection de ressources que vous pouvez cibler avec des déploiements à partir d’un pipeline. Les environnements vous fournissent l’historique du déploiement, la traçabilité des éléments de travail et des validations et des mécanismes de contrôle d’accès.
Nous savons que vous souhaitez créer des environnements par programmation. Nous avons donc publié la documentation de leur API REST.
Empêcher les exécutions de pipeline inattendues
Aujourd’hui, si votre pipeline YAML ne spécifie pas de trigger section, il s’exécute pour les modifications envoyées à son référentiel. Cela peut créer une confusion quant à la raison pour laquelle un pipeline a été exécuté et entraîner de nombreuses exécutions involontaires.
Nous avons ajouté un paramètre pipelines au niveau de l’organisation et au niveau du projet nommé Désactiver le déclencheur YAML CI implicite qui vous permet de modifier ce comportement. Vous pouvez choisir de ne pas déclencher de pipelines si leur section de déclencheur est manquante.
Générer des référentiels GitHub en toute sécurité par défaut
Dernier sprint, nous avons introduit un contrôle centralisé pour la création de demandes de tirage à partir de dépôts GitHub forked.
Avec ce sprint, nous activons l’option Securely build pull requests from forked repositories au niveau de l’organisation, pour les nouvelles organisations. Les organisations existantes ne sont pas affectées.
Remplacement désactivé de l’état de la stratégie de couverture du code en échec lors de l’échec de la génération
Précédemment, l’état de la stratégie de couverture du code a été remplacé par « Échec » si votre build dans la demande de tirage a échoué. Il s’agissait d’un bloqueur pour certains d’entre vous qui avaient la build en tant que case activée facultatif et la stratégie de couverture du code comme une case activée requise pour les demandes de tirage, ce qui entraîne le blocage des demandes de tirage.
Avec ce sprint, la stratégie de couverture du code ne sera pas remplacée par « Échec » si la build échoue. Cette fonctionnalité sera activée pour tous les clients.
Azure Repos
Prise en charge des filtres sans objet blob et sans arborescence
Azure DevOps prend désormais en charge deux filtrages supplémentaires lors du clonage/extraction. Voici les éléments suivants : --filter=blob:none Et --filter=tree:0La première option (clone sans objet blob) est la meilleure utilisée pour le développement régulier, tandis que la deuxième option (clone sans arbre) convient mieux pour les cas où vous dis carte du clone après, par exemple l’exécution d’une build.
É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.
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,
Silviu Andrica