如何管理.tf和.tfstate中的机密？

我想使用Terraform MySQL Provider保留mysql用户列表，并为创建新的测试环境提供方便。在.tf和.tfstate文件都似乎想要MySQL的存储密码明文。

关于.tf：

据我了解，.tf文件位于版本控制中，并由团队维护。秘密存在时，这种做法.tf有何不同？可以对这些值进行加密吗？

关于.tfstate：

我可以.tfstate在运行Terraform apply之后将其安全地存储在某个地方，但是对于这种用例，最好根本不存储它？

Terraform 支持在调用期间添加带有变量的附加文件。

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

我们正在使用该功能secrets.tfvars在每次Terraform调用时提供一个文件。我们还使用脚本来包装命令，以便其调用是一致的，并且所有团队成员都避免犯相同的错误。包装程序.tfstate在执行之前与S3 同步，并.tfstate在最后返回到S3。我还听说有人使用领事馆中存储的状态执行相同的操作，甚至在领事馆中添加了一种信号量以防止两个人同时启动Terraform。

当您避免在variables.tf文件中设置默认值时，它将强制用户输入该值。可以手动输入，也可以使用上述-var-file命令选项输入。不对您的机密设置默认值是执行需要更改机密的更改的好方法。

该secrets.tfvars文件是指向其中一个未存储在版本控制中的机密文件的符号链接。我们有几个，每一个环境，像这样secrets-prod.tfvars，secrets-dev.tfvars，secrets-stg.tfvars，等...

更好的做法是根据Vault中的数据或其他共享机密的方式在包装脚本期间生成这些机密文件。由于当前机密信息的格式更改或机密信息本身，我们需要在版本控制渠道之外将其传达给团队-坦白说，这并不总是很好。但是秘密很少改变。

我们避免使用Terraform处理我们的秘密。即使您设法通过上面指出的var文件“ secrtes.tfvars”注入机密，这些机密也会存储在terraform（远程）状态中。

您可以使用例如S3授权来保护远程状态文件，也可以使用gitignore本地状态文件，但是我们决定不依赖这种保护。

若你在AWS上，再看看“正确的方式来管理的秘密”由Segment.io在AWS博客。我们提倡使用chamber所有客户来管理机密。通过结合使用AWS Systems Manager参数存储（SSM）和KMS密钥来工作。这样可确保机密信息在静止（和传输）过程中被加密，由IAM保护，可通过CloudTrails进行审核，并且仅在运行时作为环境变量公开。

经过配置室和设置KMS密钥，我们写的秘密参数存储。

chamber write db TF_VAR_DB_USER foobar
chamber write db TF_VAR_DB_PASS secret

然后在调用terraform时使用这些秘密。

chamber exec db -- terraform plan

假设您已经在HCL代码中定义了一个名为DB_USER和的变量DB_PASS。

例如，您可以将其添加到 variables.tf

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

注意： chamber将始终以大写形式导出环境变量

我们提供了一个terraform模块，称为terraform-aws-kms-key，它使配置KMS密钥变得容易。请查看我们的详细文档，并提供有关如何chamber与多个名称空间一起使用以及如何使用带有Terraform的Chamber来管理机密的示例。请参阅我们完整的参考示例以了解供应室相关性。

至于.tfstate，您会提出关于状态文件中存在纯文本机密的真正要点。真的没有办法解决这个问题。为了让terraform计算更改以构建计划，它需要知道“之前”和“之后”状态。因此，我们建议使用带有强制版本控制的加密S3存储桶。terraform-aws-tfstate-backend根据最佳实践，使用该模块配置存储桶和DynamoDB锁定表。

要将机密信息导入.tf文件，您还可以使用外部数据源。例如，这可能是一个解密您的机密的脚本。

我研究了几种不同的方法，但是在实现像Vault这样的更大的东西之前，我特别喜欢git-crypt做一个临时的事情。