Aller au contenu principal

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 aide à 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ètreDescriptionRequisValeur par défaut
typeDoit être défini sur "awssecretsmanager"Oui
fetch_all_versionsIndique s'il faut collecter toutes les versions des secretsOui
profile_nameNom du profil AWS à utiliserNon
regionsRégions AWS où sont stockés les secretsNon
modeMode d'intégration (parmi : « read », « write », « read/write »)Non"read"
envLibellé d'environnement pour catégoriser les secrets (par ex. « production », « staging », « development »)Non
ownerProprié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

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.

Authentification

GGScout utilise le client AWS Rust 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 ne permet de spécifier que le paramètre profile_name.

remarque

Les méthodes d'authentification ne peuvent pas être configurées directement dans le fichier TOML. 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 AWS Rust tente de charger les identifiants dans l'ordre suivant :

  1. Variables d'environnement :

    • AWS_ACCESS_KEY_ID
    • AWS_SECRET_ACCESS_KEY
    • AWS_SESSION_TOKEN (en cas d'identifiants temporaires)
  2. Fichiers d'identifiants AWS :

    • ~/.aws/credentials
    • ~/.aws/config
  3. Rôles IAM pour Amazon EC2 ou tâches 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 AWS access key ID
  • AWS_SECRET_ACCESS_KEY : votre AWS secret access key
  • AWS_SESSION_TOKEN : votre AWS session token (en cas d'identifiants temporaires)
  • AWS_REGION : la région AWS où sont stockés vos secrets
astuce

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

Permissions AWS requises

Pour récupérer des 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 instance profiles lors d'une 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 changements dans vos secrets au fil du temps
  4. Faites tourner régulièrement les access keys
  5. Utilisez des comptes AWS ou des régions distincts pour chaque environnement