0.9.4
provider "aws" {
alias = "src"
region = "${var.aws_src_region}"
profile = "${var.aws_src_profile}"
}
provider "aws" {
alias = "dest"
region = "${var.aws_dest_region}"
profile = "${var.aws_dest_profile}"
}
data "aws_caller_identity" "src" {
provider = "aws.src"
}
resource "aws_s3_bucket" "src" {
provider = "aws.src"
bucket = "${var.src_bucket_name}"
versioning {
enabled = true
}
replication_configuration {
role = "${aws_iam_role.src.arn}",
rules = {
prefix = ""
status = "Enabled"
destination {
bucket = "${aws_s3_bucket.dest.arn}"
}
}
}
}
resource "aws_s3_bucket" "dest" {
provider = "aws.dest"
bucket = "${var.dest_bucket_name}"
versioning {
enabled = true
}
policy = <<EOF
{
"Version":"2008-10-17",
"Id":"",
"Statement":[
{
"Effect":"Allow",
"Principal":{
"AWS":"arn:aws:iam::${data.aws_caller_identity.src.account_id}:root"
},
"Action":["s3:ReplicateObject", "s3:ReplicateDelete"],
"Resource":"arn:aws:s3:::${var.dest_bucket_name}/*"
}
]
}
EOF
}
s3 bucket should have been imported to the state file.
the output implies that the aws s3 bucket resource was located and queried - but that a subsequent (internal to the command) "Refreshing state" failed due to improper aws credentials.
Please list the steps required to reproduce the issue, for example:
terraform import \
> -provider aws.src \
> -var aws_src_profile=src -var aws_src_region=us-east-1 -var src_bucket_name=src \
> -var aws_dest_profile=dest -var aws_dest_region=us-west-1 -var dest_bucket_name=dest \
> -var application=app \
> aws_s3_bucket.src src
The terraform source uses two aws providers, each with an alias. The terraform import command appears to use that, correctly, for the import step, but then forget to use them for the refresh step. Another oddity is that the command prompts for the default region as it starts up, but also continues to run (making the output from the command interleave the prompt/answer and further output.) Entering a region, or just pressing ENTER, does not make any difference and the command still fails. It is telling that if, in addition to the command as it stands, I prefix it with some environment variables: AWS_DEFAULT_REGION="us-east-1" AWS_ACCESS_KEY_ID=xxx AWS_SECRET_ACCESS_KEY=xxx for the (in this case) src account - the command executes correctly. Here is the output from the import command above:
```
provider.aws.region
The region where AWS operations will take place. Examples
are us-east-1, us-west-2, etc.
Default: us-east-1
Enter a value: aws_s3_bucket.src: Importing from ID "src"...
aws_s3_bucket.src: Import complete!
Imported aws_s3_bucket (ID: src
aws_s3_bucket.src: Refreshing state... (ID: src)
I PRESSED ENTER
Error importing: 1 error(s) occurred:
yeah - i was trying to use a common infra data module that i set up with an input variable called environment that keyed a map with things including profile, but i couldn't get the refresh step to respect the provider.aws.profile i supplied using that module's output. so there's definitely a disconnect between refresh and declared providers.
Any progress here? I am hitting the same issue here when trying to import a KMS key.
I also had this issue w/ v0.10.2 and v0.10.6 while importing aws users.
terraform import --provider=aws.awssecurityad aws_iam_user.jdoe_awssecurityad [email protected]
worked around it w/
AWS_ACCESS_KEY_ID='xxx' AWS_SECRET_ACCESS_KEY='xxx' terraform import --provider=aws.awssecurityad aws_iam_user.jdoe_awssecurityad [email protected]
This is fixed in master, and will be in the 0.11 release.
Unless I'm doing something wrong, this does not be appear to be resolved for the version matrix:
Terraform v0.11.7
+ provider.google v1.10.0
I do not have a default provider, or default application credentials, and instead have each provider aliased. Modules are then added to the root directory's main.tf, and a providers map is provided, which is of course consumed by module, which uses each provider to define resources. To import existing resources into state (we'll use a custom role for Google Cloud Platform as an example), the following command should be used (according to current documentation):
terraform import \
-provider="my_google_provider_alias" \
module.my_module_name.google_project_iam_custom_role.foo \
projects/my-project/roles/foo
This successfully imports the resource, but fails to refresh the state:
module.my_module_name.google_project_iam_custom_role.foo: Importing from ID "projects/my-project/roles/foo"...
module.my_module_name.google_project_iam_custom_role.foo: Import complete!
Imported google_project_iam_custom_role (ID: projects/a-dev/roles/foo)
module.my_module_name.google_project_iam_custom_role.foo: Refreshing state... (ID: projects/my-project/roles/foo)
Error: provider.google: google: could not find default credentials. See https://developers.google.com/accounts/docs/application-default-credentials for more information.
I don't believe I'm the odd one out for not wanting default application credentials and instead having to explicitly define them. In my opinion, if a provider is explicitly defined using the -provider flag, then terraform import should ensure that the defined provider is used for _all_ operations. If this is somehow impossible, we should provide documentation for this.
_Note to other users who may stumble upon this with the same issue: I worked around this by temporarily generating default application credentials for my IAM user via google auth application-default login. You can then remove the credentials.json file and revoke access to the Auth application in the App Permissions page for your Google account._
SO turns out if you set an alias, import won't find the provider. SO more on our side ugh - not an issue at the moment once I noticed that :(
**Updated
Want to second this issue. Using 0.11.7
Terraform import first stage works fine. Finds the resource. Second stage on the refresh ignores the provider block it seems. This hits us on assumed roles:
provider "aws" {
assume_role {
role_arn = "arn:aws:iam::12341235123:role/admin"
}
}
We do this as we run with credentials from a master account 55555555. The permissions work let us import, then refresh fails and doesn't seem to use the above role assumption :(
Hello @jbardin, is there any chance this could be reopened? This is definitely still an issue in v0.11.13 and most likely also in 0.12.
Hi @Alberts00,
I believe you are looking for #18257 and/or #13018 if you want to follow the open issues. If those don't cover your use case, please file a new issue with the configuration and steps to reproduce it.
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.
Most helpful comment
SO turns out if you set an alias, import won't find the provider. SO more on our side ugh - not an issue at the moment once I noticed that :(
**Updated
Want to second this issue. Using 0.11.7
Terraform import first stage works fine. Finds the resource. Second stage on the refresh ignores the provider block it seems. This hits us on assumed roles:
We do this as we run with credentials from a master account 55555555. The permissions work let us import, then refresh fails and doesn't seem to use the above role assumption :(