backend/local: disable local backup of remote state #16464
Conversation
Previously we forced all remote state backends to be wrapped in a BackupState wrapper that generates a local "terraform.tfstate.backup" file before updating the remote state. This backup mechanism was motivated by allowing users to recover a previous state if user error caused an undesirable change such as loss of the record of one or more resources. However, it also has the downside of flushing a possibly-sensitive state to local disk in a location where users may not realize its purpose and accidentally check it into version control. Those using remote state would generally prefer that state never be flushed to local disk at all. The use-case of recovering older states can be dealt with for remote backends by selecting a backend that has preservation of older versions as a first-class feature, such as S3 versioning or Terraform Enterprise's first-class historical state versioning mechanism. There remains still one case where state can be flushed to local disk: if a write to the remote backend fails during "terraform apply" then we will still create the "errored.tfstate" file to allow the user to recover. This seems like a reasonable compromise because this is done only in an _exceptional_ case, and the console output makes it very clear that this file has been created. Fixes #15339.
|
Does the S3 backend currently check today if versioning is enabled on the bucket? And if not - tell the user? Just something to make using at least S3 buckets safer since versioning is not enabled by default. |
|
Is this issue fixed? does terraform still write |
|
Just updated to 0.11.13 but it still creates local |
|
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further. |
ghost
locked and limited conversation to collaborators
Previously we forced all remote state backends to be wrapped in a
BackupStatewrapper that generates a localterraform.tfstate.backupfile before updating the remote state.This backup mechanism was motivated by allowing users to recover a previous state if user error caused an undesirable change such as loss of the record of one or more resources. However, it also has the downside of flushing a possibly-sensitive state to local disk in a location where users may not realize its purpose and accidentally check it into version control. Those using remote state would generally prefer that state never be flushed to local disk at all.
The use-case of recovering older states can be dealt with for remote backends by selecting a backend that has preservation of older versions as a first-class feature, such as S3 versioning or Terraform Enterprise's first-class historical state versioning mechanism.
There remains still one case where state can be flushed to local disk: if a write to the remote backend fails during
terraform applythen we will still create theerrored.tfstatefile to allow the user to recover. This seems like a reasonable compromise because this is done only in an exceptional case, and the console output makes it very clear that this file has been created. There is no remote location where the result could be written in this case.Fixes #15339.