Intégration Google Secret Manager

GGScout prend en charge l'intégration avec Google Secret Manager pour collecter et surveiller vos secrets. Ce guide vous aide à mettre en place et configurer l'intégration.

Fonctionnalités prises en charge

• Collecte de plusieurs versions de secrets
• Plusieurs méthodes d'authentification (service account, Kubernetes Workload Identity, Application Default Credentials)
• Prise en charge native de l'infrastructure GCP (détection automatique de l'endpoint metadata)
• Collecte de secrets par projet
• Accès basé sur les rôles IAM

Configuration

Pour configurer GGScout afin qu'il fonctionne avec Google Secret Manager, ajoutez la configuration suivante à votre fichier ggscout.toml :

Authentification par fichier de clé Service Account

Utilisez un fichier de clé JSON pour l'authentification :

[sources.gcp]
type = "gcpsecretmanager"
fetch_all_versions = true
projects = ["some-project-id-441517"]
mode = "read"
env = "production"
owner = "devops-team@example.com"

auth.auth_mode = "service_account_key_file"
auth.key_file = ".secure_files/.gcp_key.json"

[[sources.gcp.include]]
resource_ids = ["app-*", "database-*", "api-key"]

[[sources.gcp.exclude]]
resource_ids = ["test-*", "temp-*", "old-secret"]

Application Default Credentials (recommandé pour GCP)

Lorsque vous exécutez ggscout sur l'infrastructure GCP (GCE, GKE, Cloud Run, etc.), utilisez Application Default Credentials pour une authentification automatique :

[sources.gcp]
type = "gcpsecretmanager"
fetch_all_versions = true
projects = ["some-project-id-441517"]
mode = "read"
env = "production"
owner = "devops-team@example.com"

auth.auth_mode = "default"

[[sources.gcp.include]]
resource_ids = ["app-*", "database-*", "api-key"]

[[sources.gcp.exclude]]
resource_ids = ["test-*", "temp-*", "old-secret"]

Exécution sur l'infrastructure GCP

Lorsque vous utilisez auth_mode = "default", ggscout détecte automatiquement son environnement et utilise la méthode d'authentification la plus appropriée :

• Sur GCE/GKE : appelle automatiquement l'endpoint metadata GCP pour récupérer les identifiants
• Avec GOOGLE_APPLICATION_CREDENTIALS : utilise le fichier de clé service account spécifié par la variable d'environnement
• Développement local : se rabat sur les identifiants de gcloud auth application-default login

C'est l'approche recommandée pour les déploiements en production sur l'infrastructure GCP.

Kubernetes Workload Identity Federation

Pour les clusters GKE utilisant Workload Identity :

[sources.gcp]
type = "gcpsecretmanager"
fetch_all_versions = true
projects = ["some-project-id-441517"]
mode = "read"
env = "production"
owner = "devops-team@example.com"

auth.auth_mode = "k8s"
auth.project_id = "my-gcp-project"
auth.project_number = "123456789012"
auth.pool_id = "my-workload-identity-pool"
auth.provider_id = "my-provider"
auth.gcp_service_account_name = "ggscout-sa"
auth.kubernetes_namespace = "ggscout"  # Optional
auth.kubernetes_service_account = "ggscout-k8s-sa"  # Optional

[[sources.gcp.include]]
resource_ids = ["app-*", "database-*", "api-key"]

[[sources.gcp.exclude]]
resource_ids = ["test-*", "temp-*", "old-secret"]

Paramètres de configuration

Paramètre	Description	Requis	Valeur par défaut
type	Doit être défini sur "gcpsecretmanager"	Oui
fetch_all_versions	Indique s'il faut collecter toutes les versions des secrets	Oui
projects	Liste des project IDs GCP depuis lesquels collecter les secrets	Non	Tous les projets accessibles
auth.auth_mode	Méthode d'authentification : « service_account_key_file », « k8s » ou « default »	Non	"default"
mode	Mode d'intégration (parmi : « read », « write », « read/write »)	Non	"read"
env	Libellé d'environnement pour catégoriser les secrets (par ex. « production », « staging », « development »)	Non
owner	Propriétaire de cette source (un e-mail, généralement d'un employé ou d'une équipe)	Non
[[sources.<name>.include]]	Table de motifs de resource_id à inclure (voir ci-dessous)	Non
[[sources.<name>.exclude]]	Table de motifs de resource_id à exclure (voir ci-dessous)	Non

Paramètres d'authentification par fichier de clé Service Account :

Paramètre	Description	Requis	Valeur par défaut
auth.key_file	Chemin vers le fichier de clé JSON du service account	Oui (pour le mode service_account_key_file)

Paramètres Kubernetes Workload Identity Federation :

Paramètre	Description	Requis	Valeur par défaut
auth.project_id	Project ID GCP où se trouve le service account	Oui (pour le mode k8s)
auth.project_number	Project Number GCP	Oui (pour le mode k8s)
auth.pool_id	Workload Identity Pool ID	Oui (pour le mode k8s)
auth.provider_id	Workload Identity Provider ID	Oui (pour le mode k8s)
auth.gcp_service_account_name	Nom du Google Service Account (sans @project.iam.gserviceaccount.com)	Oui (pour le mode k8s)
auth.kubernetes_namespace	Namespace Kubernetes où se trouve le service account	Non
auth.kubernetes_service_account	Nom du service account Kubernetes à utiliser pour l'authentification	Non
auth.audience	Audience personnalisée pour le provider WIF	Non	Format d'URL standard du provider WIF
auth.token_expiration_seconds	Durée d'expiration du token en secondes	Non	1800 (30 minutes)

Authentification

GGScout prend en charge trois méthodes d'authentification pour Google Cloud :

1. Application Default Credentials (recommandé pour GCP)

Le mode d'authentification default infère automatiquement sa configuration en fonction de l'environnement :

• Exécution sur l'infrastructure GCP (GCE, GKE, Cloud Run) : appelle automatiquement l'endpoint metadata GCP pour récupérer les identifiants d'instance ou de workload
• Variable d'environnement GOOGLE_APPLICATION_CREDENTIALS définie : utilise le fichier de clé service account spécifié
• Développement local : se rabat sur les identifiants de gcloud auth application-default login

C'est la méthode la plus sécurisée et pratique lorsque vous exécutez ggscout sur l'infrastructure GCP, car elle élimine le besoin de gérer des fichiers de clé service account.

2. Service Account Key File

Spécifiez explicitement un chemin de fichier de clé JSON pour l'authentification. Cette méthode fonctionne dans tout environnement mais nécessite de gérer et sécuriser le fichier de clé.

3. Kubernetes Workload Identity Federation

Utilisez les tokens de service account Kubernetes avec GCP Workload Identity Federation. C'est la méthode la plus sécurisée pour les déploiements GKE car elle :

• Élimine le besoin de fichiers de clé service account
• Fournit des identifiants à courte durée de vie, automatiquement renouvelés
• Suit les bonnes pratiques de sécurité cloud-native

Prérequis : avant de configurer l'intégration, assurez-vous d'avoir activé l'API Cloud Resource Manager dans votre compte GCP, en plus de l'API Secret Manager.

Variables d'environnement

Pour l'authentification par fichier de clé Service Account :

• GOOGLE_APPLICATION_CREDENTIALS : chemin vers le fichier de clé service account (en mode default)

Pour Application Default Credentials :

• Aucune variable d'environnement requise lors de l'exécution sur l'infrastructure GCP
• GOOGLE_APPLICATION_CREDENTIALS : optionnel, peut être utilisé pour spécifier un fichier de clé

Bonnes pratiques

1. Utilisez Application Default Credentials (auth_mode = "default") lors de l'exécution sur l'infrastructure GCP (GCE, GKE, Cloud Run) pour une authentification automatique et sécurisée sans gérer de fichiers de clé
2. Pour les déploiements GKE : utilisez Kubernetes Workload Identity Federation pour l'authentification la plus sécurisée, sans clé
3. Évitez les fichiers de clé service account en production lorsque c'est possible — utilisez plutôt Application Default Credentials ou Workload Identity
4. Suivez le principe du moindre privilège pour les permissions IAM
5. Activez fetch_all_versions pour suivre les changements dans vos secrets au fil du temps
6. Si vous devez utiliser des fichiers de clé service account, stockez-les en toute sécurité et faites-les tourner régulièrement
7. Utilisez des projets distincts pour chaque environnement
8. Lors d'un déploiement sur GCP, profitez de la détection automatique de l'endpoint metadata pour une authentification transparente

Note :

• Utilisez les tables [[sources.<name>.include]] et [[sources.<name>.exclude]] pour spécifier plusieurs règles d'inclusion/exclusion. Chaque table doit comporter un tableau resource_ids.
• 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.