Answers: <p>The solution is to do it right:</p>
  
  <ul>
  <li><p><strong>Do not</strong> check them into source control.</p></li>
  <li><p><strong>Do</strong> use remote state.</p></li>
  <li><p><strong>Do not</strong> allow user access to production remote state.</p></li>
  <li><p><strong>Do</strong> enforce continuous deployment for production.</p></li>
  </ul>
  
Answers: CC BY-SA 4.0
Answers: 2020-03-18T12:18:20.607Z
Answers: 2020-03-18T20:09:26.493Z
Answers: 2020-03-18T20:09:26.493Z
Answers: Mikael Dúi Bolinder
Answers: <p>Do not store your state in anything besides remote backend. Even if you store it in a remote backend the secrets will appear in a plain text again, this is an ongoing Terraform limitation. </p>
  
  <p>In our case we are using AWS S3 backend ( although we have multi cloud environments ), we've got those key benefits out of the box:</p>
  
  <ul>
  <li>Encryption in transit and at rest.</li>
  <li>Access policy configuration.</li>
  <li>Durability and availability close to the maximum.</li>
  <li>Locking capability.</li>
  <li>Versioning.</li>
  </ul>
  
  <p>Please do not go with <code>locally-maintained repos that are redundant as possible</code>.</p>
  
Answers: CC BY-SA 4.0
Answers: 2020-03-17T21:17:32.677Z
Answers: 2020-03-17T21:17:32.677Z
Answers: Recoba20
Body: <p>Part of my IaC that describes my systems for Azure is CosmosDB, and Keyvaults.  Terraform happily created everything and I was able to use an output from CosmosDB (db keys) as an input to the Keyvault (as a keyvault secret) so my db key was safely stored.</p>
  
  <p>Then I poked through my terraform.tfstate and sure enough, ALL the cosmosdb keys (pri and sec, rw and ro) keys are in there plaintext, as is the plaintext of the vaults secrets.</p>
  
  <p>So this leaves somewhat of a quandry here  - These state files are apparently integral and they must be maintained (as far as I can tell) but I really dont like the idea of checking them into any repo.  I guess theres no real good solution here other than locally-maintained repos that are redundant as possible?</p>
  
Tags: <terraform><secret-management>
Title: Terraform's local state (the 2 tfstate files) contain very sensitive info
UserDisplayName: Optical Carrier
ThreadText: # Terraform's local state (the 2 tfstate files) contain very sensitive info
  
  (Asked by: username_0 on 2020-03-17)
  
  Part of my IaC that describes my systems for Azure is CosmosDB, and Keyvaults. Terraform happily created everything and I was able to use an output from CosmosDB (db keys) as an input to the Keyvault (as a keyvault secret) so my db key was safely stored.
  
  Then I poked through my terraform.tfstate and sure enough, ALL the cosmosdb keys (pri and sec, rw and ro) keys are in there plaintext, as is the plaintext of the vaults secrets.
  
  So this leaves somewhat of a quandry here - These state files are apparently integral and they must be maintained (as far as I can tell) but I really dont like the idea of checking them into any repo. I guess theres no real good solution here other than locally-maintained repos that are redundant as possible?
  
  **Tags:** terraform, secret-management
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_2 on 2020-03-17. Score: 3 | Accepted answer
  
  Do not store your state in anything besides remote backend. Even if you store it in a remote backend the secrets will appear in a plain text again, this is an ongoing Terraform limitation.
  
  In our case we are using AWS S3 backend ( although we have multi cloud environments ), we've got those key benefits out of the box:
  
  * Encryption in transit and at rest.
  * Access policy configuration.
  * Durability and availability close to the maximum.
  * Locking capability.
  * Versioning.
  
  Please do not go with `locally-maintained repos that are redundant as possible`.
  
  
  ---
  
  ### Answer by username_1 on 2020-03-18. Score: 0
  
  The solution is to do it right:
  
  * **Do not** check them into source control.
  * **Do** use remote state.
  * **Do not** allow user access to production remote state.
  * **Do** enforce continuous deployment for production.
  
  
  ---
  
  