Configurer les intégrations

ggscout s'intègre à divers gestionnaires de secrets, systèmes CI/CD et composants d'infrastructure pour collecter et surveiller les secrets. Cette page explique comment configurer et utiliser les intégrations pour la découverte et la surveillance des secrets.

Modes d'intégration

Les sources peuvent être configurées avec différents modes opérationnels :

• read - Collecte uniquement les données de la source (par défaut)
• write - Écrit uniquement les données vers la source
• read/write - Collecte les données et écrit vers la source

[sources.my-source]
type = "source_type"
mode = "read/write"  # Supports both operations

Fichier de configuration

Le fichier de configuration de ggscout utilise le format TOML pour décrire :

• Comment ggscout communiquera avec la plateforme GitGuardian
• Comment accéder aux différents gestionnaires de secrets pour collecter les secrets

Exemple de configuration :

[gitguardian]
# SaaS US
endpoint = "https://api.gitguardian.com/v1"
# SaaS EU
# endpoint = "https://api.eu1.gitguardian.com/v1"
# Self-hosted
# endpoint = "https://my-gg-instance.com/exposed/v1"
api_token = "${GITGUARDIAN_API_KEY}"

[sources.my-hashicorp-vault]
# This lets ggscout know what source to contact
type = "hashicorpvault"
# And this lets ggscout know how to contact it
vault_address = "${HASHICORP_VAULT_ADDRESS}"
auth.auth_mode = "token"
auth.token = "${HASHICORP_VAULT_TOKEN}"

# Many vaults support secret versioning. Set this to false if you only
# want to collect the latest version of the vault secrets
fetch_all_versions = true
# Allow ggscout instance to read from and write to that vault
mode = "read/write" # "read" and "write" are other possible values
# Will help assess policy breaches and their severity
env = "staging"
# Optional: specify the owner of this source
owner = "devops-team@example.com"

# Configure another vault to collect here
# [sources.my-other-vault]
# type = "gcpsecretmanager"

Le fichier de configuration prend en charge la lecture des variables d'environnement ("${GITGUARDIAN_API_KEY}") à la place des valeurs brutes.
Vous pouvez définir ces variables dans un fichier .env :

GITGUARDIAN_API_KEY=<your-gitguardian-api-key>

HASHICORP_VAULT_ADDRESS=<your-vault-url>
HASHICORP_VAULT_TOKEN=<your-vault-token>

Veuillez vous référer à la section Secrets Managers pour configurer correctement la collecte des secrets.

Types d'intégration pris en charge

ggscout prend en charge plusieurs types d'intégration dans différentes catégories. Le tableau ci-dessous présente toutes les intégrations disponibles et leurs capacités :

Type d'intégration	Nom de l'intégration	Identifiant de type	Prise en charge de l'écriture
Secrets Managers	HashiCorp Vault	hashicorpvault	✅ Oui
	AWS Secrets Manager	awssecretsmanager	✅ Oui
	CyberArk Secrets Manager SaaS	cyberarksaas	✅ Oui
	CyberArk Secrets Manager Self-Hosted	cyberarkselfhosted	✅ Oui
	Akeyless	akeyless	✅ Oui
	Delinea Secret Server	delineasecretserver	✅ Oui
	Azure Key Vault	azurekeyvault	❌ Non
	Google Secret Manager	gcpsecretmanager	❌ Non
CI/CD Systems	GitLab CI	gitlabci	❌ Non
Infrastructure	Kubernetes	k8s	❌ Non

info

Les intégrations qui ne prennent pas en charge l'écriture peuvent tout de même être utilisées pour la découverte et la surveillance des secrets avec la commande fetch-and-send. Seules les intégrations prenant en charge l'écriture peuvent être utilisées avec la commande sync-secrets.

Référez-vous à la section Synchronisation des secrets pour plus de détails sur sync-secrets.

Paramètres de configuration communs

Toutes les intégrations de gestionnaires de secrets prennent en charge les paramètres communs suivants en plus de leur configuration spécifique :

Catégorisation de l'environnement

• env : Environnement par défaut pour les secrets de cette source : production, pre-production, staging, testing ou development. ggscout accepte également les alias prod et prd, pre-prod, preprod et preproduction, ainsi que dev et local, et envoie le nom complet. Toute autre valeur est rejetée. GitGuardian le remplace par secret lorsque le chemin du secret, les tags ou les labels nomment un environnement, et utilise cette valeur par défaut sinon. Consultez comment les environnements sont déduits.

Propriété de la source

• owner : Propriétaire de cette source (un e-mail, généralement celui d'un employé ou d'une équipe). Ce champ est facultatif et aide à identifier qui est responsable de la gestion de la source.

Filtrage des ressources

• [[sources.<name>.include]] : Table de motifs resource_id à inclure. Seuls les secrets correspondant à ces motifs seront collectés.
• [[sources.<name>.exclude]] : Table de motifs resource_id à exclure. Les secrets correspondant à ces motifs seront ignorés.

Chaque table include ou exclude doit comporter un tableau resource_ids. Vous pouvez spécifier plusieurs tables include ou exclude pour différents ensembles de motifs.

Les motifs prennent en charge les caractères génériques (*) uniquement à la fin pour la correspondance de préfixe. Pour des correspondances exactes, spécifiez le nom complet sans caractères génériques.

Exemple de configuration

[sources.my-vault]
type = "hashicorpvault"
vault_address = "${HASHICORP_VAULT_ADDRESS}"
fetch_all_versions = true
mode = "read"
env = "production"
owner = "devops-team@example.com"

[[sources.my-vault.include]]
resource_ids = ["app/*", "database/*", "api-key"]

[[sources.my-vault.exclude]]
resource_ids = ["test/*", "temp/*", "old-secret"]

auth.auth_mode = "token"
auth.token = "${HASHICORP_VAULT_TOKEN}"

Dans cet exemple :

• Motifs de préfixe : "app/*" et "database/*" correspondent à tous les secrets commençant par ces préfixes
• Correspondances exactes : "api-key" correspond uniquement au secret exact portant ce nom