Intégration AWS Secrets Manager

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

Configuration

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

[sources.aws-source-playground]
type = "awssecretsmanager"
fetch_all_versions = true
profile_name = "default"
regions = ["us-east-1"]
mode = "read"
env = "production"
owner = "devops-team@example.com"

[[sources.aws-source-playground.include]]
resource_ids = ["app/*", "database/*", "api-key"]

[[sources.aws-source-playground.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 "awssecretsmanager"	Oui
fetch_all_versions	Indique s'il faut collecter toutes les versions des secrets	Oui
profile_name	Nom du profil AWS à utiliser	Non
regions	Régions AWS où les secrets sont stockés	Non
mode	Mode d'intégration (l'un de : "read", "write", "read/write")	Non	"read"
env	Environnement par défaut des secrets de cette source. GitGuardian infère un environnement par secret et se rabat sur cette valeur	Non
owner	Propriétaire de cette source (un e-mail, généralement celui 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

Remarque :

• 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 caractères génériques (*) uniquement à la fin, pour une correspondance par préfixe. Pour des correspondances exactes, spécifiez le nom complet sans caractères génériques.
• GitGuardian infère l'environnement de chaque secret d'abord à partir de son chemin de nom (par exemple app/prod/db-password), puis à partir de ses tags de ressource tels que env ou environment, et n'utilise le env au niveau de la source que lorsque aucun des deux ne le renseigne.

Authentification

GGScout utilise le client Rust AWS pour l'authentification, qui suit le processus standard de résolution des identifiants AWS. L'authentification est gérée automatiquement par le SDK AWS, et le fichier de configuration TOML permet uniquement de spécifier le paramètre profile_name.

remarque

Les méthodes d'authentification ne peuvent pas être configurées directement dans le fichier TOML. À la place, vous devez fournir les identifiants AWS nécessaires via des variables d'environnement ou des fichiers d'identifiants AWS.

Résolution des identifiants AWS

Le client Rust AWS tentera de charger les identifiants dans l'ordre suivant :

1. Variables d'environnement :

   • AWS_ACCESS_KEY_ID
   • AWS_SECRET_ACCESS_KEY
   • AWS_SESSION_TOKEN (si vous utilisez des identifiants temporaires)

2. Fichiers d'identifiants AWS :

   • ~/.aws/credentials
   • ~/.aws/config

3. Rôles IAM pour les tâches Amazon EC2 ou ECS

4. Fédération d'utilisateurs IAM

Variables d'environnement

Pour une authentification directe, vous devez définir les variables d'environnement suivantes :

• AWS_ACCESS_KEY_ID : votre ID de clé d'accès AWS
• AWS_SECRET_ACCESS_KEY : votre clé d'accès secrète AWS
• AWS_SESSION_TOKEN : votre token de session AWS (si vous utilisez des identifiants temporaires)
• AWS_REGION : la région AWS où vos secrets sont stockés

astuce

Pour les environnements de production, il est recommandé d'utiliser des rôles IAM ou des profils d'instance plutôt que de coder en dur les identifiants dans les variables d'environnement.

Permissions AWS requises

Pour récupérer les secrets depuis AWS Secrets Manager, l'identité utilisée par GGScout doit disposer des permissions IAM appropriées. Les permissions minimales requises sont :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "secretsmanager:GetSecretValue",
        "secretsmanager:BatchGetSecretValue",
        "secretsmanager:DescribeSecret",
        "secretsmanager:ListSecretVersionIds"
      ],
      "Resource": "arn:aws:secretsmanager:*:*:secret:*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "secretsmanager:ListSecrets"
      ],
      "Resource": "*"
    }
  ]
}

Comme indiqué dans la documentation AWS, il n'est pas possible de restreindre les permissions "secretsmanager:ListSecrets" à un sous-ensemble de secrets.

Bonnes pratiques

1. Utilisez des rôles IAM ou des profils d'instance lors de l'exécution sur l'infrastructure AWS
2. Suivez le principe du moindre privilège pour les permissions IAM
3. Activez fetch_all_versions pour suivre les modifications de vos secrets au fil du temps
4. Effectuez une rotation régulière des clés d'accès
5. Utilisez des comptes ou des régions AWS distincts pour les différents environnements