Gestion de la sécurité améliorée

Avec cette mise à jour, vous avez désormais la possibilité d’activer ou de désactiver Advanced Security pour l’ensemble de votre projet ou organization. Vous pouvez également activer automatiquement Advanced Security pour les dépôts ou projets nouvellement créés.

Dans Azure Pipelines, nous avons ajouté un contrôle centralisé pour améliorer la sécurité des demandes de tirage générées à partir de dépôts GitHub dupliqués.

Consultez les notes de publication pour en savoir plus sur ces fonctionnalités.

Général

• Activation des projets et des organization pour Advanced Security

• Estimation du nombre de commiteurs lors de l’activation d’Advanced Security

Azure Pipelines

• Réessayez une étape lorsque les approbations et les vérifications expirent

• Rôle administrateur pour tous les environnements

• Contrôle centralisé pour la création de demandes de tirage à partir de dépôts GitHub dupliqués

Azure Repos

• Nouvelle « stratégie de branche » empêchant les utilisateurs d’approuver leurs propres modifications

Azure Artifacts

• Présentation de la prise en charge d’Azure Artifacts pour Cargo Crates (préversion publique)

Général

Activation des projets et des organization pour Advanced Security

Vous pouvez maintenant activer ou désactiver Advanced Security pour l’ensemble de votre projet ou organization. Conjointement avec le nouvel ajout de l’affichage du nombre de commiteurs avant l’activation, la sélection de « Tout activer » au niveau du projet ou organization vous fournira une estimation du nombre de nouveaux commiteurs actifs qui peuvent vous être facturés. Vous pouvez également choisir d’activer automatiquement Advanced Security pour les dépôts ou projets nouvellement créés sous votre projet ou organization respectif. Tous les dépôts activés via ce paramètre ont l’analyse des dépôts secrets et la protection push actives.

Activation au niveau du projet :

Activation au niveau de l’organisation :

Estimation du nombre de commiteurs lors de l’activation d’Advanced Security

Dans le cadre de votre expérience d’intégration de sécurité avancée, vous pouvez maintenant voir une estimation du nombre de commiteurs actifs qui ont été ajoutés suite à l’activation de la sécurité avancée pour un dépôt, un projet ou un organization particulier. Ce nombre est une approximation et vous pouvez voir de légères différences entre l’estimation fournie et ce qui est signalé pour la facturation après activation. Cette estimation peut également être obtenue via l’API avec une documentation supplémentaire expliquant ce processus bientôt.

Azure Pipelines

Réessayez une étape lorsque les approbations et les vérifications expirent

Lorsque les approbations et les vérifications expirent, la phase à laquelle ils appartiennent est ignorée. Les étapes qui ont une dépendance sur l’étape ignorée sont également ignorées.

Vous pouvez maintenant réessayer une étape lors de l’expiration des approbations et des vérifications. Auparavant, cela était possible uniquement lorsqu’une approbation a expiré.

Rôle administrateur pour tous les environnements

Les environnements dans les pipelines YAML représentent une ressource de calcul sur laquelle vous déployez votre application, par exemple un cluster AKS ou un ensemble de machines virtuelles. Ils vous fournissent des contrôles de sécurité et une traçabilité pour vos déploiements.

La gestion des environnements peut être très difficile. En effet, lorsqu’un environnement est créé, la personne qui le crée devient automatiquement le seul administrateur. Par exemple, si vous souhaitez gérer les approbations et les vérifications de tous les environnements de manière centralisée, vous devez demander à chaque administrateur d’environnement d’ajouter un utilisateur ou un groupe spécifique en tant qu’administrateur, puis d’utiliser l’API REST pour configurer les vérifications. Cette approche est fastidieuse, sujette aux erreurs et ne se met pas à l’échelle lorsque de nouveaux environnements sont ajoutés.

Avec ce sprint, nous avons ajouté un rôle Administrateur au niveau du hub d’environnements. Les environnements sont ainsi au même niveau que les connexions de service ou les pools d’agents. Pour attribuer le rôle Administrateur à un utilisateur ou à un groupe, vous devez déjà être administrateur de hub d’environnements ou propriétaire de organization.

Un utilisateur disposant de ce rôle d’administrateur peut administrer les autorisations, gérer, afficher et utiliser n’importe quel environnement. Cela inclut l’ouverture d’environnements à tous les pipelines.

Lorsque vous accordez un rôle Administrateur d’utilisateur au niveau du hub des environnements, ils deviennent administrateurs pour tous les environnements existants et pour tous les environnements futurs.

Contrôle centralisé pour la création de demandes de tirage à partir de dépôts GitHub dupliqués

Si vous créez des référentiels publics à partir de GitHub, vous devez considérer votre position concernant les builds de duplication. Les duplications sont particulièrement dangereuses, car elles proviennent de l’extérieur de votre organisation.

Vous pouvez améliorer la sécurité des pipelines qui génèrent des dépôts publics GitHub en consultant nos recommandations sur la façon de créer des dépôts GitHub et la protection des dépôts. Malheureusement, la gestion de nombreux pipelines et la garantie de leur respect des meilleures pratiques peuvent nécessiter beaucoup d’efforts.

Pour améliorer la sécurité de vos pipelines, nous avons ajouté un contrôle de niveau organization pour définir la façon dont les pipelines génèrent des demandes de tirage à partir de dépôts GitHub dupliqués. Le nouveau paramètre est nommé Limiter la génération des demandes de tirage à partir de dépôts GitHub dupliqués et fonctionne au niveau organization et du projet.

Le paramètre de niveau organization limite les paramètres que les projets peuvent avoir, et le paramètre au niveau du projet restreint les paramètres que les pipelines peuvent avoir.

Examinons comment le bouton bascule fonctionne à organization niveau. Le nouveau contrôle étant désactivé par défaut, aucun paramètre n’est appliqué universellement.

bascule

Lorsque vous activez le bouton bascule, vous pouvez choisir de désactiver la génération de demandes de tirage à partir de dépôts GitHub dupliqués. Cela signifie qu’aucun pipeline ne s’exécute lors de la création d’une telle demande de tirage.

Lorsque vous choisissez l’option Générer de manière sécurisée des demandes de tirage à partir de dépôts dupliqués, tous les pipelines, à l’échelle organization, ne peuvent pas rendre les secrets disponibles pour les builds de demandes de tirage à partir de dépôts dupliqués, ne peuvent pas faire en sorte que ces builds aient les mêmes autorisations que les builds normales et doivent être déclenchés par un commentaire de demande de tirage. Les projets peuvent toujours décider de ne pas autoriser les pipelines à créer de tels PR.

Lorsque vous choisissez l’option Personnaliser , vous pouvez définir comment restreindre les paramètres de pipeline. Par exemple, vous pouvez vous assurer que tous les pipelines nécessitent un commentaire pour générer une demande de tirage à partir d’un dépôt GitHub dupliqué, lorsque la demande de tirage appartient à des membres non-d’équipe et à des non-contributeurs. Toutefois, vous pouvez choisir de leur permettre de mettre des secrets à la disposition de ces builds. Les projets peuvent décider de ne pas autoriser les pipelines à créer de telles demandes de tirage, de les générer de manière sécurisée, ou d’avoir des paramètres encore plus restrictifs que ce qui est spécifié au niveau organization.

Azure Repos

Nouvelle « stratégie de branche » empêchant les utilisateurs d’approuver leurs propres modifications

Pour améliorer le contrôle des modifications approuvées par l’utilisateur et respecter des exigences réglementaires/de conformité plus strictes, nous proposons une option permettant d’empêcher l’utilisateur d’approuver ses propres modifications, sauf autorisation explicite.

L’utilisateur capable de gérer les stratégies de branche peut maintenant basculer l’option nouvellement ajoutée « Exiger au moins une approbation sur chaque itération » sous « Quand de nouvelles modifications sont envoyées ( push) ». Lorsque cette option est sélectionnée, au moins un vote d’approbation pour la dernière modification de branche source est requis. L’approbation de l’utilisateur n’est pas comptabilisée par rapport aux itérations non approuvées précédentes envoyées par cet utilisateur. Par conséquent, une approbation supplémentaire sur la dernière itération doit être effectuée par un autre utilisateur.

L’image suivante montre la demande de tirage créée par l’utilisateur A et 4 validations supplémentaires (itérations) effectuées pour cette demande de tirage par les utilisateurs B, C, A et C. Une fois la deuxième itération (validation effectuée par l’utilisateur B), l’utilisateur C l’a approuvée. À ce moment-là, il impliquait l’approbation de la première validation de l’utilisateur A (lors de la création de la demande de tirage) et la stratégie nouvellement introduite réussira. Après la cinquième itération (dernière validation de l’utilisateur C), l’approbation a été effectuée par l’utilisateur A. Cette approbation implicite pour une validation antérieure effectuée par l’utilisateur C, mais n’implique pas l’approbation de la deuxième validation effectuée par l’utilisateur A dans la quatrième itération. Pour que la stratégie nouvellement introduite réussisse, l’itération non approuvée quatre doit être approuvée par l’utilisateur B, C ou tout autre utilisateur qui n’a apporté aucune modification à la demande de tirage.

Azure Artifacts

Présentation de la prise en charge d’Azure Artifacts pour Cargo Crates (préversion publique)

Nous sommes heureux d’annoncer qu’Azure Artifacts offre désormais une prise en charge native des caisses cargo. Cette prise en charge inclut la parité des fonctionnalités par rapport à nos protocoles existants, en plus de crates.io étant disponible en tant que source amont. Les développeurs et les équipes Rust peuvent désormais consommer, publier, gérer et partager leurs caisses Cargo en toute transparence, tout en utilisant l’infrastructure robuste d’Azure et en restant dans l’environnement Azure DevOps familier.

Aucune inscription n’est nécessaire pour la préversion ; Vous pouvez commencer en accédant à votre projet Azure DevOps, en sélectionnant Artefacts et en suivant les instructions pour connecter votre projet Rust à votre flux Azure Artifacts.

É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édez à Azure DevOps

Comment fournir des commentaires

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

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

Merci,

Silviu Andrica