stelligent / cfn_nag

Linting tool for CloudFormation templates
MIT License
1.25k stars 209 forks source link

Contributing custom cfn_nag rules #548

Open rakshb opened 3 years ago

rakshb commented 3 years ago

Hi!

I work at AWS and we've been using cfn_nag in our CI/CD pipelines. We've noticed more common patterns and we think it would be beneficial to add a few custom rules to cfn_nag so that we can catch these problems earlier in the development process of CloudFormation templates.

Here are the patterns we identified so far:

Would these patterns be a good addition to cfn_nag? If so, we would like to contribute by sending PRs for these proposed additions. Can we create one PR for all these rules? Thanks in advance!

arothian commented 3 years ago

Hi, thanks for the recommendations! We would be happy to review PRs for proposed rule additions. Some feedback on your specific rules below. Preference would be for different PRs per rule.

If the S3 bucket is configured as a static website, the client should implement secure http header [FAILURE]

This seems like a general best practice that would make a good rule.

If a bucket is configured as a static website, it should be fronted by a CloudFront distribution with an origin access identity [FAILURE]

I think this is a more specific use-case. You should be able to still enforce this as a custom rule in your own setup.

Multiple Lambda functions should not use the same IAM roles [FAILURE]

Seems like a good fit. General idea being that each function's permissions should be reduced to least privilege and it is unlikely that two functions require the exact same permissions. This might be somewhat hard to enforce as it depends on having the differing lambda functions in the same stack, but that is beyond the scope of what cfn_nag currently reviews.

AWS Lambda function should log application information to CloudWatch to catch issues [WARNING]

This would potentially occur if the execution role was missing cloudwatch log permissions? Seems like a good rule if it can be detected straightforwardly.

If there are service integrations with the Lambda function (eg. API Gateway) that supports tracing, AWS X-ray should be enabled to support tracing for the customer [WARNING]

I think this is also potentially useful. It would trigger under situations where tracing is enabled on the API Gateway stage but not on the associated lambda?