Disable suppression

[fatbasstard]

Introduction

We're using TFLint in our Platform Engineering setup to help other developers with writing "Secure and correct" Terraform code. And block the "wrong" ones at PR level.

We've got a really nice ruleset and automation over all our repositories in place, but we now get the "Let's just suppress this" behaviour.

Although the possibility to suppress findings is really handy (if there is no other way, or implementation will be done later), I would the capability to mark findings with a "cannot be suppressed" option. So certain findings cannot be suppressed.

Proposal

Create a toggle per finding to "allow suppression", allowed by default.

References

[bendrucker]

This needs more detail, e.g. a proposed API, before it's a concrete feature proposal. But I like the idea!

[bendrucker]

First thought would be to add an ignorable attribute to rule and possibly plugin too.

The behavior would have two phases:

1. When parsing annotations, make sure all rule-specific ignores are not forbidden by an ignorable = false TFLint configuration. If so, error on that, before even evaluating the Terraform configuration.
2. When filtering emitted issues, check again, to handle file and all annotations. Simply emit these as if they were not ignored, since the annotation itself is still valid for other rules.

[wata727]

Given that Eslint provides options like --no-inline-config, I think it's not a bad idea to provide an option for whether annotations are enabled or not.

On the other hand, I'm not sure if this feature is really useful from Platform Engineering perspective. If the ignoreable can be easily changed by other developers through .tflint.hcl, there is the problem of how platform engineers should detect the change, which can be as complex as detecting inline comments if configuration files are scattered all over the place (e.g. monorepo).

[fatbasstard]

In our case the .tflint.hcl is loaded from a centralized repository so it's fully under our control. We can enable/disable rules and configure it all up to our "standardized" needs. so people cannot change that file in the CI/CD flow.

And even for ourselves as engineers, from the SecOps point of view some rules we just don't want to be bypassed. So I actually like the ignorable option.

Default behaviour stays the same, but if wanted we can "enforce" certain checks, giving more control

[wata727]

Related discussion: #1690

[fatbasstard]

Oh, examples:

supressing terraform_unused_declarations is fine (maybe you're preparing codechanges). supressing terraform_naming_convention is BS, just implement the rule.

Maybe not the best example, but that's the idea 😄