Sources non-VCS

Cette section décrit 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, les outils de documentation, les systèmes de tickets et les registres de conteneurs à la recherche de secrets.

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

Compatibilité des workers :

• Peuvent utiliser les workers VCS par défaut (mais des workers dédiés sont recommandés) : Slack, Microsoft Teams, Confluence, Jira et ServiceNow peuvent éventuellement 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, registres de conteneurs, registres de paquets) 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 files d'attente et de 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 et événements en temps réel
• worker-scanners-ods - Gère les scans historiques pour les plateformes de messagerie
• worker-scanners-slack - Worker dédié aux scans historiques Slack uniquement
• worker-long-ods - Traite les tâches de longue durée pour les plateformes de messagerie
• worker-long-ods-io - Gère les tâches de longue durée intensives en I/O

Intégrations de documentation

Scannez les plateformes de documentation et les services de stockage de fichiers à la recherche de secrets divulgués.

Sources disponibles :

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

Workers requis :

• worker-realtime-ods - Traite les scans et événements en temps réel
• 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 de longue durée pour les plateformes de documentation
• worker-long-ods-io - Gère les tâches de longue durée intensives en I/O
• apache-tika - Requis lors du scan de Microsoft OneDrive et SharePoint pour les formats de documents Office

Intégrations de tickets

Surveillez les systèmes de tickets 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 et événements en temps réel
• worker-scanners-ods - Gère les scans historiques pour les plateformes de tickets
• worker-long-ods - Traite les tâches de longue durée pour les plateformes de tickets
• worker-long-ods-io - Gère les tâches de longue durée intensives en I/O

Intégrations de registres de conteneurs

Scannez les images et registres de conteneurs à la recherche de secrets intégré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 des registres de conteneurs

Intégrations de registres de paquets

Scannez les artefacts des registres de paquets à la recherche de secrets à travers plusieurs écosystèmes de paquets.

Sources disponibles :

• JFrog Package Registries

Workers requis :

• worker-scanners-db-less - Worker dédié aux tâches de scan des registres de paquets

info

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

Configuration système requise

Workers standards

Chaque type de worker standard requiert : 0.5 vCPU et 2 Gio de RAM par replica

Pod file scanner

Pour le scan de fichiers binaires (OneDrive/SharePoint) : 0.5 vCPU et 500 Mio de RAM par replica

Workers à fort disque

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

Configuration

Installation basée sur KOTS

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

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

2. Naviguez vers 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 replicas pour les workers requis (passez de 0 à 1 ou plus)

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

6. Enregistrez la configuration

Installation basée sur Helm

info

Pour les environnements air-gapped, les noms des images requises pour le file scanner sont disponibles dans la documentation d'installation air-gap.

Pour les installations basées sur Helm, consultez la documentation des valeurs Helm pour les options de configuration détaillées. Configurez les replicas 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 tickets :

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

Exemple de configuration pour les registres de conteneurs :

celeryWorkers:
  container-registries:
    replicas: 1

Exemple de configuration pour les registres de paquets :

celeryWorkers:
  scanners-db-less:
    replicas: 1

Scaling

Après avoir activé les intégrations de base, référez-vous à la documentation Scaling pour des informations détaillées sur :

• La configuration des paramètres de scaling en fonction de votre charge de travail
• La surveillance des performances des workers
• L'optimisation de l'allocation des ressources
• La gestion d'un débit accru

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

Notes

• Isolation des files d'attente : l'utilisation de workers dédiés empêche les sources non-VCS d'interférer avec les performances du 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 disque : le worker-scanners-ods-highdisk est spécifiquement conçu pour les tâches nécessitant un stockage important, principalement le scan de Microsoft OneDrive et SharePoint
• Cas particulier de Slack : Slack dispose de son propre worker de scan historique dédié (worker-scanners-slack) en plus des workers ODS standards
• Isolation des conteneurs : le scan des registres de conteneurs utilise des workers complètement séparés (worker-container-registries) des autres sources non-VCS
• Isolation des registres de paquets : le scan des registres de paquets nécessite des workers worker-scanners-db-less dédiés et utilise l'instance Redis commit-cache