Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Terraform deletion prevention when removing resource from config #3468

Closed
spicykoala opened this issue Oct 9, 2015 · 10 comments
Closed

Terraform deletion prevention when removing resource from config #3468

spicykoala opened this issue Oct 9, 2015 · 10 comments

Comments

@spicykoala
Copy link

Is there a way to prevent the deletion of a resource if it accidentally gets removed from the terraform config? 'prevent_destroy' in the lifecycle block seems to only stop resources from being deleted when their changes require deletion, it doesn't seem to have any effect if you accidentally delete the resource from the config and then apply.

Thoughts?

@spicykoala
Copy link
Author

resource "aws_sqs_queue" "terraform_queue" {
  name = "terraform-example-queue"
  delay_seconds = 90
  max_message_size = 2048
  message_retention_seconds = 86400
  receive_wait_time_seconds = 10

  lifecycle {
    prevent_destroy = true
  }
}

resource "aws_sqs_queue" "terraform_queue_two" {
  name = "terraform-example-queue-two"
  delay_seconds = 90
  max_message_size = 2048
  message_retention_seconds = 86400
  receive_wait_time_seconds = 10

  lifecycle {
    prevent_destroy = true
  }
}

changing to:

resource "aws_sqs_queue" "terraform_queue_two" {
  name = "terraform-example-queue-two"
  delay_seconds = 90
  max_message_size = 2048
  message_retention_seconds = 86400
  receive_wait_time_seconds = 10

  lifecycle {
    prevent_destroy = true
  }
}

will remove terraform_queue from amazon.

@erichmond
Copy link

This doesn't directly answer your question, but we have adjusted the IAM of the terraform user so that it is unable to delete resources we never want deleted.

@spicykoala
Copy link
Author

Thanks for the reply - that is the approach we've taken as well. In fact, even if terraform had an option, we'd likely keep it that way as an extra layer of protection. I just wanted to know if it was intended functionality.

@antonyshchenko
Copy link

Would be great if this feature gets implemented at some point!

@veqryn
Copy link

veqryn commented Apr 20, 2017

I don't really see the point of prevent_destroy if it doesn't prevent this sort of thing.

Even with prevent_destroy, your resources will still get destroyed if you terraform apply after:
renaming them (and accidentally forget to use state-mv on them)
moving them into a module (and accidentally forget to use state-mv on them)
accidentally deleting them from the tf file

@roidelapluie
Copy link
Contributor

So, I have taken a quick look:

  • Currently no meta attributes are persisted into state. We could either persist all of them (I think it would be cool but maybe overhead.) or specifically persist a prevent_permanent_destroy meta attribute.
  • We only need to run that check for orphan resources (node_resource_plan_orphan.go) so that should not be too much complex.

@tdmalone
Copy link

tdmalone commented Jul 2, 2018

Potentially duplicated by #17599

@heidemn
Copy link

heidemn commented Jul 6, 2018

Guys I would really appreciate if you fix this.
I think that this is currently one of the biggest issues with Terraform.

@apparentlymart
Copy link
Contributor

This does indeed seem to be the same thing as #17599. Thanks for pointing that out, @tdmalone! I'm going to close this one to consolidate the discussion over there.

@ghost
Copy link

ghost commented Apr 4, 2020

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 ghost locked and limited conversation to collaborators Apr 4, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

10 participants