Document reasoning behind rule checks

Is your feature request related to a problem? Please describe. When running checkov, you get pointed to rule violations with a one line explanation of what is wrong, ex. Ensure Amazon EKS public endpoint disabled. However, there’s no deeper explanation on why that’s something to be concerned about, only that it’s suggested that you fix it. Also, fixing it with respect to making checkov happy is one thing, but supporting, external steps to make it work may be bigger than the one line configuration change. Tooling like this is a great opportunity to educate users on good practices, common problems, and solutions.

Describe the solution you’d like I would like to see documentation that explains why each rule is there (ie. what exactly is the problem?) and suggestions on how to fix it (ie. what configuration to change/add/update, as well as external changes to support it). Since each rule is supposed to be based on ‘best practices’, there should be a valid explanation of what problem the rule identifies actually is. Likewise, if these are ‘best practices’, then well known solution patterns should be available easily and conveniently. Similarly, examples, when applicable, of when this violation might safely be ignored/disabled should be discussed.

Describe alternatives you’ve considered The alternative is to internet search phrases around the one line suggestion in the output to try to find help on why it’s a problem, and what to do about it.

Additional context TFLint does a decent job of this: https://github.com/terraform-linters/tflint/blob/v0.14.0/docs/rules/aws_db_instance_default_parameter_group.md, and Rubocop at least links out to an external explanation: https://docs.rubocop.org/en/stable/cops_lint/

[schosterbarak]

Working on it! stay tuned.

[schosterbarak]

@bol @mgrecar you can now view a link to guide on each check output: