I am curious to understand how others manage their secret and sensitive info in conjunction with Terraform.
Most of my use-cases with terraform are provisioning Infra (Usually AWS) and then Application resources that depend on the infra.
Examples of Secrets:
- single-line strings
- multi-line strings
- ascii-armored pem files
- ascii license data
- binary license data
I’ll explain the requirements I’m trying to fulfill and then currently how I achieve the success criteria.
- Audit-able - As secrets change, the ability to identify that, who did it, when, and what the previous and changed values are are a critical requirement.
- Shareable - Multiple TF operators need to be able to access the secret data.
- Secure - Only TF operators and TF should be able to see the data.
- Orchestrated - Multiple-TF Operators should not have to guess if the data they have is up to date. It should be apparent at plan-time at minimum.
- Reference-able - Values should be securely reference-able within TF to provide to resources.
- Avoid OutOfBand - Unless absolutely necessary, avoid using multiple processes that are unaware of eachother. E.g. boostrapping done by System-A and a requirement for System-B.
- Secure - I use ansible-vault to secure a yaml formatted secrets (from here, known as secret-yaml) file with a symmetric passphrase (stored in a file)
- Audit-able - I include the secret-yaml in the SCM project with the terraform-code and the passphrase-file is .git-ignored. I also consider setting up precommit hooks to confirm the secret-yaml is encrypted.
- This provides insight into who, what when and if sufficient commit messages provided, why.
- Shareable - Since the secret-yaml is in SCM, its accessible to other TF Operators.
- Reference-able - I create an external datasource using a python script to decrypt and parse the secret data. Its then available as datasource result value.
- Orchestrated - Since the data is in the tfstate and part of datasources being referenced, the plan changes when the data changes. If operator sees an unexpected change, they can confirm they’re on head of proper branch or check with other operators to see if they have un-merged changes. But if all standard process is followed, no guessing is required to identify if you have latest data.
- The state isn’t encrypted except through S3 backend KMS. Its a single point of failure so if that key is breached, all secret-data is exposed.
- Initial creation of symmetric passphrase file is small but out of band and must remember to gitignore.
- feel free to add more here. Looking to improve the process while maintaining the requirements.