Add support for Terraform v1.10

[wata727]

Fixes #2172

This PR adds support for the following features added in Terraform v1.10:

• Ephemeral values
  • ephemeral.* expressions
  • ephemeral input variables
• ephemeralasnull function
• terraform.applying symbol
• Dynamic blocks with marked (sensitive or ephemeral) for_each values

Besides the above, updating the Terraform fork to v1.10 also brings several other fixes.

Ephemeral Values

Terraform v1.10 introduced ephemeral values. This is treated internally as a cty value marked in the same way as sensitive. In order to send marked values ​​to the plugin, we need to extend the serialization process, so updating the SDK version. See terraform-linters/tflint-plugin-sdk#358 for details.

Plugins built with older SDKs cannot interpret the new ephemeral mark, so host server will return ErrSensitive instead of returning a marked cty value. Strictly speaking, ephemeral values ​​are not sensitive values, but they are similar in that they contain secrets, so we have adopted the policy of returning this error that older SDKs can interpret to prevent unintended disclosure. Developers of plugins built with SDK v0.16+ should be aware that if they directly evaluate expr to a cty value, ErrSensitive may be returned. This will not affect you if you use the recommended function callback approach.

An expression like ephemeral.* will always resolve to unknown, just like a resource reference, but it differs in that it is marked as ephemeral. This is mostly no different from any other unsupported named value, but it has implications when passed as an argument to a function, such as ephemeralasnull.

Values ​​marked as ephemeral are treated the same as Terraform in most cases, but there is a slight difference when they are passed as meta-arguments. Terraform does not allow passing an ephemeral value as count, but TFLint does not throw an error. It is possible to match the same behavior, but since it is not necessary to exactly match the behavior that causes an error in Terraform, nothing is done here. The behavior regarding meta-arguments is summarized in below:

Are the marked values ​​available in meta-arguments?

Terraform

	sensitive	ephemeral
count	Yes	No
for_each	No	No

TFLint

	sensitive	ephemeral
count	Yes	Yes
for_each	No	No

The terraform.applying symbol, which returns an ephemeral value, always resolves to false.

Marked dynamic blocks

Terraform v1.10 now accepts marked for_each values in dynamic blocks. See hashicorp/hcl#679 for details.

TFLint now also supports expanding dynamic blocks when sensitive or ephemeral values ​​are included in for_each, but note that there is a slight difference in whether the mark propagates to children. Terraform propagates marks to all attributes included in a dynamic block, but TFLint does not. Instead, expressions containing the marked value resolve to unknown.

resource "aws_s3_bucket" "main" {
  dynamic "lifecycle_rule" {
    for_each = sensitive(toset([true]))

    content {
      # Terraform: cty.StringVal("static").Marks(marks.Sensitive)
      # TFLint:    cty.StringVal("static")
      id = "static"

      # Terraform: cty.True.Marks(marks.Sensitive)
      # TFLint:    cty.UnknownVal(cty.Bool)
      enabled = lifecycle_rule.value
    }
  }
}

In most cases this behavior is not likely to be an issue, but be aware that there are situations where it is less safe than Terraform in that static values ​​may become unmarked.

This is because older SDKs cannot support the marked values. TFLint supports dynamic blocks in the tfhcl package, a fork of hcl/ext/dynblock. It evaluates a wrapped expr on the fly and binds the cty value to the expr to send over the wire protocol. At this time, TFLint does not bind marked values ​​because not all plugins can handle all marked values. As a result, marked values ​​are resolved to unknown (iterators are treated as resource references) and static values ​​can be evaluated as is, without the mark. This behavior will be improved if all marks are supported in available SDK versions.

Side note: hashicorp/hcl#679 explains that if you use a sensitive value in the dynamic block for_each, Terraform will reject the value. However, in fact it will accept the value.

variable "attempts" {
  sensitive = true
  default = [1]
}

data "http" "example" {
  url = "https://checkpoint-api.hashicorp.com/v1/check/terraform"

  request_headers = {
    Accept = "application/json"
  }

  dynamic "retry" {
    for_each = var.attempts
    content {
      attempts = retry.value
    }
  }
}

$ ./terraform19 plan

Planning failed. Terraform encountered an error while generating this plan.

╷
│ Error: Invalid dynamic for_each value
│
│   on main.tf line 14, in data "http" "example":
│   14:     for_each = var.attempts
│
│ Cannot use a tuple value in for_each. An iterable collection is required.

$ ./terraform110 plan
data.http.example: Reading...
data.http.example: Read complete after 0s [id=https://checkpoint-api.hashicorp.com/v1/check/terraform]

No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration and found no differences, so no changes are needed.

I'm not sure if this was intended, but TFLint follows this behavior.