Configurer les intégrations

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

Modes d'intégration

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

• read — collecte uniquement les données depuis la source (par défaut)
• write — écrit uniquement des données vers la source
• read/write — collecte et écrit les données 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 communique avec la plateforme GitGuardian
• Comment accéder aux différents Secrets Managers 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 de variables d'environnement ("${GITGUARDIAN_API_KEY}") à la place de valeurs en clair.
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>

Référez-vous à la section Secrets Managers pour configurer correctement la collecte des secrets.

Types d'intégrations pris en charge

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

Type d'intégration	Nom de l'intégration	Identifiant de type	Écriture prise en charge
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
Systèmes CI/CD	GitLab CI	gitlabci	❌ Non
Infrastructure	Kubernetes	k8s	❌ Non

info

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

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

Paramètres de configuration communs

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

Catégorisation d'environnement

• env : libellé d'environnement pour catégoriser les secrets (par ex. « production », « staging », « development »). Cela aide à organiser et filtrer les secrets par environnement cible.

Propriété de la source

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

Filtrage des ressources

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

Chaque table include ou exclude doit avoir un tableau resource_ids. Vous pouvez préciser plusieurs tables include ou exclude pour différents ensembles de motifs.

Les motifs prennent en charge les wildcards (*) uniquement à la fin pour la correspondance par préfixe. Pour des correspondances exactes, indiquez le nom complet sans wildcards.

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 préfixés : "app/*" et "database/*" correspondent à tous les secrets commençant par ces préfixes
• Correspondances exactes : "api-key" ne correspond qu'au secret portant exactement ce nom