import aws_s3_bucket does not store important attributes like acl

[7rack]

i am trying to import exist s3 resource. generating hcl with terraforming, and importing statefile with terraform.
after import , while run terraform plan cannot get zero changes.
Terraform verion

Terraform v0.11.8
+ provider.aws v1.38.0

Terraform Configuration Files

main.tf

terraform {
  backend "s3" {
    bucket         = "terraform-state-foodev-global"
    dynamodb_table = "terraform-lock-foodev-global"
    key            = "s3/terraform.tfstate"
    region         = "ap-southeast-1"
  }
}
 
provider "aws" {
  region = "ap-southeast-1"
}

resource.tf -- generated by terraforming

resource "aws_s3_bucket" "freeman-test2" {
  bucket        = "freeman-test2"
  acl           = "private"
}

Output

$ terraform import aws_s3_bucket.freeman-test2 freeman-test2

Acquiring state lock. This may take a few moments...
aws_s3_bucket.freeman-test2: Importing from ID "freeman-test2"...
aws_s3_bucket.freeman-test2: Import complete!
  Imported aws_s3_bucket (ID: freeman-test2)
aws_s3_bucket.freeman-test2: Refreshing state... (ID: freeman-test2)
 
Import successful!
 
The resources that were imported are shown above. These resources are now in
your Terraform state and will henceforth be managed by Terraform.
 
Releasing state lock. This may take a few moments...

$ terraform plan
aws_s3_bucket.freeman-test2: Refreshing state... (ID: freeman-test2)
------------------------------------------------------------------------
An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  ~ update in-place
Terraform will perform the following actions:

  ~ aws_s3_bucket.freeman-test2
      acl:           "" => "private"
      force_destroy: "" => "false"

Plan: 0 to add, 1 to change, 0 to destroy.

and check s3/terraform.tfstate file, without acl attribute

Expected Behavior
run terraform plan get zero changes.

[Willis0826]

The issue is persist in Terraform v0.12.18. The acl and force_destroy of S3 is still missing after imported.

[jerryhebert]

I'm seeing this with Terraform 0.12.26 and version 2.69.0 of the aws provider. It's concerning when there are grants involved since trying to apply past this actually removed the grant. Here are the steps I observed:

1. Defined my aws_s3_bucket resource which included no specification of the acl property but did have one grant block.
2. Imported the bucket
3. Ran a plan, acl and force_destroy showed as dirty.
4. Attempted to set acl even though it's conflicting but this was disallowed. Setting force_destroy to false as the plan showed also did not seem to take any effect.
5. I decided to try to apply anyway, as this was a low risk bucket. Applying the phantom acl = "private" change actually removed my grant!
6. I ran another plan with the same source code which showed the grant as a new addition, since it had been removed.
7. I applied this and now the plan is finally clean.

I am not sure how to account for this without hacking the state file to add the acl (and maybe force_destroy) attributes directly but I have not been able to get an empty plan in this case and applying it is dangerous on high risk buckets since this would temporarily remove the policy as specified in code.

[benyitzhaki]

we are experiencing the same issue. terraform v0.12.28, aws provider 2.58.0

[arjunrv88]

This issue is still being seen with Terraform v0.12.24, aws-provider 3.3.0

[mattmelgard]

Would be great to get some kind of update on this if possible. This still seems to be a problem and the issue has been around for about 2 years now.

[tomaspinho]

Still an issue with Terraform 0.12.24 and aws-provider 3.22.0

[tomislater]

I had the same issue.

I imported an existing bucket to terraform. The bucket was public:

Here is the code:

resource "aws_s3_bucket" "my-bucket" {
  bucket = "my-bucket"

  grant {
    permissions = [
        "READ",
        "READ_ACP",
    ]
    type = "Group"
    uri = "http://acs.amazonaws.com/groups/global/AllUsers"
  }
  grant {
    id = "my-id"
    permissions = [
        "FULL_CONTROL",
    ]
    type = "CanonicalUser"
  }
}

After importing, during terraform apply, terraform wanted to change acl to private:

Terraform will perform the following actions:

  # aws_s3_bucket.my-bucket will be updated in-place
  ~ resource "aws_s3_bucket" "my-bucket" {
      + acl                         = "private"
      + force_destroy               = false
        id                          = "my-bucket"
        tags                        = {}
        # (7 unchanged attributes hidden)


        # (3 unchanged blocks hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.

But, after this action, terraform also removed logic from grant blocks (the bucket was not public anymore)! During another terraform apply, terraform wanted to add these blocks again...

So, what I did? I used this guy: https://www.terraform.io/docs/configuration/meta-arguments/lifecycle.html#ignore_changes and added both acl and force_destroy to ignore_changes list:

lifecycle {
    ignore_changes = [
      acl,
      force_destroy,
    ]
  }

And it works. Terraform does not want to change this resource anymore and does not remove my grant blocks too. But, I think that it looks quite hacky.

[alxsbn]

Still an issue.

Terraform v0.14.5
+ provider registry.terraform.io/hashicorp/aws v3.24.1

[christiansaiki]

Just curious here, how do I know what was the correct acl and force_destroy of my imported resource?
Is there a way to double-check it by using aws-cli?

[alxsbn]

Just curious here, how do I know what was the correct acl and force_destroy of my imported resource?
Is there a way to double-check it by using aws-cli?

https://docs.aws.amazon.com/cli/latest/reference/s3api/get-bucket-acl.html

[ghost]

And it works. Terraform does not want to change this resource anymore and does not remove my grant blocks too. But, I think that it looks quite hacky.

Maybe so, but thank you nonetheless, as I am experiencing this issue and this worked for me. Currently I do not see any alternative.

[trevorlinton]

Here's an OK workaround depending on your comfort level:

Step 1. Pull the state file down

Ensure you're in the directory of your imported s3 bucket and run:

terraform state pull > state.json

Step 2. Edit the state.json file and set the correct state on force_destroy/acl

In the JSON file you'll have to find your resource and in the attributes object you'll find both the acl and force_destroy are set to null, set these to the appropriate values:

You can map your S3 ACL to set of canned ACLs here:
https://docs.aws.amazon.com/AmazonS3/latest/userguide/acl-overview.html#canned-acl
As for the force_destroy, i set mine to false, but i'm not actually sure what this related to in AWS.

Step 3. Increment the serial number at the top of the state.json file

If its currently 5 set it to 6.. etc..

Step 4. Push the state file back up, and make sure to erase the local copy*

terraform state push ./state.json
rm state.json

After that all of it came out clean without having to ignore the state.

[lorengordon]

policy is another attribute of aws_s3_bucket that is not refreshed on import.

[breathingdust]

Hi all 👋 Just letting you know that this is issue is featured on this quarters roadmap. If a PR exists to close the issue a maintainer will review and either make changes directly, or work with the original author to get the contribution merged. If you have written a PR to resolve the issue please ensure the "Allow edits from maintainers" box is checked. Thanks for your patience and we are looking forward to getting this merged soon!

[pdecat]

Awesome news! I've opened this PR to fix this issue: #20670

[pdecat]

I believe this is now resolved by #22537

resource/aws_s3_bucket: The acl and grant arguments have been deprecated and are now read-only. Use the aws_s3_bucket_acl resource instead when available in a future minor version.

b09aa2c

[DrFaust92]

closing per @pdecat comment. If there are still issues please open a new ticket with relevant details.

[github-actions]

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.