terraform-provider-aws: GuardDuty entry created when deleting S3 public access block and bucket

Community Note

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave “+1” or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform Version

Terraform v0.12.21
+ provider.aws v2.50.0

Affected Resource(s)

aws_s3_bucket_public_access_block
aws_s3_bucket

Terraform Configuration Files

provider "aws" {
  region = "eu-west-2"
}

resource "aws_s3_bucket" "bucket" {
  bucket        = "guardduty-alert-trigger"
  acl           = "private"
  force_destroy = true
}

resource "aws_s3_bucket_public_access_block" "access" {
  block_public_acls       = true
  block_public_policy     = true
  bucket                  = aws_s3_bucket.bucket.id
  ignore_public_acls      = true
  restrict_public_buckets = true
}

Debug Output

N/A

Panic Output

N/A

Expected Behaviour

When running a terraform destroy the block and bucket should be destroyed without raising any entries in AWS GuardDuty. This is the behaviour I would expect because the bucket has not been opened to the public unexpectedly but is being deleted.

Actual Behaviour

When running a terraform destroy the block is destroyed before the bucket which creates an Policy:IAMUser/S3BlockPublicAccessDisabled entry in AWS GuardDuty. If the bucket is deleted directly then this entry is not raised.

Steps to Reproduce

Enable AWS GuardDuty with 15 minutes frequency
terraform init the above code
terraform apply the above code
terraform destroy the above code
Wait 15 minutes for AWS GuardDuty to update
See entry in AWS GuardDuty

Important Factoids

N/A

References

https://aws.amazon.com/about-aws/whats-new/2019/10/amazon-guardduty-adds-three-new-threat-detections/

About this issue

Original URL
State: open
Created 4 years ago
Reactions: 54
Comments: 17 (2 by maintainers)

Most upvoted comments

Is there an update on this? Open since 2020…

atamgp on Nov 15, 2022

Workaround Detail:

If you run the following before doing a terraform destroy it will remove any aws_s3_bucket_public_access_block resources from your state and therefore the destroy step will just delete the bucket directly rather than delete the public access block and then the bucket.

terraform state list | (grep aws_s3_bucket_public_access_block || true) | xargs -r -I {} terraform state rm '{}'

I’ve tested this with single resources and for_each loops of resources, not sure about count loops of resources.

If you’re changing a bucket name in your terraform and that under the hood is destroying this resource and making a new one I don’t have a nice solution for you that you can drop in, it would likely need to be a manual state edit for the specific resource rather than a catch-all. Or just live with the false-alarm 😞 .

alastair-smith on Apr 6, 2022

my question is not related to the alert itself, more focused on what would happens if the resource aws_s3_bucket_public_access_block gets destroyed and then there is an error before the associated bucket is destroyed. the bucket will become public and if whoever forget to delete files then it is a security issue. I wonder if terraform plan checks for if a bucket can be destroyed: e.g. aws does not allow you to destroy a bucket if it is not empty (if you do not use force option), does terraform plan throw error if the bucket you want to destroy contains files?

giacomochiarella on May 10, 2023

if I want to destroy an aws_s3_bucket, terraform will first destroy aws_s3_bucket_public_access_block associated. If an error happen right after aws_s3_bucket_public_access_block is destroyed, the aws_s3_bucket associated will not be destroyed and will become public. This is a security issue then.

giacomochiarella on May 10, 2023

This issue still happens in terraform version 1.1.7 with AWS Provider 4.8.0 (both latest) Any news on how to handle/mitigate this ?

KennethEgholm on Apr 6, 2022

Hey @alastair-smith 👋 Thank you for taking the time to file this issue. Given that there’s been a number of AWS provider releases since you initially filed it, can you confirm whether you’re still experiencing this behavior?

justinretzolk on Oct 26, 2021