Terraform: Confusing error message on terraform_remote_state's config block

[ashb]

I had a config error in the terraform_remote_state datasource and it took me a _while_ to work out what I'd done wrong.

The docs don't mention anything about assume_role (I probably copied it from the provider config) and it give this error:

• data.terraform_remote_state.vpc: config (assume_role): '' expected type 'string', got unconvertible type '[]map[string]interface {}'

That is.... hard to decipher what is actually going wrong.

(Also slightly counter to expectations the remote state data source (and I guess the backend) doesn't accept the same config as the aws provider.)

Terraform Version

Terraform v0.9.5

Affected Resource(s)

• data.terraform_remote_state

Terraform Configuration Files

data "terraform_remote_state" "vpc" {
  backend = "s3"

  config {
    region  = "eu-west-1"
    bucket  = "my-terraform-state"
    key     = "accounts/999999999999-demo/vpc.tfstate"
    profile = "annalect-emea"

    assume_role {
      role_arn = "arn:aws:iam::111111111111:role/OrganizationAccountAccessRole"
    }
  }
}

Steps to Reproduce

1. terraform plan

[jbardin]

Hi @ashb,

Thanks for bringing this up.
The remote_state data source takes the same configuration as the backend in the "terraform" configuration block.

That error is not helpful though, I'll see if we can get something better during validation.

[apparentlymart]

Hi @ashb! Sorry for the long silence here.

I tried the configuration you gave in the v0.12.0-alpha2 prerelease build. Running it as-is, I got the following error:

Error: Unsupported block type

  on data-remote-state-config.tf line 4, in data "terraform_remote_state" "vpc":
   4:   config {

Blocks of type "config" are not expected here. Did you mean to define
attribute "config"?

This one's expected because config is a map argument rather than a block and while Terraform 0.11 and prior failed to validate that (leading to some strange bugs in more complex cases), this is now required to use the attribute assignment syntax, config = { ... }. This will eventually be fixed automatically by a configuration upgrade tool included in the v0.12.0 final release, but since that tool is not yet complete I adjusted it manually.

After updating that, I got a different error:

Error: Invalid backend configuration

  on data-remote-state-config.tf line 4, in data "terraform_remote_state" "vpc":
   4:   config = {
   5:     region  = "eu-west-1"
   6:     bucket  = "my-terraform-state"
   7:     key     = "accounts/999999999999-demo/vpc.tfstate"
   8:     profile = "annalect-emea"
  10:     assume_role = { # (I also adjusted this because blocks can't nest inside maps)
  11:       role_arn = "arn:aws:iam::111111111111:role/OrganizationAccountAccessRole"
  12:     }
  13:   }

The given configuration is not valid for backend "s3": unexpected attribute
"assume_role".

This is the new version of the error you got before, explaining that assume_role is not an expected argument for the s3 backend. This agrees with the s3 backend docs, which show this being specified as a top-level role_arn argument instead.

So after addressing that, I had the following configuration:

data "terraform_remote_state" "vpc" {
  backend = "s3"

  config = {
    region   = "eu-west-1"
    bucket   = "my-terraform-state"
    key      = "accounts/999999999999-demo/vpc.tfstate"
    profile  = "annalect-emea"
    role_arn = "arn:aws:iam::111111111111:role/OrganizationAccountAccessRole"
  }
}

Naturally this didn't apply as-is because all of the values are placeholders, but it passed the S3 backend's validation steps, and instead returned an AWS authorization error as I expected.

Since the bad error message is now fixed in master and ready to be included in the forthcoming v0.12.0 release, I'm going to close this out. Thanks for pointing this out and sorry it took so long to fix it!

---

By the way, I agree that it's unfortunate that the backend and provider settings are not aligned here. I think this is a historical limitation from back when backends only supported string values in their configuration, before they were updated to use the same schema system as providers. Although it is in principle now possible to have an assume_role block like you tried, that was not technically possible until recently. Perhaps in a future release we can update this for consistency with the provider and deprecate the top-level role_arn argument; we're planning to shift our focus to backend improvements soon, so we can think more about that as part of that work.

[jijojohn]

Unfortunatly i am getting the same error on tf version
$ terraform --version
Terraform v0.12.24

• provider.aws v2.61.0
• provider.null v2.1.2

`Error: Unsupported block type

on vpcxxx.tf line 4, in data "terraform_remote_state" "state":
4: config {
`