Terraform-provider-aws: importing an S3 bucket fails on "Error importing AWS S3 bucket policy"

Created on 25 Jul 2019  ·  5Comments  ·  Source: hashicorp/terraform-provider-aws

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 "me too" comments, 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

v0.12.5

Affected Resource(s)

  • aws_s3_bucket

Terraform Configuration Files

resource "aws_s3_bucket" "xxxx-data-intelligence" {
  bucket = "xxxx-data-intelligence"
  acl = "private"
}

I have not defined a policy in the configuration, and there is no policy attached to the bucket.

Note that this bucket is in a subaccount than the one we typically use. To handle this, we map our provider account id to terraform workspace, like so:

provider "aws" {
  assume_role {
    role_arn = "arn:aws:iam::${lookup(module.accounts.ids, terraform.workspace, module.accounts.ids["di"])}:role/OrganizationAccountAccessRole"
  }
  region = "us-west-2"
}

This has been working for us for a variety of configurations, this is the first time we've encountered this issue.

Debug Output

➜  common git:(master) ✗ terraform import aws_s3_bucket.xxxx_data_intelligence xxxx-data-intelligence
aws_s3_bucket.xxxx_data_intelligence: Importing from ID "xxxx-data-intelligence"...

Error: Error importing AWS S3 bucket policy: AccessDenied: Access Denied
        status code: 403, request id: E1FAE91EE442xxxx, host id: <snip>

Expected Behavior


The S3 bucket should have been imported into the state.

Actual Behavior


The bucket failed to import, producing the error message mentioned in the debug output.

I _suspect_ what's happening is that the aws provider is correctly assuming role to import the bucket, but doesn't assume role to get the policy, resulting in the 'AccessDenied'.

Steps to Reproduce

  1. Create a provider configuration that defines an AWS account to assume using assume_role.
  2. Create an S3 bucket in that account
  3. Create a terraform configuration that maps to that bucket.
  4. Import the bucket using terraform import

Important Factoids


We're using a provider with assume_role to import the resource from a subaccount.

bug servics3

Most helpful comment

I've just encountered the same issue on terraform v0.12.18, aws provider v92.43.0, but was able to import successfully after replacing variables in provider configuration by static values (basically hardcoded account id just for import). I suspect it might be related to how terraform is resolving variables during import, something like https://github.com/hashicorp/terraform/issues/21662

All 5 comments

I've just encountered the same issue on terraform v0.12.18, aws provider v92.43.0, but was able to import successfully after replacing variables in provider configuration by static values (basically hardcoded account id just for import). I suspect it might be related to how terraform is resolving variables during import, something like https://github.com/hashicorp/terraform/issues/21662

Ran into this.

[karthik@server]$ terraform version
Terraform v0.12.24
+ provider.aws v2.61.0

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. 👍

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!

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!

Was this page helpful?
0 / 5 - 0 ratings