Importing S3 bucket with inline policy creates unmanageable policy object

[alkalinecoffee]

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.11.14
+ provider.aws v1.54.0
+ provider.template v1.0.0

Affected Resource(s)

• aws_s3_bucket
• aws_s3_bucket_policy

Terraform Configuration Files

resource "aws_s3_bucket" "bucket" {
  name = "my-bucket
  policy = <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
  ...

Expected Behavior

I'm specifying an aws_s3_bucket object with an in-line policy value shown above and importing it into my state.

After importing, I make a change to the policy and run terraform plan. The plan should show only policy changes on my newly imported aws_s3_bucket object.

Actual Behavior

After importing, it appears that the policy is internally attached to an aws_s3_bucket_policy object, which does not exist in my configuration and is unmanageable without further config changes.

Because my policy is specified in-line with the aws_s3_bucket, the terraform plan shows that the policy must be created directly on the bucket, and the policy object be removed:

  ~ aws_s3_bucket.bucket
      policy:        "" => "{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": ..."

  - aws_s3_bucket_policy.bucket

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

This is confusing as according to the plan, the policy should be deleted, then re-attached directly to the S3 bucket. So we're hesitant about running this plan in production.

To me, if an S3 object with a policy is imported into configuration that specifies a policy in-line, that policy should be attached directly to the aws_s3_bucket object, and the aws_s3_bucket_policy object should not exist at all.

Steps to Reproduce

1. Create bucket in S3 with a policy
2. Import with terraform import aws_s3_bucket.bucket my-bucket
3. terraform plan to see an unmanaged aws_s3_bucket_policy object

[bflad]

Hi @alkalinecoffee 👋 Thank you for reporting this confusing behavior and sorry it exists to begin with.

We plan on removing any "complex" imports (where a single terraform import operation adds multiple resources into the Terraform state) across all resources in version 3.0.0 of the Terraform AWS Provider. (Since I notice Terraform 0.11 in your version information, please note that this major update of the Terraform AWS Provider will only support Terraform 0.12 and later.)

In the meantime (on any version of the Terraform CLI), you can execute the following to remove the "extra" resource from the Terraform state:

$ terraform state rm aws_s3_bucket_policy.bucket

This does not affect anything in the S3 API, only the Terraform state. 👍

[bflad]

The removal of the automatic aws_s3_bucket_policy resource import during aws_s3_bucket resource import has been merged and will release with version 3.0.0 of the Terraform AWS Provider, likely in two weeks. Please follow the v3.0.0 milestone for tracking the progress of that release. You can use the aws_s3_bucket_policy resource import support to import that resource directly after the provider upgrade, similar to all other Terraform resources that support import. 👍

[alkalinecoffee]

Sounds good @bflad, thanks!

[ghost]

This has been released in version 3.0.0 of the Terraform AWS provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template for triage. Thanks!

[ghost]

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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!