Recommandations pour sécuriser l’infrastructure partagée dans Azure Pipelines

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

Les ressources protégées dans Azure Pipelines sont une abstraction de l’infrastructure réelle. Suivez ces recommandations pour protéger l’infrastructure sous-jacente.

Utiliser les pools hébergés par Microsoft

Les pools hébergés par Microsoft offrent une isolation et une machine virtuelle propre pour chaque exécution d’un pipeline. Si possible, utilisez des pools hébergés par Microsoft plutôt que des pools auto-hébergés.

Agents distincts pour chaque projet

Un agent ne peut être lié qu’à un seul pool. Vous pouvez partager des agents entre des projets en partageant le pool avec plusieurs projets. En d’autres termes, plusieurs projets peuvent exécuter des travaux sur le même agent, l’un après l’autre. Bien que cette pratique permette de réduire les coûts d'infrastructure, elle peut permettre des mouvements latéraux.

Pour éliminer cette forme de mouvement latéral et empêcher un projet d'« empoisonner » un agent pour un autre projet, conservez des pools d’agents distincts avec des agents distincts pour chaque projet.

Utiliser des comptes à faible privilège pour exécuter des agents

Il est tentant mais dangereux d’exécuter l’agent sous une identité qui peut accéder directement aux ressources Azure DevOps. Cette configuration problématique est courante dans les organisations qui utilisent Microsoft Entra ID. Si vous exécutez l'agent sous une identité soutenue par Microsoft Entra ID, il peut alors accéder directement aux API Azure DevOps sans utiliser le jeton d'accès de la tâche. Vous devez à la place exécuter l’agent en tant que compte local non privilégié tel que le Service réseau.

Azure DevOps dispose d’un groupe qui s’appelle de manière trompeuse les comptes de service de la collection de projets. Par héritage, les membres des comptes de service de la collection de projets sont également membres des administrateurs de la collection de projets. Les clients exécutent parfois leurs agents de build en utilisant une identité soutenue par Microsoft Entra ID et membre des comptes Project Collection Service. Si des personnes mal intentionnées exécutent un pipeline sur l’un de ces agents de build, elles peuvent prendre le contrôle de l’ensemble de l’organisation Azure DevOps.

Nous avons également vu des agents auto-hébergés s’exécuter sous des comptes hautement privilégiés. Souvent, ces agents utilisent des comptes privilégiés pour accéder aux secrets ou aux environnements de production. Mais si des personnes mal intentionnées exécutent un pipeline compromis sur l’un de ces agents de build, ils peuvent accéder à ces secrets. Ensuite, les personnes mal intentionnées peuvent se déplacer latéralement par la suite via d’autres systèmes accessibles par ces comptes.

Pour garantir la sécurité de vos systèmes, utilisez le compte avec les privilèges les plus bas pour exécuter les agents auto-hébergés. Par exemple, utilisez votre compte d’ordinateur ou une identité de service managé. Laissez Azure Pipelines gérer l’accès aux secrets et aux environnements.

Réduire l’étendue des connexions de service

Les connexions de service doivent être en mesure d’accéder uniquement aux ressources dont elles ont besoin. Si possible, utilisez la fédération des identités de charge de travail au lieu d’un principal de service pour votre connexion de service Azure. La fédération des identités de charge de travail utilise une technologie standard, Open ID Connect (OIDC), pour faciliter l’authentification entre Azure et Azure DevOps, et n’utilise pas de secrets.

Votre connexion de service Azure doit être étendue aux ressources auxquelles elle doit accéder. Les utilisateurs ne doivent pas disposer de droits de contributeur étendus pour l’ensemble de l’abonnement Azure.

Lorsque vous créez une nouvelle connexion de service Azure Resource Manager, sélectionnez toujours un groupe de ressources. Vérifiez que votre groupe de ressources contient uniquement les machines virtuelles ou les ressources requises par la build. De même, lorsque vous configurez l’application GitHub, octroyez l’accès uniquement aux référentiels que vous souhaitez générer à l’aide d’Azure Pipelines.

Étapes suivantes

Prenez en compte quelques recommandations générales pour la sécurité.