Comment puis-je gérer des secrets dans .tf et .tfstate?

Je voudrais utiliser le fournisseur MySQL de Terraform pour conserver une liste des utilisateurs de mysql et des autorisations utiles pour la création de nouveaux environnements de test. Les fichiers .tfet les .tfstatedeux semblent vouloir stocker les mots de passe MySQL en texte clair.

En ce qui concerne .tf:

Si j'ai bien compris, les .tffichiers sont contrôlés par les révisions et gérés par une équipe. En quoi cette pratique diffère-t-elle lorsque des secrets sont dans la .tf? Il est possible de chiffrer ces valeurs du tout?

En ce qui concerne .tfstate:

Je peux stocker le .tfstatefichier quelque part en toute sécurité après l’application de Terraform, mais il serait préférable que ce cas d’utilisation ne le stocke pas du tout.

Terraform prend en charge l' ajout d'un fichier supplémentaire avec des variables lors de l'appel.

^{documentation: https://www.terraform.io/intro/getting-started/variables.html#from-a-file}

Nous utilisons cette fonctionnalité pour fournir un secrets.tfvarsfichier à chaque appel de Terraform. Nous utilisons également un script pour encapsuler la commande afin que son invocation soit cohérente et que tous les membres de l'équipe évitent de devoir faire les mêmes erreurs. Le wrapper se synchronise .tfstateavec S3 avant une exécution et .tfstaterevient à S3 à la fin. J'entends aussi parler de gens qui font la même chose avec state stocké dans Consul, ajoutant même une sorte de sémaphore dans consul pour empêcher deux personnes de démarrer Terraform en même temps.

Lorsque vous évitez de définir une valeur par défaut dans un variables.tffichier, l'utilisateur est obligé de saisir cette valeur. Il peut être saisi manuellement ou à l'aide de l' -var-fileoption de commande décrite ci-dessus. Ne pas définir une valeur par défaut sur vos secrets est un bon moyen d'appliquer des modifications qui nécessitent une modification des secrets.

Le secrets.tfvarsfichier est un lien symbolique vers l'un des fichiers contenant des secrets qui ne sont pas stockés dans le contrôle de version. Nous avons plusieurs, l' un par l' environnement, comme si secrets-prod.tfvars, secrets-dev.tfvars, secrets-stg.tfvars, etc ...

Une pratique encore meilleure serait de générer ces fichiers secrets lors du script d'encapsidation en fonction des données de Vault ou d'une autre manière de partager des secrets. Depuis le moment où le format des secrets change, ou les secrets eux-mêmes, nous devons le communiquer à l'équipe en dehors du canal de contrôle de version - et cela ne fonctionne pas toujours bien, pour être honnête. Mais les secrets changent rarement.

Nous évitons terraform gérer nos secrets. Même si vous parvenez à injecter des secrets via un fichier var "secrtes.tfvars" comme indiqué ci-dessus, ces secrets seront stockés dans votre état terraform (remote-).

Vous pouvez protéger des fichiers d'état distants en utilisant, par exemple, une autorisation S3, ou vous pouvez créer des fichiers d'état locaux, mais nous avons décidé de ne pas compter sur ce type de protection.

Si vous êtes sur AWS, consultez «Le bon moyen de gérer les secrets» par Segment.io sur le blog AWS. Nous recommandons chamberà tous nos clients de gérer leurs secrets. Il fonctionne en exploitant le SSM (AWS Systems Manager Parameter Store) avec les clés KMS. Cela garantit que les secrets sont cryptés au repos (et en transit), sécurisés avec IAM, contrôlables avec CloudTrails et exposés uniquement en tant que variables d'environnement au moment de l'exécution.

Après avoir configuré la chambre et la clé KMS, nous écrivons les secrets dans le magasin de paramètres.

chamber write db TF_VAR_DB_USER foobar
chamber write db TF_VAR_DB_PASS secret

Ensuite, utilisez ces secrets lorsque vous appelez terraform.

chamber exec db -- terraform plan

Cela suppose que vous avez défini une variable appelée DB_USERet DB_PASSdans votre code HCL.

Par exemple, vous pouvez ajouter ceci à variables.tf

variable "DB_USER" { }
variable "DB_PASS" { }

REMARQUE: chamber exportera toujours les variables d’environnement en majuscules

Nous fournissons un module terraform appelé terraform-aws-kms-keypour faciliter le provisioning de la clé KMS. Consultez notre documentation détaillée avec des exemples d'utilisation chamberde plusieurs espaces de noms ainsi que de l'utilisation de chamber avec terraform pour gérer les secrets. Voir notre exemple de référence complet pour les dépendances de la chambre d'approvisionnement.

En ce qui concerne .tfstate, vous soulevez un très bon point sur l'existence de secrets en texte brut dans le fichier d'état. Il n'y a vraiment aucun moyen de contourner cela. Pour que terraform calcule les modifications nécessaires à la création d'un plan, il doit connaître l'état "avant" et "après". Pour cette raison, nous vous recommandons d'utiliser un compartiment S3 crypté avec la gestion des versions obligatoire. Utilisez le terraform-aws-tfstate-backendmodule pour provisionner un compartiment et une table de verrouillage DynamoDB conformément aux meilleures pratiques.

Pour importer des secrets dans des fichiers .tf, vous pouvez également utiliser une source de données externe . Cela pourrait être par exemple un script qui déchiffre vos secrets.

J'ai examiné différentes manières, mais j'ai particulièrement aimé git-crypt pour une tâche ad hoc avant de mettre en œuvre quelque chose de plus grand, comme Vault.