Partager via


Secrets dans Azure Pipelines

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

Cet article fournit les meilleures pratiques pour protéger les secrets dans Azure Pipelines. Un secret est un élément pour lequel vous voulez contrôler étroitement l’accès. Il peut s’agir de clés d’API, de mots de passe, de certificats ou de clés de chiffrement. Azure Pipelines ne génère pas de valeurs secrètes, mais vous devrez peut-être ajouter des secrets aux pipelines pour stocker des données sensibles telles que des clés API.

Cet article fait partie d’une série qui vous aide à implémenter des mesures de sécurité pour Azure Pipelines. Pour plus d’informations, consultez Sécuriser Azure Pipelines.

Conditions préalables

Catégorie Exigences
Azure DevOps - Implémentez des recommandations dans Rendre vos pipelines Azure DevOps sécurisés et sécurisés.
- Connaissance de base de YAML et d’Azure Pipelines. Pour plus d’informations, consultez Créer votre premier pipeline.
Autorisations - Pour modifier les autorisations des pipelines : membre du groupe Administrateurs de projet.
- Pour modifier les autorisations de l'Organisation : Membre du groupe Project Collection Administrators.

Utiliser une autre méthode

Les secrets présentent des risques de sécurité inhérents, il est donc préférable de ne pas les utiliser du tout. Au lieu de gérer des secrets dans des variables ou de les exposer dans votre configuration de pipeline, vérifiez si votre pipeline peut utiliser l’une de ces autres méthodes pour effectuer une tâche.

Pour plus d’informations, consultez Utiliser des principaux de service et des identités managées.

Utiliser des variables secrètes

Ne stockez jamais de valeurs sensibles sous forme de texte brut dans un fichier azure-pipelines.yml . Vous pouvez utiliser des variables secrètes pour les informations privées telles que les mots de passe, les ID et d’autres données d’identification que vous ne souhaitez pas exposer. Les variables secrètes sont chiffrées. Vous pouvez donc les utiliser dans des pipelines sans exposer leurs valeurs.

  • Il est préférable de gérer en toute sécurité les variables secrètes dans Azure Key Vault. Vous pouvez également définir des variables secrètes dans l’interface utilisateur de définition de pipeline ou dans un groupe de variables.
  • N’utilisez pas de commande de journalisation pour définir une variable secrète, car toute personne qui peut accéder à votre pipeline peut également voir le secret.
  • Ne jamais faire écho aux secrets en tant que sortie, et ne transmettez pas de secrets sur la ligne de commande. Au lieu de cela, il est préférable de mapper vos secrets dans des variables d’environnement.
  • Lorsque vous créez un secret, suivez les instructions de nommage des variables et assurez-vous que votre nom de secret ne divulgue pas d’informations sensibles.

Pour en savoir plus sur la définition des secrets dans les variables, consultez Définir des variables secrètes.

Limiter l’accès aux variables secrètes

Pour limiter l’accès aux secrets dans Azure DevOps, suivez l’une des pratiques suivantes :

  • Stocker vos secrets dans Azure Key Vault. En utilisant Azure Key Vault, vous pouvez utiliser le contrôle d’accès en fonction du rôle Azure pour limiter l’accès à un secret ou à un groupe de secrets.
  • Définissez des variables secrètes dans l’interface utilisateur du pipeline. Ces variables sont étendues au pipeline où elles sont définies. Elles sont donc visibles uniquement par les utilisateurs de ce pipeline.
  • Définissez des secrets dans des groupes de variables. Les groupes de variables suivent le modèle de sécurité de la bibliothèque . Vous pouvez donc contrôler qui peut accéder ou créer des éléments.

Ne pas écrire de secrets dans les journaux

Azure Pipelines s'efforce de supprimer des secrets des journaux autant que possible, mais n'est pas infaillible. Évitez de renvoyer des secrets à la console, de les utiliser dans des paramètres de ligne de commande ou de les journaliser dans des fichiers.

Soyez prudent lorsque vous utilisez des commandes Azure CLI qui génèrent des informations sensibles. Utilisez le format de sortie None et, si vous devez récupérer un secret à partir d’un appel Azure CLI, récupérez les informations de sécurité d’une variable secrète.

Ne pas utiliser de données structurées en tant que secrets

Évitez d’utiliser des formats de données structurés tels que JSON, XML ou YAML pour encapsuler des valeurs secrètes, y compris les caractères de contrôle tels que le retour \r chariot et le flux de \nligne. Au lieu de cela, créez des secrets individuels pour chaque valeur sensible. Cette approche garantit une meilleure précision de la rédaction et réduit le risque d’exposer par inadvertance des données sensibles.

Auditer l’utilisation du secret

Pour auditer la façon dont vos pipelines utilisent des secrets, suivez les bonnes pratiques suivantes :

  • Examinez le code source du référentiel qui héberge le pipeline. Pour vous assurer que les secrets sont gérés correctement, vérifiez toutes les tâches que le pipeline utilise. Vérifiez que les secrets ne sont pas envoyés par inadvertance à des hôtes inattendus ou explicitement imprimés dans les journaux.

  • Après avoir testé des entrées valides et non valides, consultez les journaux d’exécution de votre pipeline. Assurez-vous que les secrets sont correctement supprimés et non exposés. Parfois, les erreurs dans les commandes ou les outils risquent de fuiter par inadvertance des secrets dans les journaux d’erreurs. Bien qu’Azure Pipelines tente de nettoyer les secrets des journaux, la révision manuelle est toujours essentielle.

Auditer et alterner les secrets

Pour auditer et faire pivoter les secrets, suivez les bonnes pratiques suivantes :

  • Passez régulièrement en revue les secrets inscrits dans vos pipelines. Vérifiez qu’ils sont toujours nécessaires et supprimez ceux qui ne sont plus nécessaires. Cette pratique permet de réduire l’encombrement et les risques de sécurité potentiels.
  • Vérifiez la configuration appropriée et la gestion sécurisée des secrets de connexion de service.
  • Conservez la durée du jeton d’accès personnel (PAT) courte et choisissez les autorisations minimales nécessaires.
  • Changer régulièrement les secrets pour réduire la durée pendant laquelle un secret compromis pourrait être exploité. La modification périodique des secrets améliore la sécurité.

Utiliser des modèles YAML

Au lieu d’inclure des scripts inline avec des paramètres de secret directement dans votre yaML de pipeline, utilisez des modèles. Cette approche améliore la sécurité en extrayant les informations sensibles du pipeline principal.

Pour implémenter cette approche, créez un fichier YAML distinct pour votre script et stockez ce script dans un dépôt distinct et sécurisé. Vous pouvez ensuite référencer le modèle et passer une variable secrète à partir d’Azure Key Vault, d’un groupe de variables ou de l’interface utilisateur du pipeline dans votre yaML en tant que paramètre. Pour plus d’informations sur l’utilisation de modèles, consultez la référence sur l’utilisation du modèle.

Limiter les secrets avec des stratégies de branche et des autorisations de groupe de variables

Pour vous assurer que les secrets sont accessibles uniquement à une branche spécifique du dépôt, vous pouvez utiliser une combinaison de stratégies de branche, de permissions des groupes de variables et de l'insertion conditionnelle de tâches.

Appliquez des stratégies de validation de build qui autorisent les builds uniquement à partir d’une certaine branche. Utilisez ensuite des autorisations de groupe de variables pour vous assurer que seuls les pipelines autorisés peuvent accéder aux secrets stockés dans votre groupe de variables. Enfin, utilisez une condition dans votre pipeline pour vous assurer que seul un push vers la branche désignée peut référencer le groupe de variables.

jobs:
- job: ExampleJob
  condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))
  pool:
    vmImage: 'ubuntu-latest'
  steps:
  - script: echo "This runs only for the main branch"
    displayName: 'Conditional Step'
  variables:
  - group: your-variable-group-name