Validate AWS CloudFormation yaml/json templates against the AWS CloudFormation Resource Specification and additionalchecks. Includes checking valid values for resource properties and best practices.
This is an attempt to provide validation for AWS CloudFormation templates properties andtheir values. For values things can get pretty complicated (mappings, joins, splits,conditions, and nesting those functions inside each other) so it's a best effort tovalidate those values but the promise is to not fail if we can't understand or translateall the things that could be going on.
The Serverless Application Model (SAM) is supported by the linter. The template istransformed using AWS SAM before the linter processes the template.
To get information about the SAM Transformation, run the linter with --info
Python 2.7+ and 3.5+ are supported.
pip install cfn-lint
. If pip is not available, runpython setup.py clean --all
then python setup.py install
.
brew install cfn-lint
In cfn-python-lint
source tree:
docker build --tag cfn-python-lint:latest .
In repository to be linted:
docker run --rm -v `pwd`:/data cfn-python-lint:latest /data/template.yaml
There are IDE plugins available to get direct linter feedback from you favorite editor:
cfn-lint template.yaml
cfn-lint -t template.yaml
Multiple files can be linted by either specifying multiple specific files:
cfn-lint template1.yaml template2.yaml
cfn-lint -t template1.yaml template2.yaml
or by using wildcards (globbing):
Lint all yaml
files in path
:
cfn-lint path/*.yaml
Lint all yaml
files in path
and all subdirectories (recursive):
cfn-lint path/**/*.yaml
Note: If using sh/bash/zsh, you must enable globbing.(setopt -s globstar
for sh/bash, setopt extended_glob
for zsh).
cfn-lint
will return a non zero exit if there are any issues with your template. The value is dependent on the severity of the issues found. For each level of discovered error cfn-lint
will use bitwise OR to determine the final exit code. This will result in these possibilities.
The template to be linted can also be passed using standard input:
cat path/template.yaml | cfn-lint -
cfn-lint -r us-east-1 ap-south-1 -- template.yaml
cfn-lint -r us-east-1 ap-south-1 -t template.yaml
From a command prompt run cfn-lint <path to template>
to run standard linting of the template.
It will look for a configuration file in the following locations (by order of preference):
.cfnlintrc
, .cfnlintrc.yaml
or .cfnlintrc.yml
in the current working directory~/.cfnlintrc
for the home directoryIn that file you can specify settings from the parameter section below.
Example:
templates:
- test/fixtures/templates/good/**/*.yaml
ignore_templates:
- codebuild.yaml
include_checks:
- I
custom_rules: custom_rules.txt
Optional parameters:
Command Line | Metadata | Options | Description |
---|---|---|---|
-h, --help | Get description of cfn-lint | ||
-z, --custom-rules | filename | Text file containing user-defined custom rules. See here for more information | |
-t, --template | filename | Alternative way to specify Template file path to the file that needs to be tested by cfn-lint | |
-f, --format | format | quiet, parseable, json, junit, pretty | Output format |
-l, --list-rules | List all the rules | ||
-r, --regions | regions | [REGIONS [REGIONS ...]], ALL_REGIONS | Test the template against many regions. Supported regions |
-b, --ignore-bad-template | ignore_bad_template | Ignores bad template errors | |
--ignore-templates | IGNORE_TEMPLATES [IGNORE_TEMPLATES ...] | Ignore templates from being scanned | |
-a, --append-rules | append_rules | [RULESPATH [RULESPATH ...]] | Specify one or more rules paths using one or more --append-rules arguments. Each path can be either a directory containing python files, or an import path to a module. |
-i, --ignore-checks | ignore_checks | [IGNORE_CHECKS [IGNORE_CHECKS ...]] | Only check rules whose ID do not match or prefix these values. Examples: - A value of W will disable all warnings- W2 disables all Warnings for Parameter rules.- W2001 will disable rule W2001 |
-e, --include-experimental | include_experimental | Whether rules that still in an experimental state should be included in the checks | |
-c, --include-checks | INCLUDE_CHECKS [INCLUDE_CHECKS ...] | Include rules whose id match these values | |
-m, --mandatory-checks | Rules to check regardless of ignore configuration | ||
-x, --configure-rule | CONFIGURE_RULES [CONFIGURE_RULES ...] | Provide configuration for a rule. Format RuleId:key=value. Example: E3012:strict=false | |
-D, --debug | Specify to enable debug logging. Debug logging outputs detailed information about rules processing, useful for debugging rules. | ||
-I, --info | Specify to enable logging. Outputs additional information about the template processing. | ||
-u, --update-specs | Update the CloudFormation Resource Specifications. You may need sudo to run this. You will need internet access when running this command | ||
-o, --override-spec | filename | Spec-style file containing custom definitions. Can be used to override CloudFormation specifications. More info here | |
-g, --build-graph | Creates a file in the same directory as the template that models the template's resources in DOT format | ||
-s, --registry-schemas | one or more directories of CloudFormation Registry Resource Schemas | ||
-v, --version | Version of cfn-lint |
To maintain backwards compatibility info
rules are not included by default. To include these rules you will need to include -c I
or --include-checks I
Inside the root level Metadata key you can configure cfn-lint using the supported parameters.
Metadata:
cfn-lint:
config:
regions:
- us-east-1
- us-east-2
ignore_checks:
- E2530
Inside a resources Metadata key you can configure cfn-lint to ignore checks. This will filter out failures for the resource in which the Metadata belongs. Keep in mind that AWS::Serverless
resources may lose metadata during the Serverless transform
Resources:
myInstance:
Type: AWS::EC2::Instance
Metadata:
cfn-lint:
config:
ignore_checks:
- E3030
Properties:
InstanceType: nt.x4superlarge
ImageId: ami-abc1234
cfn-lint applies configurations from several sources. The rules at lower levels are overridden by those at higher levels.
Certain rules support configuration properties. You can configure these rules by using configure_rules
parameter.
From the command line the format is RuleId:key=value
, for example: E3012:strict=false
.From the cfnlintrc or Metadata section the format is
Metadata:
cfn-lint:
config:
configure_rules:
RuleId:
key: value
The configurable rules have a non-empty Config entry in the table here.
There are getting started guides available in the documentation section to help with integrating cfn-lint
or creating rules.
This linter checks the AWS CloudFormation template by processing a collection of Rules, where every rule handles a specific function check or validation of the template.
This collection of rules can be extended with custom rules using the --append-rules
argument.
More information describing how rules are set up and an overview of all the Rules that are applied by this linter are documented here.
The linter supports the creation of custom one-line rules which compare any resource with a property using pre-defined operators. These custom rules take the following format:
<Resource Type> <Property[*]> <Operator> <Value> [Error Level] [Custom Error Message]
A separate custom rule text file must be created.
The example below validates example_template.yml
does not use any EC2 instances of size m4.16xlarge
custom_rule.txt
AWS::EC2::Instance InstanceSize NOT_EQUALS "m4.16xlarge" WARN "This is an expensive instance type, don't use it"
example_template.yml
AWSTemplateFormatVersion: "2010-09-09"
Resources:
myInstance:
Type: AWS::EC2::Instance
Properties:
InstanceType: m4.16xlarge
ImageId: ami-asdfef
The custom rule can be added to the configuration file or ran as a command line argument
The linter will produce the following output, running cfn-lint example_template.yml -z custom_rules.txt
:
W9001 This is an expensive instance type, don't use it
mqtemplate.yml:6:17
More information describing how custom rules are setup and an overview of all operators available is documented here.
The linter follows the AWS CloudFormation Resource Specifications by default. However, for your use case specific requirements might exist. For example, within your organisation it might be mandatory to use Tagging.
The linter provides the possibility to implement these customized specifications using the --override-spec
argument.
More information about how this feature works is documented here
If you'd like cfn-lint to be run automatically when making changes to files in your Git repository, you can install pre-commit and add the following text to your repositories' .pre-commit-config.yaml
:
repos:
- repo: https://github.com/aws-cloudformation/cfn-python-lint
rev: v0.54.2 # The version of cfn-lint to use
hooks:
- id: cfn-python-lint
files: path/to/cfn/dir/.*\.(json|yml|yaml)$
files:
line above, every json/yml/yaml file will be checked.