04 - AWS Secrets Manager et ses alternatives

Ce que tu vas apprendre

• La différence entre AWS Secrets Manager et SSM Parameter Store
• Stocker, lire et faire tourner des secrets avec la CLI AWS
• Comparaison entre GCP, AWS et Azure pour la gestion des secrets

Prerequisites

Un compte AWS. Le CLI AWS installe et configure.

Deux services, deux usages

AWS a deux services pour stocker des secrets. C'est deroutant au début, mais chacun a sa place.

AWS Secrets Manager est le vault manage. Il stocke des secrets, les chiffre avec KMS, gere le versioning, et propose la rotation automatique via Lambda. Il coûte $0.40 par secret par mois, plus $0.05 pour 10 000 appels API.

SSM Parameter Store (Systems Manager Parameter Store) est un key-value store plus generaliste. Il stocke de la configuration et des secrets. La version Standard est gratuite (jusqu'a 10 000 paramètres). Pas de rotation automatique intégrée, mais c'est souvent suffisant.

Mon conseil : utilise Parameter Store pour la configuration non-sensible (URLs, feature flags, noms de bucket) et Secrets Manager pour les vrais secrets (API keys, mots de passe, credentials). Ca évité de payer $0.40/mois pour stocker l'URL de ton API qui n'a rien de secret.

Stocker et lire des secrets

Avec Secrets Manager :

bash# Creer un secret
aws secretsmanager create-secret \
  --name "paltemps/ANTHROPIC_KEY" \
  --secret-string "sk-ant-api03-xxxx" \
  --description "Cle API Anthropic pour paltemps.fr"

# Lire
aws secretsmanager get-secret-value \
  --secret-id "paltemps/ANTHROPIC_KEY" \
  --query SecretString \
  --output text

Avec SSM Parameter Store :

bash# Creer (SecureString = chiffre avec KMS)
aws ssm put-parameter \
  --name "/paltemps/SMTP_HOST" \
  --value "smtp.paltemps.fr" \
  --type String

aws ssm put-parameter \
  --name "/paltemps/SMTP_PASS" \
  --value "monmotdepasse" \
  --type SecureString

# Lire
aws ssm get-parameter \
  --name "/paltemps/SMTP_PASS" \
  --with-decryption \
  --query Parameter.Value \
  --output text

La convention /app/env/secret est une bonne pratique. Ca permet de filtrer par prefixe et de donner des droits IAM par chemin :

bash# Lire tous les parametres de paltemps
aws ssm get-parameters-by-path \
  --path "/paltemps/" \
  --with-decryption \
  --query "Parameters[*].{Name:Name,Value:Value}"

Acces depuis du code TypeScript

bashbun add @aws-sdk/client-secrets-manager

typescriptimport { SecretsManagerClient, GetSecretValueCommand } from "@aws-sdk/client-secrets-manager";

const client = new SecretsManagerClient({ region: "eu-west-3" });

async function getSecret(name: string): Promise<string> {
  const command = new GetSecretValueCommand({ SecretId: name });
  const response = await client.send(command);

  if (!response.SecretString) {
    throw new Error(`Secret ${name} has no string value`);
  }
  return response.SecretString;
}

// Usage
const anthropicKey = await getSecret("paltemps/ANTHROPIC_KEY");

L'authentification passe par les credentials AWS standards : variables d'environnement AWS_ACCESS_KEY_ID et AWS_SECRET_ACCESS_KEY, fichier ~/.aws/credentials, ou rôle IAM attache a l'instance EC2 / au conteneur ECS.

Rotation automatique avec Lambda

La rotation automatique est le gros avantage de Secrets Manager par rapport a Parameter Store. Le principe : tu attaches une fonction Lambda a un secret, et AWS l'exécuté selon un planning pour générer une nouvelle valeur.

bash# Activer la rotation (rotation tous les 30 jours)
aws secretsmanager rotate-secret \
  --secret-id "paltemps/DB_PASSWORD" \
  --rotation-lambda-arn "arn:aws:lambda:eu-west-3:123456:function:rotate-db-password" \
  --rotation-rules '{"AutomaticallyAfterDays": 30}'

La Lambda doit implementer 4 étapes : createSecret, setSecret, testSecret, finishSecret. AWS fournit des templates pour les cas courants (RDS, Redshift, DocumentDB).

Pour les clés API externes (Anthropic, OpenAI), la rotation automatique est plus compliquee parce que ca implique d'appeler l'API du fournisseur pour régénérer la clé. En pratique, on fait souvent la rotation manuellement pour ces cas-la. L'article sur la rotation donne une méthode.

IAM : contrôle d'acces

Le contrôle fin passe par les politiques IAM. Tu peux restreindre un rôle a un seul secret :

json{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "secretsmanager:GetSecretValue",
      "Resource": "arn:aws:secretsmanager:eu-west-3:123456:secret:paltemps/ANTHROPIC_KEY-*"
    }
  ]
}

Meme logique qu'on a vue avec Google IAM dans l'article précédent. Le principe est le meme : un service ne voit que les secrets dont il a besoin.

Comparaison des vaults cloud

Pour un projet hébergé hors cloud (VPS OVH, Hetzner, Scaleway), aucune de ces solutions n'est un choix naturel. Tu dois quand meme créer un compte cloud, gerer un service account, et accepter une dépendance réseau. Si ton VPS ne peut pas joindre l'API GCP ou AWS, ton application ne démarré pas.

C'est pour ca que pour paltemps.fr, qui tourne sur un VPS OVH, je reste sur des variables CI/CD GitLab et du chiffrement SOPS. Pas de dépendance cloud, pas de latence réseau supplementaire au démarrage.

Quand choisir AWS Secrets Manager

Si ton infrastructure est deja sur AWS (EC2, ECS, Lambda), c'est le choix logique. L'intégration IAM est native, la rotation avec Lambda fonctionne bien pour les bases de donnees, et CloudTrail te donne l'audit trail automatiquement.

Si tu n'es pas sur AWS et que tu n'as pas l'intention d'y aller, passe ton chemin. Le prochain article couvre HashiCorp Vault, la solution self-hosted qui ne depend d'aucun cloud.

Navigation : Precedent : 03 - Google Secret Manager | Suivant : 05 - HashiCorp Vault

Sources

• AWS Secrets Manager documentation par AWS
• AWS Systems Manager Parameter Store par AWS
• Rotating AWS Secrets Manager secrets par AWS
• AWS Secrets Manager pricing par AWS

Retrouve d'autres articles techniques sur paltemps.fr.