Convert Figma logo to code with AI

aws-cloudformation logocfn-lint

CloudFormation Linter

2,426
586
2,426
70

Top Related Projects

CloudFormation Linter

1,254

Linting tool for CloudFormation templates

1,163

Test all the CloudFormation things! (with TaskCat)

6,861

Prevent cloud misconfigurations and find vulnerabilities during build-time in infrastructure as code, container images and open source packages with Checkov by Bridgecrew.

Quick Overview

cfn-lint is a tool for validating AWS CloudFormation templates. It checks for errors, best practices, and provides suggestions for improvements in CloudFormation YAML and JSON templates. This linter helps developers catch issues early in the development process, ensuring more reliable and efficient infrastructure-as-code deployments.

Pros

  • Improves CloudFormation template quality and reduces deployment errors
  • Supports both YAML and JSON formats
  • Integrates with popular IDEs and CI/CD pipelines
  • Regularly updated to support new AWS resources and best practices

Cons

  • May produce false positives in complex or edge-case scenarios
  • Learning curve for understanding and customizing rules
  • Limited support for third-party or custom resources
  • Can be slow when processing large templates or multiple files

Code Examples

  1. Basic usage:
from cfnlint import Template, Runner

template = Template('path/to/template.yaml')
rules = Runner.create_rules()
matches = Runner.run(rules, template)

for match in matches:
    print(match)
  1. Custom rule implementation:
from cfnlint.rules import CloudFormationLintRule

class MyCustomRule(CloudFormationLintRule):
    id = 'E9000'
    shortdesc = 'My custom rule'
    description = 'Checks for a specific condition in the template'

    def match(self, cfn):
        matches = []
        # Add your custom logic here
        return matches
  1. Using cfn-lint as a pre-commit hook:
# .pre-commit-config.yaml
repos:
  - repo: https://github.com/aws-cloudformation/cfn-lint
    rev: v0.72.2
    hooks:
      - id: cfn-lint
        files: path/to/cloudformation/templates/
        args: [--format, parseable]

Getting Started

To get started with cfn-lint, follow these steps:

  1. Install cfn-lint:

    pip install cfnlint
    
  2. Run cfn-lint on a CloudFormation template:

    cfn-lint path/to/template.yaml
    
  3. To integrate with your IDE, install the appropriate extension (e.g., VS Code CloudFormation Linter).

  4. For CI/CD integration, add cfn-lint to your pipeline scripts or use pre-commit hooks as shown in the code examples.

Competitor Comparisons

CloudFormation Linter

Pros of cfn-lint

  • More comprehensive linting rules and checks for CloudFormation templates
  • Actively maintained with frequent updates and bug fixes
  • Supports custom rule creation for organization-specific requirements

Cons of cfn-lint

  • Can be slower for large templates due to extensive rule checking
  • May produce false positives in some edge cases
  • Steeper learning curve for advanced features and custom rule creation

Code Comparison

cfn-lint:

Resources:
  MyBucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: my-unique-bucket-name

cfn-lint>:

Resources:
  MyBucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: !Ref BucketNameParameter

The code comparison shows that cfn-lint can detect hardcoded values in resource properties, while cfn-lint> might not flag this as an issue. cfn-lint encourages the use of parameters for better template flexibility and reusability.

Both tools aim to improve CloudFormation template quality, but cfn-lint offers more extensive checks and customization options. However, this comes at the cost of potentially slower performance and a steeper learning curve. cfn-lint> might be simpler to use for basic linting needs but may not catch as many potential issues or best practice violations.

1,254

Linting tool for CloudFormation templates

Pros of cfn_nag

  • Focuses specifically on security and compliance issues in CloudFormation templates
  • Provides more detailed security checks and best practices enforcement
  • Easier to integrate into CI/CD pipelines with its command-line interface

Cons of cfn_nag

  • Limited to security and compliance checks, lacking general template validation
  • May produce more false positives due to its strict security focus
  • Less frequent updates compared to cfn-lint

Code Comparison

cfn_nag example:

require 'cfn-nag'
cfn_nag = CfnNag.new

violations = cfn_nag.audit_file('/path/to/cloudformation.yaml')
violations.each do |violation|
  puts "#{violation.type} #{violation.message}"
end

cfn-lint example:

from cfnlint import Runner, decode_filename

filename = 'path/to/cloudformation.yaml'
template, _ = decode_filename(filename)
rules = RulesCollection()
runner = Runner(rules, filename, template)
matches = list(runner.run())

for match in matches:
    print(f"{match.rule.id} {match.message}")

Both tools provide similar functionality for linting CloudFormation templates, but cfn_nag focuses more on security aspects while cfn-lint offers broader validation capabilities. The choice between them depends on specific project requirements and the desired level of security scrutiny.

1,163

Test all the CloudFormation things! (with TaskCat)

Pros of taskcat

  • Provides end-to-end testing of CloudFormation templates by deploying resources
  • Supports multi-region testing for better coverage
  • Offers built-in test reporting and result visualization

Cons of taskcat

  • Requires more setup and configuration compared to cfn-lint
  • May incur AWS costs due to resource deployment during tests
  • Limited to CloudFormation template testing, while cfn-lint can check other AWS-related files

Code Comparison

taskcat configuration (.taskcat.yml):

project:
  name: my-project
  regions:
    - us-east-1
    - us-west-2
tests:
  my-test:
    template: templates/my-template.yaml
    parameters:
      ParameterKey: ParameterValue

cfn-lint usage:

cfn-lint template.yaml

taskcat focuses on deploying and testing CloudFormation templates in real AWS environments, while cfn-lint performs static analysis without resource creation. taskcat is better suited for comprehensive testing, including resource interactions, while cfn-lint excels at quick syntax and best practice checks. Choose taskcat for thorough, multi-region testing of complex templates, and cfn-lint for rapid validation during development or CI/CD pipelines.

6,861

Prevent cloud misconfigurations and find vulnerabilities during build-time in infrastructure as code, container images and open source packages with Checkov by Bridgecrew.

Pros of Checkov

  • Supports multiple IaC formats (Terraform, CloudFormation, Kubernetes, etc.)
  • Offers pre-built policies for various compliance standards (CIS, HIPAA, SOC2)
  • Integrates with CI/CD pipelines and provides machine-readable output

Cons of Checkov

  • May have a steeper learning curve due to its broader scope
  • Can be slower for large codebases due to comprehensive checks
  • Requires more setup and configuration for specific use cases

Code Comparison

cfn-lint example:

Resources:
  MyBucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: my-unique-bucket-name

Checkov example:

resource "aws_s3_bucket" "my_bucket" {
  bucket = "my-unique-bucket-name"
  acl    = "private"
}

Both tools can detect issues like naming conventions and security misconfigurations, but Checkov's broader scope allows it to check for additional concerns across multiple IaC formats.

Convert Figma logo designs to code with AI

Visual Copilot

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

AWS CloudFormation Linter

[cfn-lint logo]

Testing PyPI version PyPI downloads PyPI downloads codecov Discord Shield

Validate AWS CloudFormation yaml/json templates against the AWS CloudFormation resource provider schemas and additional checks. Includes checking valid values for resource properties and best practices.

Warning

This is an attempt to provide validation for AWS CloudFormation templates properties and their 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 to validate those values but the promise is to not fail if we can't understand or translate all the things that could be going on.

Contribute

We encourage you to contribute to cfn-lint! Please check out the Contributing Guidelines for more information on how to proceed.

Community

Join us on Discord! Connect & interact with CloudFormation developers & experts, find channels to discuss and get help for cfn-lint, CloudFormation registry, StackSets, Guard and more:

Join our Discord

Serverless Application Model

The Serverless Application Model (SAM) is supported by the linter. The template is transformed using AWS SAM before the linter processes the template.

To get information about the SAM Transformation, run the linter with --info

Install

Python 3.8+ is supported.

Pip

pip install cfn-lint. If pip is not available, run python setup.py clean --all then python setup.py install.

Optional dependencies

cfn-lint has optional dependencies based on certain features you may need.

  • pip install cfn-lint[full] for installing all the optional dependencies. This will install all the dependencies for graph, junit, and sarif.
  • pip install cfn-lint[graph] for installing pydot to draw and output template graphs
  • pip install cfn-lint[junit] for installing the packages to output the junit format
  • pip install cfn-lint[sarif] for installing the packages to output the sarif format

Homebrew (macOS)

brew install cfn-lint

Docker

In cfn-lint source tree:

docker build --tag cfn-lint:latest .

In repository to be linted:

docker run --rm -v `pwd`:/data cfn-lint:latest /data/template.yaml

Editor Plugins

There are IDE plugins available to get direct linter feedback from you favorite editor:

GitHub Action

Online demo

Basic Usage

  • 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. (shopt -s globstar for sh/bash, setopt extended_glob for zsh).

Exit Codes

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.

  • 0 is no issue was found
  • 2 is an error
  • 4 is a warning
  • 6 is an error and a warning
  • 8 is an informational
  • 10 is an error and informational
  • 12 is an warning and informational
  • 14 is an error and a warning and an informational
Configuring Exit Codes

cfn-lint allows you to configure exit codes. You can provide the parameter --non-zero-exit-code with a value of informational, warning, error, or none. cfn-lint will determine the exit code based on the match severity being the value of the parameter --non-zero-exit-code and higher. The exit codes will remain the same as above.

The order of severity is as follows:

  1. informational default
  2. warning
  3. error
  4. none Exit code will always be 0 unless there is a syntax error
Specifying the template as an input stream

The template to be linted can also be passed using standard input:

  • cat path/template.yaml | cfn-lint -
Specifying the template with other parameters
  • cfn-lint -r us-east-1 ap-south-1 -- template.yaml
  • cfn-lint -r us-east-1 ap-south-1 -t template.yaml

Configuration

Command Line

From a command prompt run cfn-lint <path to template> to run standard linting of the template.

Config File

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 directory

In 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

Parameters

Optional parameters:

Command LineMetadataOptionsDescription
-h, --helpGet description of cfn-lint
-z, --custom-rulesfilenameText file containing user-defined custom rules. See here for more information
-t, --templatefilenameAlternative way to specify Template file path to the file that needs to be tested by cfn-lint
-f, --formatformatquiet, parseable, json, junit, pretty, sarifOutput format
-l, --list-rulesList all the rules
-r, --regionsregions[REGIONS [REGIONS ...]], ALL_REGIONSTest the template against many regions. Supported regions
-b, --ignore-bad-templateignore_bad_templateIgnores bad template errors
--ignore-templatesIGNORE_TEMPLATES [IGNORE_TEMPLATES ...]Ignore templates from being scanned
-a, --append-rulesappend_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-checksignore_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-experimentalinclude_experimentalWhether rules that still in an experimental state should be included in the checks
-c, --include-checksINCLUDE_CHECKS [INCLUDE_CHECKS ...]Include rules whose id match these values
-m, --mandatory-checksRules to check regardless of ignore configuration
--non-zero-exit-codeinformational (default), warning, error, none]Exit code will be non zero from the specified rule class and higher
-x, --configure-ruleCONFIGURE_RULES [CONFIGURE_RULES ...]Provide configuration for a rule. Format RuleId:key=value. Example: E3012:strict=true
-D, --debugSpecify to enable debug logging. Debug logging outputs detailed information about rules processing, useful for debugging rules.
-I, --infoSpecify to enable logging. Outputs additional information about the template processing.
-u, --update-specsUpdate the CloudFormation resource provider schemas. You may need sudo to run this. You will need internet access when running this command
-o, --override-specfilenameSpec-style file containing custom definitions. Can be used to override CloudFormation specifications. More info here
-g, --build-graphCreates a file in the same directory as the template that models the template's resources in DOT format
-s, --registry-schemasone or more directories of CloudFormation Registry Resource Schemas
-v, --versionVersion of cfn-lint

Info Rules

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

Metadata

Template Based Metadata

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

Resource Based Metadata

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

Precedence

cfn-lint applies configurations from several sources. The rules at lower levels are overridden by those at higher levels.

  1. cfnlintrc configurations
  2. Template Metadata configurations
  3. CLI parameters

Configure Rules

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=true. 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.

Getting Started Guides

There are getting started guides available in the documentation section to help with integrating cfn-lint or creating rules.

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.

Custom Rules

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]

Example

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 InstanceType 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.

Customize specifications

The linter follows the AWS CloudFormation resource provider schemas 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

pre-commit

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-lint
    rev: v1.12.4 # The version of cfn-lint to use
    hooks:
      - id: cfn-lint
        files: path/to/cfn/dir/.*\.(json|yml|yaml)$

If you are using a .cfnlintrc and specifying the templates or ignore_templates we would recommend using the .cfnlintrc exlusively to determine which files should be scanned and then using:

repos:
  - repo: https://github.com/aws-cloudformation/cfn-lint
    rev: v1.12.4 # The version of cfn-lint to use
    hooks:
      - id: cfn-lint-rc

Note: When mixing .cfnlintrc ignore_templates and files option in your .pre-commit-config.yaml cfn-lint may return a file not found error

  • If you exclude the files: line above, every json/yml/yaml file will be checked.
  • You can see available cfn-lint versions on the releases page.