Sources non-VCS

Cette section explique comment activer et configurer les workers pour les intégrations non-VCS (Version Control System) dans GitGuardian Self-Hosted. Ces intégrations vous permettent de scanner les plateformes de messagerie, outils de documentation, systèmes de ticketing et container registries pour y détecter des secrets.

Par défaut, tous les workers pour ces intégrations sont désactivés (nombre de réplicas défini à 0).

Compatibilité des workers :

• Peuvent utiliser les workers VCS par défaut (mais workers dédiés recommandés) : Slack, Microsoft Teams, Confluence, Jira et ServiceNow peuvent optionnellement utiliser les mêmes workers que les sources VCS (worker-scanners, worker-worker, worker-long).
• Nécessitent des workers dédiés : toutes les autres intégrations (OneDrive, SharePoint, Container Registries, Package Registries) doivent utiliser leurs propres workers spécialisés et ne peuvent pas partager les workers VCS

Nous recommandons d'utiliser des workers dédiés pour toutes les intégrations afin d'éviter la congestion des queues et garantir des performances optimales.

Intégrations disponibles

Intégrations de messagerie

Surveillez les plateformes de messagerie pour détecter les secrets dans les conversations et le contenu partagé.

Sources disponibles :

• Microsoft Teams
• Slack

Workers requis :

• worker-realtime-ods - Traite les scans temps réel et événements
• worker-scanners-ods - Gère les scans historiques pour les plateformes de messagerie
• worker-scanners-slack - Worker dédié uniquement aux scans historiques Slack
• worker-long-ods - Traite les tâches longues pour les plateformes de messagerie
• worker-long-ods-io - Gère les tâches longues intensives en IO

Intégrations de documentation

Scannez les plateformes de documentation et les services de stockage de fichiers pour les secrets fuités.

Sources disponibles :

• Confluence Cloud
• Confluence Data Center
• Microsoft OneDrive
• Microsoft SharePoint Online

Workers requis :

• worker-realtime-ods - Traite les scans temps réel et événements
• worker-scanners-ods - Gère les scans historiques pour les plateformes de documentation
• worker-scanners-ods-highdisk - Requis pour les tâches à fort stockage (scan Microsoft OneDrive et SharePoint)
• worker-long-ods - Traite les tâches longues pour les plateformes de documentation
• worker-long-ods-io - Gère les tâches longues intensives en IO
• apache-tika - Requis lors du scan de Microsoft OneDrive et SharePoint pour les formats de documents Office

Intégrations de ticketing

Surveillez les systèmes de ticketing pour détecter les secrets dans les tickets, commentaires et pièces jointes.

Sources disponibles :

• Jira Cloud
• Jira Data Center
• ServiceNow

Workers requis :

• worker-realtime-ods - Traite les scans temps réel et événements
• worker-scanners-ods - Gère les scans historiques pour les plateformes de ticketing
• worker-long-ods - Traite les tâches longues pour les plateformes de ticketing
• worker-long-ods-io - Gère les tâches longues intensives en IO

Intégrations Container Registry

Scannez les images conteneur et les registries pour les secrets embarqués.

Sources disponibles :

• Amazon ECR
• Azure Container Registry
• Docker Hub
• Google Artifact Registry
• JFrog Container Registry

Workers requis :

• worker-container-registries - Worker dédié aux tâches de scan de container registries

Intégrations Package Registry

Scannez les artefacts des package registries pour les secrets sur plusieurs écosystèmes de packages.

Sources disponibles :

• JFrog Package Registries

Workers requis :

• worker-scanners-db-less - Worker dédié aux tâches de scan de package registries

info

L'instance Redis commit-cache est utilisée pour le scan de JFrog Package Registries. Si l'instance Redis commit-cache n'est pas configurée, l'instance Redis principale sera utilisée à la place.

Prérequis système

Workers standards

Chaque type de worker standard nécessite : 0,5 vCPU et 2 Gio de RAM par réplica

Pod file scanner

Pour le scan de binaires et fichiers (OneDrive/SharePoint) : 0,5 vCPU et 500 Mio de RAM par réplica

Workers à fort stockage

Pour les exigences de stockage élevées (OneDrive/SharePoint) : espace disque et capacité I/O supplémentaires

Configuration

Installation via KOTS

Pour activer les intégrations de sources non-VCS dans KOTS :

1. Accédez à la console d'administration KOTS

2. Naviguez jusqu'à la section Config

3. Localisez les sections de configuration des workers sous Scaling :

   • Container registries Worker
   • Non-VCS Sources Workers

   

4. Définissez un nombre positif de réplicas pour les workers requis (passez de 0 à 1 ou plus)

5. Si vous utilisez OneDrive/SharePoint, activez et définissez les réplicas dans la section File Scanner

6. Enregistrez la configuration

Installation via Helm

info

Pour les environnements airgap, les noms des images requises pour le file scanner se trouvent dans la documentation Air-gap Installation.

Pour les installations Helm, consultez la documentation des values Helm pour des options de configuration détaillées. Configurez les réplicas des workers dans votre fichier values.yaml.

Exemple de configuration minimale pour l'intégration de messagerie :

# File scanner (for OneDrive/SharePoint)
apacheTika:
  replicas: 1  # Set to 0 if not using OneDrive/SharePoint

# Celery Workers
celeryWorkers:
  # Messaging, Documentation, and Ticketing workers
  scanners-ods:
    replicas: 1
  scanners-slack: 
    replicas: 1  # Only needed for Slack
  long-ods:
    replicas: 1
  long-ods-io:
    replicas: 1
  realtime-ods:
    replicas: 1
    
  # Container registry workers
  container-registries:
    replicas: 1
    
  # High disk workers (for OneDrive/SharePoint)
  scanners-ods-highdisk:
    replicas: 1  # Set to 0 if not using OneDrive/SharePoint

Exemple de configuration pour l'intégration de documentation avec OneDrive/SharePoint :

apacheTika:
  replicas: 1

celeryWorkers:
  scanners-ods:
    replicas: 1
  scanners-ods-highdisk:
    replicas: 1  # Required for OneDrive/SharePoint
  long-ods:
    replicas: 1
  long-ods-io:
    replicas: 1
  realtime-ods:
    replicas: 1

Exemple de configuration pour l'intégration de ticketing :

celeryWorkers:
  scanners-ods:
    replicas: 1
  long-ods:
    replicas: 1
  long-ods-io:
    replicas: 1
  realtime-ods:
    replicas: 1

Exemple de configuration pour les container registries :

celeryWorkers:
  container-registries:
    replicas: 1

Exemple de configuration pour les package registries :

celeryWorkers:
  scanners-db-less:
    replicas: 1

Scaling

Après avoir activé les intégrations de base, consultez la documentation Scaling pour des informations détaillées sur :

• Configurer les paramètres de scaling selon votre charge de travail
• Surveiller les performances des workers
• Optimiser l'allocation des ressources
• Gérer un débit accru

Cette page se concentre sur l'activation initiale - la documentation Scaling couvre l'optimisation des performances et la planification de capacité.

Notes

• Isolation des queues : utiliser des workers dédiés empêche les sources non-VCS d'interférer avec les performances de scan VCS
• File scanner : requis uniquement lors du scan de Microsoft OneDrive et SharePoint pour le scan de fichiers (documents Office, PDF, etc.)
• Workers à fort stockage : le worker-scanners-ods-highdisk est spécifiquement conçu pour les tâches nécessitant un stockage important, principalement le scan Microsoft OneDrive et SharePoint
• Cas spécial Slack : Slack a son propre worker dédié pour les scans historiques (worker-scanners-slack) en plus des workers ODS standards
• Isolation des conteneurs : le scan de container registries utilise des workers complètement séparés (worker-container-registries) des autres sources non-VCS
• Isolation des package registries : le scan de package registries nécessite des workers worker-scanners-db-less dédiés et utilise l'instance Redis commit-cache