cloudposse/terraform-aws-tfstate-backend

Invalid terraform when assume_role is set

spar-eag opened this issue · 2 comments

Describe the Bug

When assume_role is set, the generated backend configuration is not valid. E.g.

module "terraform_state_backend" {
  source = "cloudposse/tfstate-backend/aws"
  version     = "1.4.1"
  namespace  = "test"
  name       = "tf-state"

  terraform_backend_config_file_path = "."
  terraform_backend_config_file_name = "backend.tf"
  role_arn = "<my role>"
}

results in the following configuration

terraform {
  required_version = ">= 1.0.0"

  backend "s3" {
    region  = "eu-central-1"
    bucket  = "test-tf-state"
    key     = "terraform.tfstate"
    profile = ""
    encrypt = "true"

    assume_role {
      role_arn = "<my role>"
    }

    dynamodb_table = "test-tf-state-lock"
  }
}

Applying this result in

Unsupported block type
│ 
│   on backend.tf line 11, in terraform:
│   11:     assume_role {
│ 
│ Blocks of type "assume_role" are not expected here. Did you mean to define argument "assume_role"? If so, use the equals
│ sign to assign it a value.

The generated code should actually be

terraform {
  required_version = ">= 1.0.0"

  backend "s3" {
    [...]
    assume_role = {
      role_arn = "<my role>"
    }
    [...]
}

i.e. an equal sign is missing. See https://developer.hashicorp.com/terraform/language/settings/backends/s3#assume-role-configuration.

Expected Behavior

I expect correct backend code to be generated.

Steps to Reproduce

See code example above.

Screenshots

No response

Environment

No response

Additional Context

No response

Nuru commented

I have been wanting to get rid of the generated configuration for a long time, as it is difficult to use and difficult to maintain. This was broken in #151 6 months ago, and if even the PR submitter didn't realize it was broken, then, to me, that is evidence that few people are using it and we can safely get rid of it.

@osterman What do you think?

@Nuru +1 on getting rid of it. It doesn't feel like it should be in scope of this module -- That's not a great way to manage backend configs.

@spar-eag if you put up a PR that removes this functionality altogether, then I'd be happy to review and we can bring it to the rest of the maintainer team to get their thoughts as well at that point.