Protection des référentiels

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2020

Le code source, le fichier YAML du pipeline, ainsi que les scripts et outils nécessaires sont tous stockés dans un référentiel de gestion de version. Les autorisations et les stratégies de branche doivent être utilisées pour garantir que les modifications apportées au code et au pipeline sont sécurisées. Vous pouvez également ajouter des autorisations de pipeline et des vérifications aux référentiels.

En outre, vous devez passer en revue le contrôle d’accès par défaut pour les référentiels.

En raison de la conception de Git, la protection au niveau de la branche a ses limites. Les utilisateurs ayant l’accès pour envoyer à un référentiel peuvent généralement créer de nouvelles branches. Si vous utilisez des projets open source GitHub, toute personne disposant d’un compte GitHub peut dupliquer votre référentiel et proposer des contributions à son tour. Étant donné que les pipelines sont associés à un référentiel et non à des branches spécifiques, vous devez supposer que le code et les fichiers YAML ne sont pas approuvés.

Fourches

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. Pour protéger vos produits du code fourni, tenez compte des recommandations suivantes.

Notes

Les recommandations suivantes s’appliquent principalement à la création de référentiels publics à partir de GitHub.

Ne fournissez pas de secrets aux builds forks

Par défaut, vos pipelines sont configurés pour générer des duplications, mais les secrets et les ressources protégées ne sont pas mis à la disposition des travaux de ces pipelines par défaut. Ne désactivez pas cette dernière protection.

Remarque

Lorsque vous activez les builds de fork pour accéder aux secrets, Azure Pipelines restreint par défaut le jeton d’accès utilisé pour les builds de fork. Il a un accès plus limité aux ressources ouvertes qu’un jeton d’accès normal. Pour accorder aux builds de fork les mêmes autorisations que les builds standard, activez les builds Faites en sorte que les builds de fork aient les mêmes autorisations que les builds standard paramètre.

Envisagez de déclencher manuellement les builds de duplication

Vous pouvez désactiver des builds de duplication (fork) automatiques et utiliser à la place des commentaires de demandes de tirage (pull request) comme moyen pour générer manuellement ces contributions. Ce paramètre vous donne la possibilité d’examiner le code avant de déclencher une build.

Utiliser des agents hébergés par Microsoft pour les builds de duplication

N’exécutez pas de builds à partir de duplications sur des agents auto-hébergés. En procédant ainsi, vous fournissez un chemin d’accès aux organisations externes pour exécuter du code externe sur des machines à l’intérieur de votre réseau d’entreprise. Utilisez des agents hébergés par Microsoft dans la mesure du possible. Pour votre agent auto-hébergé, utilisez une forme d’isolation réseau et assurez-vous que les agents ne conservent pas leur état entre les travaux.

Passer en revue les modifications du code

Avant d’exécuter votre pipeline sur une demande de tirage dupliqué, examinez attentivement les modifications proposées et assurez-vous que vous êtes à l’aise pour l’exécuter.

La version du pipeline YAML que vous allez exécuter est celle de la demande de tirage. Par conséquent, prêtez une attention particulière aux modifications apportées au code YAML et au code qui s’exécute lorsque le pipeline s’exécute, comme les scripts de ligne de commande ou les tests unitaires.

Limitation de l’étendue des jetons GitHub

Lorsque vous générez une demande de tirage dupliqué GitHub, Azure Pipelines garantit que le pipeline ne peut pas modifier le contenu du référentiel GitHub. Cette restriction s’applique uniquement si vous utilisez l’application GitHub Azure Pipelines à intégrer dans GitHub. Si vous utilisez d’autres formes d’intégration GitHub, par exemple l’application OAuth, la restriction n’est pas appliquée.

Branches d’utilisateur

Les utilisateurs de votre organisation disposant des autorisations appropriées peuvent créer de nouvelles branches contenant du code nouveau ou mis à jour. Ce code peut s’exécuter via le même pipeline que vos branches protégées. En outre, si le fichier YAML de la nouvelle branche est modifié, le fichier YAML mis à jour est utilisé pour exécuter le pipeline. Bien que cette conception offre une grande flexibilité et le libre-service, toutes les modifications ne sont pas sécurisées (qu’elles soient effectuées de manière malveillante ou non).

Si votre pipeline consomme du code source ou est défini dans Azure Repos, vous devez comprendre entièrement le modèle d’autorisations Azure Repos. En particulier, un utilisateur disposant de l’autorisation Create Branch au niveau du référentiel peut introduire du code dans le référentiel, même si cet utilisateur n’a pas l’autorisation Contribuer .

Étapes suivantes

Ensuite, découvrez une protection plus importante offerte par des vérifications sur ressources protégées.