Deployment jobs

Fonctionnalité Business

Seuls les espaces de travail sur le plan Business peuvent accéder à la fonctionnalité Deployment jobs.

Introduction

Les deployment jobs sont une fonctionnalité clé qui permet de disséminer efficacement des honeytokens dans plusieurs dépôts de code. Ce processus consiste à créer des pull requests pour insérer un fichier contenant un honeytoken dans les dépôts ciblés.

Pendant un deployment job, pour chaque dépôt sélectionné, GitGuardian va :

1. Créer un honeytoken unique.
2. Le placer dans un contexte de fichier approprié.
3. Créer une pull request pour insérer le honeytoken dans le dépôt.

Il est important de noter que la décision de fusionner chaque honeytoken dans la branche principale revient à l'utilisateur, qui doit effectuer cette action directement dans le VCS. Le rôle de GitGuardian se limite à ouvrir la pull request. Dans tous les cas, vous devez considérer le honeytoken comme déployé dès la création de la pull request, puisqu'il est désormais visible dans le dépôt git.

info

Nous utilisons « Pull request » pour tous les Version Control Systems (VCS). Pour GitLab, cela équivaut à « Merge requests ».

Prérequis

info

Actuellement, cette fonctionnalité ne prend en charge que les sources GitLab et GitHub. Azure DevOps et BitBucket ne sont pas pris en charge pour le moment.

Pour utiliser les deployment jobs, GitGuardian requiert un accès en écriture sur les dépôts surveillés.

• Pour les projets GitLab : aucune configuration supplémentaire n'est nécessaire.
• Pour les dépôts GitHub et GitHub Enterprise Server : des étapes additionnelles sont nécessaires pour activer les permissions d'écriture. Voir les instructions détaillées dans les guides d'intégration pour GitHub ou GitHub Enterprise Server.

Créer un deployment job

Naviguez vers l'onglet « Deployment jobs » dans le module Honeytoken et cliquez sur Create deployment job.

1. Name : attribuez un nom descriptif à votre deployment job, indiquant son périmètre ou son objectif.
2. Context creation strategy : choisissez une stratégie pour les types de fichiers à utiliser pour l'insertion des honeytokens. Les détails sur les stratégies sont disponibles dans la section dédiée.
3. Tags : assignez des tags personnalisés aux honeytokens générés dans ce job, pour faciliter leur identification et leur filtrage. Par exemple, auto-deploy:true pourrait identifier les honeytokens créés depuis des deployment jobs.
4. Sources : sélectionnez les dépôts dans lesquels vous souhaitez déployer des honeytokens.

info

Certaines sources peuvent ne pas être éligibles aux deployment jobs : Azure DevOps, BitBucket, dépôts GitHub sans permissions d'écriture, sources hors du périmètre surveillé et sources publiques. Consultez la section d'aide pour la résolution de problèmes.

Note : le nombre de sources sélectionnées ne peut pas dépasser le nombre de honeytokens disponibles à la création.

Stratégie de création de contexte (context creation strategy)

Dans les paramètres Honeytoken, vous pouvez consulter et modifier les stratégies de création de contexte. Ces stratégies déterminent les types de fichiers dans lesquels les honeytokens peuvent être insérés, classés en « générique » ou « dynamique » :

info

« Générique » désigne les types de fichiers qui peuvent réalistement se trouver dans n'importe quel dépôt, indépendamment du langage de programmation, comme .env, .txt, .csv, .yaml, .json.
« Dynamique » désigne les types de fichiers et de contenus alignés avec le langage principal du dépôt cible. Nos contextes dynamiques sont générés par IA dans le langage demandé. À noter qu'aucun code n'est jamais envoyé au modèle.

Lors de la création ou de la modification d'une stratégie, vous devez sélectionner une option de « context creation », ainsi que les types de contextes génériques que vous souhaitez autoriser :

Même en sélectionnant l'option « Dynamic contexts », vous devez tout de même sélectionner au moins un type de contexte générique : si le langage du dépôt n'existe pas ou n'est pas disponible, le système basculera sur un fichier générique.

Suivre la progression de votre deployment job

Une fois un deployment job créé, vous pouvez consulter le statut de chaque déploiement individuel :

• Processing : la pull request est en attente.
• Pull request created : GitGuardian a créé avec succès le honeytoken et la pull request.
• Merged : le changement proposé a été approuvé et fusionné.
• Pull request closed : le changement proposé a été rejeté, fermant la pull request.
• Error : un problème est survenu pendant le déploiement (détails disponibles dans le panneau latéral en cliquant sur le déploiement).

Pour les statuts autres que « Processing » et « Error », vous trouverez des liens vers le honeytoken, la pull request et le fichier inséré.

Il est important de noter qu'un honeytoken est considéré comme déployé dès la création de la pull request, car il devient visible dans le dépôt, qu'il soit ou non fusionné. Si une pull request est fermée, le honeytoken reste en place tant que la branche et la pull request ne sont pas explicitement supprimées.

Caractéristiques des honeytokens créés par deployment job

Les honeytokens créés via les deployment jobs ont les caractéristiques suivantes :

• Le nom : correspond au nom de la source, suivi d'un suffixe basé sur le deployment job.
• Tags personnalisés : tels que spécifiés lors de la création du deployment job.
• Lien : lorsque la source est détectée et que l'information est ajoutée au honeytoken (peu après la création de la pull request), un lien permet de rediriger vers le déploiement associé.