feat: Generic rule to prevent certain dangerous resources like aws_iam_policy_attachment

[nitrocode]

There is a large warning for the resource aws_iam_policy_attachment to use aws_iam_role_policy_attachment instead.

I'd like to prevent the first resource from getting into our infrastructure with an appropriate tflint rule. We could make it specific to this resource but I'd prefer a more generic one so if we find a future resource, we can simply add it to a list within the rule.

rule "terraform_denylisted_resources" {
  enabled = true

  resources = [
    "aws_iam_policy_attachment",
    "google_organization_iam_binding",
  ]

  # in case some upstream module refuses to remove xyz resource 
  # and you don't want to manage a fork
  allow_in_modules = true
}

Edit: @mveitas put in PR terraform-linters/tflint#769

[mveitas]

@nitrocode Are you thinking along the lines of a rule named terraform_blacklisted_resources?

[nitrocode]

Yes exactly

[mveitas]

I'll try and get this knocked out. I think this is a great thing to have and am going to make use of it as soon as it is released!

[bendrucker]

Would be nice for this to take a map of suggested resources and the preferred alternative as opposed to just returning that something was blacklisted. I'm not sure what actual use cases there'd be for entirely blacklisting a resource with no suggested alternative.

[nitrocode]

Would be nice for this to take a map of suggested resources and the preferred alternative as opposed to just returning that something was blacklisted.

@bendrucker yes or even a custom message could be printed if the code was flagged due to the terraform_blacklisted_resources rule (terraform-linters/tflint#768).

I'm not sure what actual use cases there'd be for entirely blacklisting a resource with no suggested alternative.

@bendrucker, the original post mentions a resource that has been dangerous which was the incentive for this ticket. nvm just caught the tail end "with no suggested alternative" agreed.

[bendrucker]

Ha, was typing as I saw your edit. In theory I could imagine someone wanting to blacklist a resource with no alternative because it has bugs, but that seems like a pretty narrow/tricky use case.

Suggestions to use b instead of a could cover a lot of providers—the Google provider has resources with similar caveats, e.g.:

https://www.terraform.io/docs/providers/google/r/google_organization_iam_binding.html

[mveitas]

It would be nice to have this within the provider so tools could leverage this information. It sort of already exists as the documentation for a provide has the information.

[mveitas]

@nitrocode I have an initial version of the rule: terraform-linters/tflint#769

[wata727]

In my opinion, it is better to obviously resources that should be avoided (like aws_iam_policy_attachment) are provided as defaults in TFLint, rather than being investigated and configure by users themselves.

On the other hand, I agree that such a rule is effective when you want to avoid some resources for some special reason, but if possible, I want to make it a tool that provides such best practices.

[mveitas]

In my opinion, it is better to obviously resources that should be avoided (like aws_iam_policy_attachment) are provided as defaults in TFLint, rather than being investigated and configure by users themselves.

That starts to add an opinion with regards to best practices and each organization is going to have their own view on what's best for them. IMO TFLint is best served to provide a framework for people to enforce rules. The overhead associated with understanding all of the resources associated with a provider is a large amount of work.

[bendrucker]

+1 from me on usable defaults, e.g. suggesting alternatives to aws_iam_policy_attachment, rather than requiring users to supply that configuration. It's fine to also have a generic configurable rule so that end users can cover less common providers. But the overall value of good defaults will always be a lot higher than an infinitely configurable option that only a tiny fraction of users do the work to adopt.

[mveitas]

👍

Since these things are very much provide specific, can we say that the terraform_blacklisted_resources is the generic configurable rule and rules to support provider specific defaults should be placed under the rules/awsrules?

[bendrucker]

Yes. I'd avoid making the tests or examples too AWS centric to help avoid confusion with an eventual AWS-specific rule.

[m00lecule]

@mveitas are there still chances, that this rule will be implemented?