First glance at AWS CloudFormation Guard 2.0
Yesterday AWS CloudFormation Guard version 2.0 was introduced. Guard is an open source tool that can be used to validate CloudFormation templates against certain rules. You can use it for linting your templates both on syntax and semantics. Linting tools are essential in CI/CD pipelines and an powerful addition when it comes to validating structured and human-readable files such as JSON and YAML. In your delivery pipelines you would preferably run linting tests as early as possible, before proceeding to steps such as compile and deploy steps et cetera(fail-fast).
If you zoom out a little bit and look to the entire governance process linting tools can help you making big steps in shifting-left. This means that you want to report your findings as early in the development phase as possible. In this case linting tests should be run as soon as possible. You want to enforce your requirements before actual deployments are made.
Linting tests can include a large number of validation steps. Most obvious ones are security related, to enforce encryption and enabled auto-patching for example. But you can also think of enforcing best practices, such as mandatory tagging. Last but not least you can also include company specific requirements such as naming conventions.
As per usual AWS doesn’t provide a single tool for a purpose. For linting CloudFormation another, maybe better known, tool is CloudFormation Linter (cfn-lint). There is a lot of overlap between the two tools, but also some noticeable differences. I believe the biggest differences are that cfn-lint can be solely used to lint CloudFormation templates while cfn-guard can be used to lint any JSON or YAML file. With cfn-guard you can potentially validate Helm Charts (Kubernetes container definitions) or maybe even Terraform JSON files. Another noticeable difference is that cfn-guard doesn’t come with pre-built rules, while cfn-lint is pretty usable of the shelf.
Looking at maturity levels: I find the Unit testing framework in cfn-guard pretty valuable. Nothing is as annoying as linting rules causing false-positives or unpredictable behaviour. Also the fact that you can group rules together. This can help, for example, to distinguish between security and best practices rules. Writing and using unit tests can really help to get that consistent experience among your users.
What I find a bit clumsy is that the tool itself is written in Rust. If you opensource a tool and give it to the community it might be a logical choice to use a common language like Python or JavaScript, so that a large group of developers can contribute. Also many other AWS projects/tools are written in Python or JavaScript (or even Go).
Finally checkout my GitHub repo for some examples on how to use cfn-guard in a Docker container. It also includes an example rule and Unit test.
About me
As a cloud evangelist at Oblivion Cloud Control, my passion is to share knowledge and enable, embrace and accelerate the adoption of public cloud. In my personal life I’m a dad and a horrible sim racer.