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è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ù sont stockés les secrets | Non | |
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 |
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 tableauresource_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.
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 :
-
Variables d'environnement :
AWS_ACCESS_KEY_IDAWS_SECRET_ACCESS_KEYAWS_SESSION_TOKEN(en cas d'identifiants temporaires)
-
Fichiers d'identifiants AWS :
~/.aws/credentials~/.aws/config
-
Rôles IAM pour Amazon EC2 ou tâches ECS
-
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 IDAWS_SECRET_ACCESS_KEY: votre AWS secret access keyAWS_SESSION_TOKEN: votre AWS session token (en cas d'identifiants temporaires)AWS_REGION: la région AWS où sont stockés vos secrets
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
- Utilisez des rôles IAM ou des instance profiles lors d'une exécution sur l'infrastructure AWS
- Suivez le principe du moindre privilège pour les permissions IAM
- Activez
fetch_all_versionspour suivre les changements dans vos secrets au fil du temps - Faites tourner régulièrement les access keys
- Utilisez des comptes AWS ou des régions distincts pour chaque environnement