Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022
Gérez qui peut accéder à vos référentiels Git et quelles actions ils peuvent effectuer. Définissez les autorisations au niveau de tous les référentiels pour les appliquer à chaque dépôt Git dans un projet ou définissez des autorisations pour un dépôt individuel. Les dépôts individuels héritent des autorisations de l’entrée de référentiels Git au niveau du projet.
Note
Les branches héritent d’un sous-ensemble d’autorisations attribuées au niveau du référentiel. Pour obtenir des autorisations et des stratégies de branche, consultez Définir des autorisations de branche et Améliorer la qualité du code avec les stratégies de branche.
Pour obtenir un guide de sécurité complet couvrant les autorisations des référentiels, les stratégies de branche, la signature de validation et les scénarios d’implémentation réels, consultez Référentiels sécurisés et demandes d’extraction.
Pour obtenir des conseils sur les personnes qui fournissent des niveaux d’autorisation plus élevés, consultez Gérer l’accès à l’aide d’autorisations.
Prérequis
| Catégorie | Spécifications |
|---|---|
| Accès au projet | Appartenance à un projet Azure DevOps. |
| Permissions | Gérez les autorisations pour l’entrée de référentiels Git au niveau du projet afin de gérer chaque référentiel dans le projet, ou gérez les autorisations d’un référentiel individuel pour gérer ce référentiel. Les membres du groupe Administrateurs Project disposent de cette autorisation par défaut. Pour plus d'informations, consultez la Référence des autorisations et des groupes. |
| Services | Azure Repos activé. |
Passer en revue les autorisations de référentiel par défaut
Par défaut, les membres du groupe Contributeurs du projet sont autorisés à contribuer à un référentiel. Ce niveau d’autorisation inclut la possibilité de créer des branches, de créer des balises et de gérer des notes. Pour obtenir une description de chaque groupe de sécurité et niveau d’autorisation, consultez Autorisations et référence de groupe.
Permission
Lecteurs
Contributeurs
Générer des administrateurs
Administrateurs de projet
Lire (cloner, extraire et explorer le contenu d’un référentiel) ; peut également créer, commenter, voter et contribuer aux demandes de tirage
✔️
✔️
✔️
✔️
Contribuer, créer une branche, créer unebalise et gérer des notes
✔️
✔️
✔️
Créer un référentiel, Supprimer un référentielet Renommer un référentiel
✔️
Modifier les stratégies, Gérer les autorisations, Supprimer les verrous d’autres utilisateurs
✔️
Contourner les stratégies lors de la fin des demandes de tirage, Contourner les stratégies lors de l’envoi, Forcer l’envoi (réécrire l’historique, supprimer des branches et des balises)
(non défini pour un groupe de sécurité)
À compter de Azure DevOps sprint 224, les créateurs de branche n'obtiennent pas automatiquement l'autorisation Modifier les stratégies. Cette autorisation n’est pas accordée même si le paramètre de gestion des autorisations est activé pour le référentiel. Accordez des stratégies de modification explicitement via l’héritage, l’appartenance au groupe ou une affectation directe.
Dans Azure DevOps Server 2022.1 et versions ultérieures, les créateurs de branche n'obtiennent pas automatiquement l'autorisation Modifier les stratégies. Cette autorisation n’est pas accordée même si le paramètre de gestion des autorisations est activé pour le référentiel. Accordez des stratégies de modification explicitement via l’héritage, l’appartenance au groupe ou une affectation directe. Pour plus d’informations, consultez les notes de publication Azure DevOps Server 2022 Update 1.
Comprendre les états d’autorisation
Avant de modifier une autorisation, passez en revue la façon dont Azure DevOps évalue les états d’autorisation :
- Non défini n’accorde pas ou refuse l’autorisation. Les autorisations attribuées par le biais d’un autre groupe ou héritées d’une étendue parente peuvent toujours s’appliquer.
- Autorisez l’autorisation, sauf si un refus plus spécifique ou applicable le remplace.
- Refuser remplace généralement Autoriser, y compris les autorisations héritées ou accordées par le biais d’un autre groupe. Lorsque vous refusez une autorisation pour un groupe, le déni affecte tous les membres de ce groupe.
Passez en revue l’appartenance au groupe et les autorisations héritées avant d’attribuer un refus. Pour plus d’informations, consultez À propos des autorisations et des groupes.
Ouvrir la sécurité du référentiel
Définissez les autorisations de référentiel Git à partir desréférentiels de paramètres> Project.
Ouvrez le portail web et sélectionnez le projet dans lequel vous souhaitez ajouter des utilisateurs ou des groupes. Pour sélectionner un autre projet, consultez Changer de projet, référentiel, équipe.
Sélectionnez Paramètres de projet>Référentiels.
Pour définir des autorisations pour chaque référentiel Git dans le projet, sélectionnez Sécurité de tous les référentiels>.
Pour définir des autorisations pour un référentiel spécifique, sélectionnez le référentiel, puis sélectionnez Sécurité.
Définissez les autorisations de référentiel Git à partir desréférentiels de paramètres> Project.
Ouvrez le portail web et sélectionnez le projet dans lequel vous souhaitez gérer les autorisations. Pour sélectionner un autre projet, consultez Changer de projet, référentiel, équipe.
Sélectionnez Paramètres de projet>Référentiels.
Pour définir des autorisations pour chaque dépôt Git dans le projet, sélectionnez référentiels Git, puis sélectionnez l’utilisateur ou le groupe de sécurité dont vous souhaitez gérer les autorisations.
Pour afficher l’image complète, cliquez sur l’image à développer. Choisissez
pour fermer.
Sinon, sélectionnez un référentiel spécifique, puis sélectionnez l’utilisateur ou le groupe de sécurité dont vous souhaitez gérer les autorisations.
Modifiez les autorisations, puis sélectionnez Enregistrer les modifications.
Vérifiez que chaque autorisation modifiée conserve son nouvel état.
Modifier les autorisations d’un groupe
Pour définir des autorisations pour un groupe de sécurité personnalisé, définissez d’abord le groupe. Pour plus d’informations, consultez Modifier les autorisations au niveau du projet.
Sélectionnez le groupe pour définir des autorisations. Par exemple, sélectionnez Contributeurs.
Modifiez une ou plusieurs autorisations. Pour accorder une autorisation, sélectionnez Autoriser. Pour supprimer une attribution explicite et utiliser des autorisations héritées ou de groupe, sélectionnez Non défini. Sélectionnez Refuser uniquement lorsque vous devez remplacer une autorisation applicable.
Les modifications d’autorisation sont automatiquement enregistrées. Vérifiez que chaque autorisation modifiée affiche l’état prévu.
Modifier les autorisations d’un utilisateur
Entrez le nom de l’utilisateur dans le filtre de recherche et sélectionnez parmi les identités qui semblent définir des autorisations pour un utilisateur spécifique.
Modifiez une ou plusieurs autorisations pour l’utilisateur sélectionné.
Note
Vous ne pouvez peut-être pas trouver un utilisateur à partir d’une page d’autorisations ou d’un champ d’identité si l’utilisateur n’a pas été ajouté au projet en l’ajoutant à un groupe de sécurité ou à une équipe de projet. En outre, lorsqu’un utilisateur est ajouté à Microsoft Entra ID ou Active Directory, il peut y avoir un délai entre le moment où il est ajouté au projet et lorsqu’il peut faire l’objet d’une recherche à partir d’un champ d’identité. Le délai peut être compris entre 5 minutes et 7 jours.
Les modifications d’autorisation sont automatiquement enregistrées pour l’utilisateur sélectionné. Vérifiez que chaque autorisation modifiée affiche l’état prévu.
Vous pouvez ajouter un utilisateur ou un groupe et ne modifier aucune autorisation pour cet utilisateur ou ce groupe. Une fois la page d’autorisations actualisée, l’utilisateur ou le groupe n’apparaît plus.
Configurer l’héritage pour un référentiel
Avant de modifier l’héritage, enregistrez le paramètre actuel et passez en revue les autorisations explicites et héritées du référentiel. Lorsque vous désactivez l’héritage, les autorisations de l’entrée de référentiels Git au niveau du projet ne circulent plus vers le référentiel. Vérifiez que les affectations restantes fournissent l’accès prévu avant de continuer.
Pour activer ou désactiver l’héritage pour un référentiel spécifique, sélectionnez le référentiel, puis définissez l’héritagesur Activé ou Désactivé.
Après avoir modifié l’héritage, vérifiez les attributions d’autorisations du référentiel avec un utilisateur concerné. Si le résultat est incorrect, restaurez les états d’autorisation et de paramètre précédents. Pour en savoir plus sur l’héritage, consultez À propos des autorisations et des groupes.
Configurer les autorisations de contournement de stratégie
Il existe de nombreux scénarios où vous avez parfois besoin de contourner une stratégie de branche. Voici quelques exemples lorsque vous rétablissez une modification qui a provoqué un arrêt de build ou appliqué un correctif logiciel au milieu de la nuit.
Auparavant, l'autorisation Exempt de l'application des politiques a aidé les équipes à gérer les utilisateurs auxquels on a accordé la possibilité de contourner les politiques de branche lorsqu'ils ont terminé une pull request. Toutefois, cette autorisation accordait également aux utilisateurs la possibilité d’effectuer des envois directs vers la branche et de contourner entièrement le processus de pull request.
Les deux autorisations suivantes remplacent Exempt de l’application de la stratégie et fournissent un contrôle plus précis :
- Contourner les stratégies lors de la soumission des pull requests : les utilisateurs disposant de cette autorisation peuvent utiliser le processus de dérogation pour les pull requests.
- Contourner les stratégies lors du push : les utilisateurs disposant de cette autorisation peuvent pousser directement vers des branches où des stratégies requises sont configurées.
Pour permettre à un utilisateur de contourner les stratégies uniquement lors de la fin des demandes de tirage, définissez les stratégies de contournement lors de la fin des demandes de tirage sur Autoriser. Laissez les stratégies de contournement lors de l’envoi (push) comme Non défini si l’utilisateur ne reçoit pas d’autorisation via une autre attribution. Définissez-le sur Refuser uniquement lorsque vous devez remplacer une autorisation applicable.
Note
Utilisateurs précédemment exemptés de l’application de la stratégie définie sur Autoriserles autorisations autorisées pour les deux autorisations de remplacement. Passez en revue ces affectations et définissez des stratégies de contournement lorsque les utilisateurs n’ont pas besoin d’envoyer (push ) directement aux branches protégées et qu’aucune autre attribution n’accorde l’autorisation.
Résoudre les problèmes liés aux modifications d’autorisation
Utilisez les instructions suivantes lorsqu’une modification d’autorisation n’a pas le résultat attendu :
| Problème | Résolution |
|---|---|
| Vous ne pouvez pas modifier une autorisation | Vérifiez que vous disposez des autorisations De gestion à l’entrée de référentiels Git au niveau du projet ou du référentiel sélectionné. |
| Un utilisateur ou un groupe n’apparaît pas dans la recherche | Ajoutez l’identité au projet par le biais d’une équipe ou d’un groupe de sécurité. Les modifications d’identité peuvent prendre du temps à apparaître dans la recherche. |
| Une autorisation n’accorde pas l’accès | Vérifiez les appartenances aux groupes de l’utilisateur et des étendues plus spécifiques pour obtenir un refus applicable. |
| Une autorisation affecte les dépôts incorrects | Vérifiez si vous avez modifié tous les référentiels ou un référentiel individuel. |
| Une autorisation retourne une fois que vous avez sélectionné Non défini | Vérifiez si l’autorisation est héritée ou accordée par le biais d’un autre groupe. |
| La désactivation de l’héritage supprime l’accès | Restaurez le paramètre d’héritage précédent ou les affectations d’autorisations explicites que vous avez enregistrées avant la modification. |
Une fois que vous avez résolu le problème, un utilisateur concerné vérifie l’action de dépôt prévue.
Conseil / Astuce
Vous pouvez utiliser l’IA pour faciliter les tâches Azure DevOps. Consultez Activer l'assistance IA avec Azure DevOps MCP Server pour commencer.