cloudposse / terraform-aws-tfstate-backend

Terraform module that provision an S3 bucket to store the `terraform.tfstate` file and a DynamoDB table to lock the state file to prevent concurrent modifications and state corruption.
https://cloudposse.com/accelerate
Apache License 2.0
407 stars 175 forks source link

Invalid terraform when assume_role is set #171

Open spar-eag opened 4 months ago

spar-eag commented 4 months ago

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 4 months ago

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?

Gowiem commented 3 months ago

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