I have a lot of terraform repositories where there is a root module that includes other modules with some inputs/attributes. Those inputs are variables for the other modules, which affect whether they pass or fail rules. But config-lint doesn't handle that situation correctly, instead looking at just one file at a time, and not being aware of the relationship between the files or what is in the variables one is passing to another.

I would like to be able to config-lint a single root module and have it include/import the referenced modules with the appropriate inputs/variables.

Upgrade the currently used Go version 1.12 to use the current latest version 1.13 for all of the GitHub Workflows

Would be nice to have it compiled for Windows as well for people who have less flexible environments.

go.mod defines go 1.12, but the circleci build image we're using is circleci/golang:1.11. We need to set the build image to circleci/golang:1.12 and test accordingly.

Add a new Terraform rule:
An SQS policy should not use a wildcard action.

Using the --help option shows all of the options, but they should also be documented in the README or one of the files in the docs subdirectory

As the title says, we need to update the Build workflow to use the GitHub Workflow provided container image to run the build stages and use the setup-go action to install and configure go to better match the Build & Deploy Workflow.

The README shows setting rules for config-lint with "-rules" and "--rules" - is there one way it should be? Or are they correct as written?

We should add a step to the deployment process to push config-lint to the Stelligent DockerHub under https://hub.docker.com/r/stelligent/config-lint.

This is currently not a high priority, but will make config-lint more accessible for quickly adding to deployment pipelines.

Add a new Terraform rule:
An IAM role policy should not use a wildcard action.

Add a new Terraform rule:
AWS Lambda permissions should not use a wildcard principal.

add access_policies to the slice of TF fields that config-lint tries to parse as json

Add a new Terraform rule:
AWS CodeBuild project should use encryption.

Per https://www.hashicorp.com/blog/announcing-terraform-0-12 Terraform v 0.12 has been released and is using HCL 2.

We need to review the changes and create a set of issues for supporting Terraform 0.12.

Add a new Terraform rule:
A CloudFront distribution must have access logging configured.

Add a new Terraform rule:
EBS device volumes must be encrypted.

On rule failure, exit code is 0

Example:

$ config-lint -rules config_lint_rules/config_lint_default_rules.yml .
Failed to load rules: error unmarshaling JSON: json: cannot unmarshal array into Go struct field Expression.Value of type string
$ echo $?
0

Expected behavior:
exit code is 1

Add a new Terraform rule:
AWS CodePipeline should use an encryption key.

Add a new terraform rule:

AWS security group should not allow ingress from anywhere (0.0.0.0/0 or ::/0)

Add a new Terraform rule:
An S3 bucket policy should not use a wildcard principal.

Add a new Terraform rule:
An S3 bucket policy should not use a wildcard action.

For a description of the exception needed on checking for egress rules with protocol -1, see this issue raised for cfn_nag:

stelligent/cfn_nag#289

We are no longer using circleci to build this project, so the circleci artifacts need to be cleaned up and the local dev environment (VS Code Remote-Containers config) should align with the Github Actions workflows using golang:1.12.

Rules can be scoped to a specific ResourceType which can be "*" for all resources.
They can also be scoped to a list of ResourceTypes
It would be nice to have a way to specify "all resources except for this list"
This is more future-proof than explicitly listing all known resources in the ResourceTypes attribute.

Some typical use cases:
Tagging strategies for AWS resources - list resources types that do not support tagging
Metadata - list resource types that do not require certain metadata attributes

I would like to move this project from using dep to manage dependencies to Go Modules to improve the development experience.

This would include fixing the makefile and CI steps as needed.

In CI toolchains capable of parsing and making workflow decisions based on xunit xml artifacts, it would be useful for config-lint to emit such an XML file of its linting results (vice return codes and JSON output).

I found a couple of examples of golang emitting junit/xunit, but they seemed non-trivial

Replace the broken CircleCI build status badge with the GitHub Actions build status badge.

https://help.github.com/en/actions/automating-your-workflow-with-github-actions/configuring-a-workflow#adding-a-workflow-status-badge-to-your-repository

Add S3 bucket encryption test to terraform built-in rules

Add a new Terraform rule:
An SNS topic policy should not use a wildcard principal.

See how this is done in cfn_nag: https://github.com/stelligent/cfn_nag/blob/master/scripts/setup_and_run_end_to_end_tests.sh

The idea here is mainly to make sure we didn't drastically break anything for starters. More advanced tests can be added later.

Allow a rule to apply to multiple resources, defined as a list.

Example:

  - id: UTAN_VALID_REGEX
    resources: 
        - aws_dynamodb_table
        - aws_instance
    message: make sure that UTAN is a valid regex
    severity: WARNING
    assertions: 
      - key: tags[0].utan
        op: regex
        value: "^[0-9]{5}$"

Some of our repositories are trying to stay as DRY as possible in their code and heavily using built in Terraform features such as maps for defining tags.

variables.tf
variable "common_tags" { description = "Common resource tags." type = "map"

module.tf <-- Fails linting
tags = ${var.common_tags}

Where the variables are set and rendered on apply per environment:

main.tf
common_tags = "${map( "App", "App Name", "Product", "Product", "Team", "My Team", )}"

Having config-lint being able to render out the map would be fantastic as the alternative is to modify the rules to look for the required tags or $(var.common_tags) which feels like a band-aid.

running goreleaser shows a few deprecated notices:

• ARCHIVES
      • DEPRECATED: `archive` should not be used anymore, check https://goreleaser.com/deprecations#archive for more info.
• HOMEBREW TAP FORMULA
      • DEPRECATED: `brew` should not be used anymore, check https://goreleaser.com/deprecations#brew for more info.

See stelligent/cfn_nag#273

Setting IpProtocol: '-1' can produce unexpected results. Per the docs, when -1 is used, ToPort and FromPort are essentially ignored and access is granted on all ports from all protocols.

Terraform documentation shows a similar use of -1
https://www.terraform.io/docs/providers/aws/r/security_group.html

Add an is-subnet operator that can determine whether or not the value is a member of a given network.

This will be used to allow our Terraform SCA to check security group rules are within RFC1918 ranges.

Example:

...
  - id: SG1
    resource: aws_security_group
    message: Security group should not allow ingress from 0.0.0.0/0
    severity: FAILURE
    assertions:
      - key: "ingress[].cidr_blocks[] | [*]"
        op: is-subnet
        value: "10.0.0.0/8"
...

I am happy to implement this. Do you have any reqs for the design? Otherwise I can submit a PR for review. @lhitchon @jeffb4

Add a new Terraform rule:
S3 bucket access should be restricted to https only by policy.

Add a new Terraform rule:
AWS ALB listener should use https or tcp port 443.

Add a new Terraform rule:
CloudTrail logs should be using KMS encryption.

Add a new Terraform rule:
An SQS policy should not use a wildcard principal.

Add a max-host-count operations. This would be especially helpful in assessing CIDR blocks in configuration.

For example:

...
  - id: MAX_HOSTS_EXPOSED_PER_RULE
    message: All security group rules must expose less than 1016 hosts
    severity: FAILURE
    resource: aws_security_group_rule
    assertions:
      - every:
        key: "cidr_blocks"
        expressions:
          - key: "@"
            op: max-host-count
            value: 1016
...

Add a new Terraform rule:
An IAM policy should not use a wildcard action.

Add a new Terraform rule:
An IAM role policy should not use a wildcard resource.

The VS Code Remote Development environment needs more fine tuning and further customizations.

• Custom vscode extensions (and appropriate settings)
• git support
• non-root user
• load custom container image from stelligent Docker Hub

Add a new Terraform rule:
An ELB should have access logging configured to a central logs bucket.