Rule documentation (aws_provider_missing_default_tags)

[davimmt]

Is this a yet to implement feature or am I missing something?

❯ cat .tflint.hcl
plugin "aws" {
  enabled = true
  version = "0.32.0"
  source  = "github.com/terraform-linters/tflint-ruleset-aws"
}

rule "aws_provider_missing_default_tags" {
  enabled = true
  tags    = ["Environment", "Owner", "Project", "Name"]
}

rule "aws_resource_missing_tags" {
  enabled = true
  include = ["aws_subnet"]
  tags    = ["NACL", "RT"]
}
❯ tflint --version
TFLint version 0.47.0
+ ruleset.aws (0.32.0)
+ ruleset.terraform (0.4.0-bundled)
❯ tflint
Failed to check ruleset; failed to check "aws_resource_missing_tags" rule: .tflint.hcl:16,3-10: Unsupported argument; An argument named "include" is not expected here. Did you mean "exclude"?

Refering to this doc.

Expected behaviour:

• At provider level all these tags enforced: ["Environment", "Owner", "Project", "Name"];
• Only for "aws_subnet" resources these tags enforced: ["NACL", "RT"].

[wata727]

This seems to be a bug in the documentation.
The aws_resource_missing_tags rule does not support the include attribute.

tflint-ruleset-aws/docs/rules/aws_resource_missing_tags.md

Lines 5 to 13 in 300933d

	## Configuration
	```hcl
	rule "aws_resource_missing_tags" {
	enabled = true
	tags = ["Foo", "Bar"]
	exclude = ["aws_autoscaling_group"] # (Optional) Exclude some resource types from tag checks
	}
	```

cc:/ @bootswithdefer

[wata727]

Sounds good. There may be room for thought regarding the naming. The antonym of the exclude would be the include, but only is more intuitive. We also need to consider how it will behave when set together with the exclude.

As you say, there is a possibility that it may conflict with #639, so if you submit a PR first, please note that depending on the progress, we may ask you to resolve the conflict. If that doesn't bother you, you can submit a PR at any time.

By the way, if you know explicitly which resources you want to enforce tags on, another option might be to use the OPA ruleset.
https://github.com/terraform-linters/tflint-ruleset-opa

The benefit of the OPA ruleset is that it allows you to easily define your own policies, eliminating the need for infinite extensibility of these rules (which is why I recommend the OPA ruleset). If there is a reason why the OPA ruleset can't solve your problems, please send us your feedback.

That said, it does make sense to have an option that is the opposite of the exclude, so I'm not opposed to adding the feature.

[davimmt]

OPA ruleset should do. However, it adds a lot of complexity. But something like this should be enough:

# .tflint.d/policies/tags.rego
package tflint

import rego.v1

# Change here according to your needs!
required_tags = {
  "aws_instance": ["BKP"],
  "aws_subnet": ["NACL", "RT"]
}

resources := terraform.resources("*", {"tags": "map(string)"}, {"expand_mode": "none"})

# "tags" is null
is_untagged(config, _) if {
        is_null(config.tags.value)
}

# "tags" is not defined
is_untagged(config, _) if {
        not "tags" in object.keys(config)
}

# "tags" is defined, but all required tags not found
is_untagged(config, type) if {
        not is_null(config.tags.value)
  required_tag := required_tags[type][_]
  not object.keys(config.tags.value)[required_tag]
}

# Rule itself
deny_untagged_instance contains issue if {
        is_untagged(resources[i].config, resources[i].type)
        issue := tflint.issue(`Resource must be tagged with all the required tags`, resources[i].decl_range)
}

# main.tf
resource "aws_subnet" "foo" {
  tags = {
    "NACL" = "DMZ"
    "RT" = "IGW"
  }
}

resource "aws_instance" "bar" {
  tags = {
    "BKP" = "false"
  }
}

I'll think about making this PR, it seems like a feature that should exist by default.

[wata727]

I realized once again that there are issues with value handling. This is tracked in terraform-linters/tflint-ruleset-opa#23
It is the OPA ruleset's goal to make writing rules like this as simple as possible. Thank you for your feedback.

[davimmt]

So, I suppose these rules doesn't work with dynamic values. As with tags applied from withing a module and not directly from a resource call. It would have to lint the plan file output, as I understand tflint won't do.

For this case, I should use OPA directly or something like Terratest.

[wata727]

Yes, this is a trade-off in static analysis. You need to accept either false positives/negatives.
We understand that this property may be a disadvantage in cases where you want to apply a policy without exception.

However, the behavior that static module outputs are always marked as dynamic values ​​is an implementation limitation that may be improved in future versions. We also believe that there are few cases where a policy requires completely dynamic values, and we believe that if you can write a policy for that "property" (e.g. Value Refinements), TFLint can cover this case and many others.

We recognize that these improvements are necessary for the widespread use of the OPA ruleset. Thank you for your feedback.