Partager via

Nouvelles stratégies pour les jetons d’accès personnels

  • Article

Dans ce sprint, nous avons ajouté de nouvelles stratégies pour limiter l’étendue et la durée de vie des jetons d’accès personnels (PAT). En outre, nous avons mis à jour l’extension Windows Shell Team Foundation Version Control (TFVC) pour prendre en charge Visual Studio 2019.

Pour plus d’informations, consultez les descriptions des fonctionnalités suivantes.

Général

Azure Pipelines

Azure Repos

Général

Restreindre l’étendue et la durée de vie des jetons d’accès personnels (PAT) via la stratégie de locataire Azure AD

Les jetons d’accès personnels (PAT) facilitent l’authentification auprès d’Azure DevOps pour s’intégrer à vos outils et services. Toutefois, les jetons divulgués peuvent compromettre vos données et votre compte Azure DevOps, ce qui met vos applications et services en danger.

Nous avons reçu des commentaires indiquant que les administrateurs n’ont pas les contrôles nécessaires pour limiter la surface d’exposition des menaces posées par les paT fuites. Sur la base de ces commentaires, nous avons ajouté un nouvel ensemble de stratégies qui peuvent être utilisées pour limiter l’étendue et la durée de vie des jetons d’accès personnels (PAT) Azure DevOps de votre organization ! Voici comment ils fonctionnent :

Les utilisateurs affectés au rôle Administrateur Azure DevOps dans Azure Active Directory peuvent accéder à l’onglet Azure Active Directory dans les paramètres organization des organization Azure DevOps liés à leur Azure AD.

Contrôles PAT d’image

Là, les administrateurs peuvent :

  1. restreindre la création de jetons d’accès personnels globaux (jetons qui fonctionnent pour toutes les organisations Azure DevOps accessibles par l’utilisateur)
  2. restreindre la création de jetons d’accès personnels à étendue complète
  3. définir une durée de vie maximale pour les nouveaux jetons d’accès personnels

Ces stratégies s’appliquent à tous les nouveaux PAT créés par les utilisateurs pour les organisations Azure DevOps liées au locataire Azure AD. Chacune des stratégies a une liste verte pour les utilisateurs et les groupes qui doivent être exemptés de la stratégie. La liste des utilisateurs et des groupes dans la liste verte n’aura pas accès à la gestion de la configuration de la stratégie.

Ces stratégies s’appliquent uniquement aux nouveaux PAT et n’affectent pas les PAT existants qui ont déjà été créés et sont en cours d’utilisation. Toutefois, une fois les stratégies activées, tous les PAT existants, désormais non conformes, doivent être mis à jour pour respecter les restrictions avant de pouvoir être renouvelés.

Prise en charge de la stratégie d’accès conditionnel pour le trafic IPv6

Nous étendons maintenant la prise en charge des stratégies d’accès conditionnel (CAP) pour inclure des stratégies d’isolation IPv6. Comme nous voyons que les utilisateurs accèdent de plus en plus aux ressources Azure DevOps sur des appareils à partir d’adresses IPv6, nous voulons nous assurer que vos équipes sont équipées pour accorder et supprimer l’accès à partir de n’importe quelle adresse IP, y compris celles provenant du trafic IPv6.

Azure Pipelines

Conserver les pipelines consommés dans d’autres pipelines

Les versions classiques avaient la possibilité de conserver automatiquement les builds qu’elles consomment. Il s’agissait de l’un des écarts entre les versions classiques et les pipelines YAML, et cela a empêché certains d’entre vous de passer à YAML. Avec cette version, nous avons résolu cette lacune.

Vous pouvez maintenant créer un pipeline YAML à plusieurs étapes pour représenter votre mise en production et utiliser un autre pipeline YAML en tant que ressource. Dans ce cas, Azure Pipelines conserve automatiquement le pipeline de ressources tant que le pipeline de mise en production est conservé. Lorsque le pipeline de mise en production est supprimé, le bail sur le pipeline de ressources est libéré et ses propres stratégies de rétention sont suivies.

Modifications apportées à la création automatique d’environnements

Lorsque vous créez un pipeline YAML et que vous faites référence à un environnement qui n’existe pas, Azure Pipelines crée automatiquement l’environnement. Cette création automatique peut se produire dans le contexte utilisateur ou dans le contexte système. Dans les flux suivants, Azure Pipelines connaît l’utilisateur qui effectue l’opération :

  • Vous utilisez l’Assistant Création de pipeline YAML dans l’expérience web Azure Pipelines, puis faites référence à un environnement qui n’a pas encore été créé.
  • Vous mettez à jour le fichier YAML à l’aide de l’éditeur web Azure Pipelines, puis enregistrez le pipeline après avoir ajouté une référence à un environnement qui n’existe pas.

Dans chacun des cas ci-dessus, Azure Pipelines a une compréhension claire de l’utilisateur effectuant l’opération. Par conséquent, il crée l’environnement et ajoute l’utilisateur au rôle d’administrateur de l’environnement. Cet utilisateur dispose de toutes les autorisations nécessaires pour gérer l’environnement et/ou inclure d’autres utilisateurs dans différents rôles pour la gestion de l’environnement.

Dans les flux suivants, Azure Pipelines ne dispose pas d’informations sur l’utilisateur qui crée l’environnement : vous mettez à jour le fichier YAML à l’aide d’un autre éditeur de code externe, ajoutez une référence à un environnement qui n’existe pas, puis déclenchez un pipeline d’intégration manuel ou continu. Dans ce cas, Azure Pipelines ne connaît pas l’utilisateur. Auparavant, nous avons géré ce cas en ajoutant tous les contributeurs de projet au rôle Administrateur de l’environnement. Tout membre du projet peut ensuite modifier ces autorisations et empêcher d’autres personnes d’accéder à l’environnement.

Nous avons reçu vos commentaires sur l’octroi d’autorisations d’administrateur sur un environnement à tous les membres d’un projet. Lorsque nous avons écouté vos commentaires, nous avons entendu que nous ne devrions pas créer automatiquement un environnement s’il n’est pas clair que l’utilisateur effectuant l’opération est. Avec cette version, nous avons apporté des modifications à la façon dont les environnements seront automatiquement créés :

  • À l’avenir, les exécutions de pipeline ne créent pas automatiquement un environnement s’il n’existe pas et si le contexte utilisateur n’est pas connu. Dans ce cas, le pipeline échoue avec une erreur Environnement introuvable. Vous devez précréer les environnements avec la sécurité appropriée et vérifier la configuration avant de l’utiliser dans un pipeline.
  • Les pipelines avec un contexte utilisateur connu créent toujours automatiquement des environnements comme ils l’ont fait dans le passé.
  • Enfin, il convient de noter que la fonctionnalité permettant de créer automatiquement un environnement a été ajoutée uniquement pour simplifier le processus de prise en main d’Azure Pipelines. Il était destiné aux scénarios de test, et non aux scénarios de production. Vous devez toujours précréer des environnements de production avec les autorisations et les vérifications appropriées, puis les utiliser dans les pipelines.

Boîte de dialogue Supprimer des insights du pipeline de build

En fonction de vos commentaires, la boîte de dialogue Insights sur la tâche/pipeline qui s’affiche lors de la navigation dans le pipeline de build a été supprimée pour améliorer le flux de travail. L’analytique de pipeline est toujours disponible afin que vous disposiez des insights dont vous avez besoin.

Azure Repos

Mises à jour à Team Foundation Version Control (TFVC) extension Windows Shell pour Visual Studio 2019

La version précédente de l’extension Windows Shell TFVC fonctionnait uniquement sur les ordinateurs sur lesquels Visual Studio 2017 était installé.

Nous avons publié une nouvelle version de cet outil compatible avec Visual Studio 2019. L’extension fournit l’intégration à Windows Explorer et aux boîtes de dialogue de fichiers communes. Avec cette intégration, vous pouvez effectuer de nombreuses opérations de contrôle de code source sans avoir à exécuter Visual Studio ou un outil en ligne de commande Team Foundation.

É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 Aide pour signaler un problème ou faire une suggestion.

Faire une suggestion

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

Merci,

Vijay Machiraju