### Terraform Version ``` › terraform version Terraform v1.0.8 on darwin_amd64 + provider registry.terraform.io/datadog/datadog v3.2.0 + provider registry.terraform.io/hashicorp/aws v3.55.0 + provider registry.terraform.io/hashicorp/helm v2.3. ``` ### Terraform Configuration Files ```terraform variable "secrets" { type = map(string) sensitive = true } resource "helm_release" "example" { name = "redis" repository = "https://charts.bitnami.com/bitnami" chart = "redis" set { name = "replica.replicaCount" value = 0 } set_sensitive { name = "auth.password" value = "foo" } dynamic "set_sensitive" { for_each = var.secrets content { name = set_sensitive.key value = set_sensitive.value } } } ``` Note that this example uses an arbitrary Helm chart, just to demonstrate the behavior around processing of the dynamic `set_sensitive` attribute. ### Debug Output ### Crash Output ### Expected Behavior In prior versions of Terraform (we last tried `0.13.5`) — albeit without the input variable being marked as `sensitive` since that wasn't supported yet — the Terraform apply succeeded. ### Actual Behavior In Terraform `1.0.8`, we see the following error: ``` │ Error: Invalid dynamic for_each value │ │ on test.tf line 6, in resource "helm_release" "example": │ 6: for_each = var.secrets │ ├──────────────── │ │ var.secrets has a sensitive value │ │ Cannot use a map of string value in for_each. An iterable collection is required. ``` As described in [for_each documentation](https://www.terraform.io/docs/language/meta-arguments/for_each.html#limitations-on-values-used-in-for_each), we understand that this new behavior is intentional for `resources` (and, therefore, presumably to `modules` as well): > Sensitive values, such as sensitive input variables, sensitive outputs, or sensitive resource attributes (if the provider_sensitive_attrs experiment is enabled), cannot be used as arguments to for_each. The value used in for_each is used to identify the resource instance and will always be disclosed in UI output, which is why sensitive values are not allowed. It wasn't clear to us, however, if this behavior was intentionally intended to apply for `dynamic` attributes of a resource. We can work around the error by using the `nonsensitive` function, like this: ```terraform dynamic "set_sensitive" { for_each = nonsensitive(var.secrets) ``` That could work here since the `set_sensitive` attribute is inherently sensitive in a `helm_release` resource and so would be redacted from UI output. It just seemed incorrect to have to do that when using content that fundamentally is sensitive. ### Steps to Reproduce 1. `terraform init` 2. `TF_VAR_secrets='{secret_1_key: "secret_1_val", secret_2_key: "secret_2_val"}' terraform apply` ### Additional Context ### References