sensitive_config_vars changes should show which config vars are changing

[mmrobins]

trafficstars

While having the values of sensitive_config_vars not show in plan output is good, not showing which keys are changing makes it difficult to refactor and reason about changes.

I realized that config_vars and sensitive_config vars are just managed as a map data type, so this probably isn't doable without changing them to be their own resources, but I think changing this might also help with other issues like https://github.com/terraform-providers/terraform-provider-heroku/issues/247

Terraform and Provider Version

% terraform -v
Terraform v0.12.21
+ provider.heroku v2.2.2

Affected Resource(s)

heroku_app

Terraform Configuration Files

provider "heroku" {
  version = "~> 2.0"
}

resource "heroku_app" "app" {
  name             = "matttest-sensitive-configvars"
  region           = "us"
  organization {
    name = "myorg"
  }
  config_vars = {
    NOTSENSITIVE = "yup"
  }
  sensitive_config_vars = {
    MYVAR = "secret"
    MYVAR2 = "alsosecret"
  }
}

Expected Behavior

If I change a sensitive config var I would expect the output to show which changed, but not the value changing.

So if I change my initial terraform code

  config_vars = {
    NOTSENSITIVE = "yuppers"
  }
  sensitive_config_vars = {
    MYVAR = "secret with change"
    MYVAR2 = "alsosecret"
  }

I would expect output to be something like

  # heroku_app.app will be updated in-place
  ~ resource "heroku_app" "app" {
      ~ config_vars           = {
          ~ "NOTSENSITIVE" = "yup" -> "yuppers"
        }
      ~ sensitive_config_vars = {
          ~ "MYVAR" = (sensitive value)
      }

Actual Behavior

When I change config vars I can't tell which sensitive_config var changes

  # heroku_app.app will be updated in-place
  ~ resource "heroku_app" "app" {
      ~ config_vars           = {
          ~ "NOTSENSITIVE" = "yup" -> "yuppers"
        }
      ~ sensitive_config_vars = (sensitive value)

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. Change a value in sensitive_config_vars
2. terraform plan
3. Try to tell which config var you're changing

[davidji99]

This is likely a limitation by the terraform SDK when setting an attribute on a resource with Sensitive: true. That attribute property masks the entire diff for an attribute.

If you have noticed a different behavior in another provider, let us know.

[mmrobins]

This is likely a limitation by the terraform SDK when setting an attribute on a resource

Agreed.

this probably isn't doable without changing them to be their own resources, but I think changing this might also help with other issues like #247

Not sure if this config_vars attribute is similar to something like ingress for aws_security_group https://www.terraform.io/docs/providers/aws/r/security_group.html#ingress where you could use a for_each I'm not 100% sure of the terminology here, but I think this is an attribute as a block? https://www.terraform.io/docs/configuration/attr-as-blocks.html

If not possible to get a decent diff as a nested / sub resource / attribute as block (whatever the correct terminology), then I'd prefer each config var be its own resource (sensitive or regular). Kinda verbose for code, but at least then it'd be less surprising behavior than the current all_config_vars -> config_vars and sensitive_config_vars, at least in my opinion.

[davidji99]

heroku_app.config_vars is simply a freeform map of strings and aws_security_group.ingress is technically a list of maps. Additionally, attribute as a block is ideal for this resource's attribute because the attribute ingress has a predefined set of subattributes such as aws_security_group.ingress.from_port whereas heroku_app.config_vars does not in the schema.

That said if you wish to achieve 'each config var be its own resource', you can do this via the heroku_app_config_association resource. I would also recommend this resource as it allows one to modify just the config vars of an app and not touch any additional configurations. You can use the for_each attribute for the entire resource as well.