RFE: What about "Presets" or other grouping of rules?

[dhutty-archer]

The base ruleset for tflint, tflint-ruleset-terraform, has a concept of "presets". This groups the provided rules into categories so that users can enable/disable groups of rules at once which is particularly useful when there are hundreds of rules such as here in tflint-ruleset-aws. In a similar vein, ansible-lint has profiles and many other checkers use "severity" for categorization.

Might this be relevant to tflint-ruleset-aws?

plugin "aws" {
    enabled = true
    version = "0.38.0"
    source  = "github.com/terraform-linters/tflint-ruleset-aws"
    presets = ["iam"]
}

such that tflint then only runs checks on rules for AWS IAM Resources.

See also:

• This tflint-ruleset-terraform PR implemented this kind of functionality for the tflint.
• The Terraform Provider for AWS provides a handy grouping of AWS services which could make for an easy way to get started (and automatically update as AWS releases new services)

[bendrucker]

Yes, a similar presets feature could make sense here. Are there use cases other than services that you have in mind? I can't really think of any.

[dhutty-archer]

I don't know the existing rules well, but some rules are aimed at avoiding security risks, while some might be about valid functionality (think "your code cannot create a foo named bar because one with that name already exists", etc.).

So possible usages might be:

• In a CI pipeline that gets triggered by creating or updating a PR to "main", use rules from the presets 'security' and 'validity', treat findings as errors that block the PR from being merged.
• In a CI pipeline that gets triggered by creating or updating a PR to "dev", use rules from the presets 'security' and 'validity', treat 'validity 'findings as errors that block the PR, but 'security' findings as warnings
• pipelines that run upon merge might have stricter/more comprehensive behaviour.

[bendrucker]

Tying presets to issue levels or anything else currently controlled by each rule is a bigger change and probably not one we'd pursue.

some rules are aimed at avoiding security risks

Are they though?

This ruleset has lots of rules dealing with validation issues. Not aware of any security rules. Which leads me to think there aren't really any natural presets here, other than service-oriented ones.

[dhutty-archer]

okay, I'm sure you know better than me :)
service-oriented categorization sounds like a win to me.

[bendrucker]

Some implementation notes:

Service rule categorization should be done automatically based on the rule name prefix. But this isn't always straightforward—rds is db, ec2 has route among others. So there would have to be a map[string][]string somewhere of service name to rule name prefixes.