Bridgecrew.io
  • About Bridgecrew by Prisma Cloud
Checkov home
  • Docs
    • Quick start
    • Overview
    • Integrations
  • Download
  • Try Bridgecrew
  • Docs
    • Quick start
    • Overview
    • Integrations

Checkov Documentation

  • 1.Welcome
    • What is Checkov?
    • Terms and Concepts
    • Quick Start
    • Feature Descriptions
  • 2.Basics
    • Installing Checkov
    • CLI Command Reference
    • Suppressing and Skipping Policies
    • Hard and soft fail
    • Scanning Credentials and Secrets
    • Reviewing Scan Results
    • Visualizing Checkov Output
    • Handling Variables
  • 3.Custom Policies
    • Custom Policies Overview
    • Python Custom Policies
    • Create Custom Policy - YAML - Attribute Check and Composite
      • Policy Definition
      • Types of Definition Blocks
        • Using AND/OR Logic
        • Using NOT Logic
      • Attribute Blocks
        • Attribute Block Example
        • Attribute Condition: Operators
        • Attribute Condition: Keys and Values
        • Evaluating list attributes
      • Connection State Block
        • Connection State Example
        • Connection State Condition: Operators
        • Connection State Condition: Keys and Values
      • Filters
        • Filter Example
      • Using AND/OR Logic
        • Example
      • Using NOT Logic
        • Example
    • Custom YAML Policies Examples
    • Sharing Custom Policies
  • 4.Integrations
    • Jenkins
    • Bitbucket Cloud Pipelines
    • Github Actions
    • GitLab CI
    • Kubernetes
    • Pre-Commit
    • Docker
  • 5.Policy Index
    • all resource scans
    • arm resource scans
    • bicep resource scans
    • bitbucket_configuration resource scans
    • bitbucket_pipelines resource scans
    • cloudformation resource scans
    • dockerfile resource scans
    • github_actions resource scans
    • github_configuration resource scans
    • gitlab_ci resource scans
    • gitlab_configuration resource scans
    • kubernetes resource scans
    • openapi resource scans
    • secrets resource scans
    • serverless resource scans
    • terraform resource scans
  • 6.Contribution
    • Checkov Runner Contribution Guide
    • Implementing CI Metadata extractor
    • Implementing ImageReferencer
    • Contribution Overview
    • Contribute Python-Based Policies
    • Contribute YAML-based Policies
    • Contribute New Terraform Provider
    • Contribute New Argo Workflows configuration policy
    • Contribute New Bitbucket configuration policy
    • Contribute New GitHub configuration policy
    • Contribute New Gitlab configuration policy
  • 7.Scan Examples
    • Terraform Plan Scanning
    • Helm
    • Kustomize
    • AWS SAM configuration scanning
    • Argo Workflows configuration scanning
    • Azure ARM templates configuration scanning
    • Azure Bicep configuration scanning
    • Bitbucket configuration scanning
    • AWS CDK configuration scanning
    • Cloudformation configuration scanning
    • Dockerfile configuration scanning
    • GitHub configuration scanning
    • Gitlab configuration scanning
    • Kubernetes configuration scanning
    • OpenAPI configuration scanning
    • SCA scanning
    • Serverless framework configuration scanning
  • 8.Outputs
    • CycloneDX BOM
    • JUnit XML
  • 9.Level up
    • Upgrade from Checkov to Bridgecrew
  • Docs
  • 3.custom policies
  • YAML Custom Policies
Edit on GitHub

Create Custom Policy - YAML - Attribute Check and Composite

Custom policies created in YAML support checking a resource’s connection state and the use of complex AND/OR logic. Read also how to create custom Python Policies for attribute scanning.

A YAML-based custom policy for Checkov consists of sections for the Metadata and Policy Definition.

Metadata

The Metadata includes:

  • Policy Name
  • ID - CKV2_<provider>_<number>
  • Category

The possible values for category are:

  • GENERAL_SECURITY
  • LOGGING
  • ENCRYPTION
  • NETWORKING
  • IAM
  • BACKUP_AND_RECOVERY
  • CONVENTION
  • SECRETS
  • KUBERNETES

Policy Definition

The policy definition consists of:

  • Definition Block(s) - either Attribute Block(s) or Connection State Block(s) or both
  • Logical Operator(s) (optional)
  • Filter(optional)

The top level object under definition must be a single object (not a list). It can be an attribute block, a connection block, or a logical operator (and, or, not).

Types of Definition Blocks

  • Attribute Blocks: The policy describes resources with a certain configuration as defined by a configuration attribute and its value (per Terraform), or by the presence/absence of an attribute.
  • Connection State Blocks - The policy describes resources in a particular Connection state; either connected or not connected to another type of resource (for example, a security group).

Using AND/OR Logic

A policy definition may include multiple blocks (Attribute, Connection state or both), associated by AND/OR logic.

Using NOT Logic

A policy definition may include any block (Attribute, Connection state, or AND/OR) underneath a not block to invert the statement.

Attribute Blocks

An Attribute Block in a policy’s definition indicates that a resource will be non-compliant if a certain configuration attribute does not have a specified value or if it exists/doesn’t exist.

Bridgecrew’s custom policies in code utilize the Terraform attribute library and syntax. These policies are checked during scans of both build-time and runtime resources and for all supported cloud providers.

Attribute Block Example

The Attribute Block in the definition in the example below is used to ensure that a proper back-up policy is configured for Redshift clusters:

definition:
     cond_type: "attribute"
     resource_types:
     - "aws_redshift_cluster"
     attribute: "automated_snapshot_retention_period"
     operator: "not_equals"
     value: "0"

Attribute Condition: Operators

Operator Value in YAML
Equals equals
Not Equals not_equals
Regex Match regex_match
Not Regex Match not_regex_match
Exists exists
Not Exists not_exists
One Exists one_exists
Any any
Contains contains
Not Contains not_contains
Within within
Starts With starting_with
Not Starts With not_starting_with
Ends With ending_with
Not Ends With not_ending_with
Greater Than greater_than
Greater Than Or Equal greater_than_or_equal
Less Than less_than
Less Than Or Equal less_than_or_equal
Subset subset
Not Subset not_subset
Json Path Equals jsonpath_equals
Json Path Not Equals jsonpath_not_equals
Json Path Exists jsonpath_exists
Json Path Not Exists jsonpath_not_exists
Is Empty is_empty
Is Not Empty is_not_empty

Attribute Condition: Keys and Values

Key Type Value(s)
cond_type string Must be attribute
resource_type collection of strings Use either all or [resource types from list]
attribute string Attribute of defined resource types. For example, automated_snapshot_retention_period
operator string - equals, not_equals, regex_match, not_regex_match, exists, not exists, any, contains, not_contains, within, starting_with, not_starting_with, ending_with, not_ending_with, greater_than, greater_than_or_equal, less_than, less_than_or_equal, jsonpath_equals, jsonpath_not_equals, jsonpath_exists, jsonpath_not_exists, is_empty, is_not_empty
value (not relevant for operator: exists/not_exists) string User input.

Evaluating list attributes

You may use a wildcard (*) to evaluate all of the items within a list. You may use multiple wildcards to evaluated nested lists. If any item in the list matches the condition, then the condition passes.

For example, consider the following resource:

resource "aws_security_group" "sg" {
  ...
  ingress {
    cidr_blocks = ["0.0.0.0/0"]
    ...
  }
  ingress {
    cidr_blocks = ["192.168.1.0/24"]
    ...
  }
}

The following definition will return true, because one of the CIDR blocks contains 0.0.0.0/0:

cond_type: attribute
resource_types:
  - "aws_security_group"
attribute: "ingress.*.cidr_blocks"
operator: "contains"
value: "0.0.0.0/0"

Note that switching the operator to not_contains will still result in the evaluation being true, because there is also an element that does not contain 0.0.0.0/0. If you want to write a policy that fails if any CIDR block contains 0.0.0.0/0, consider the not operator, described below.

Connection State Block

A Connection State Block indicates a type of resource that has or does not have a connection to another type of resource. In the example presented in the table below, in order to be compliant, aws_lb and aws_elb must have connections to either aws_security_group or aws_default_security_group.

Group A Group B
aws_lb aws_elb aws_security_group aws_default_security_group

Connection State Example

The Connection State Block below indicates that to be compliant with the policy, resources of type aws_lb or of type aws_elb must be connected to either a resource of type aws_security_group or a resource of type aws_default_security_group.

definition:
       cond_type: "connection"
       resource_types:
           - "aws_elb"
           - "aws_lb"
       connected_resource_types:
         - "aws_security_group"
         - "aws_default_security_group"
       operator: "exists"

Connection State Condition: Operators

Operator Value
Exists exists
Not Exists not_exists

Connection State Condition: Keys and Values

Key Type Values
cond_type string Must be connection
resource_types   Use either all or [included resource type from list]
connected_resource_types collection of strings Use either all or [included resource type from list]
operator string exists/not exists

Filters

Filters can be used to limit the types of resources relevant to a condition. Filters are most commonly used for Connection Blocks (for Attribute Blocks you can easily limit the resource type with the resource_type parameter). For example, you may want to enforce a policy only for a specific resource type (or types) from specific groups defined in the conditions. Filters are available only for AND logic at the top level.

Filter Example

The Custom Policy in this example ensures that all ELBs are attached to security groups as shown in the table below. In line with best practices, connections of this nature should be defined using the security_groups key.

Group A Group B
aws_elb aws_security_group aws_default_security_group
Not Exists not_exists
definition:
 and:
      - cond_type: "filter"
        attribute: "resource_type"
        value:
           - "aws_elb"
        operator: "within"
      - cond_type: "connection"
        resource_types:
           - "aws_elb"
        connected_resource_types:
         - "aws_security_group"
         - "aws_default_security_group"
        operator: "exists"

Note: The condition above uses AND logic. See additional examples for complex logic in policy definitions.

Using AND/OR Logic

The Bridgecrew platform allows you to combine definition blocks using AND/OR operators.

  • The top-level logical operator is the first key below "definition" (and not an item in a collection). Most policies will start with an and or or key here, with multiple conditions nested within that.
  • Filter blocks apply (only) to the top-level and constitute an AND condition. For example, if you’d like to indicate a requirement for a Connection State between types of resources, but only within a certain subset of all of those resources. Every other logical operator applies within a collection. For example, you can use AND/OR logic in a collection of key-value pairs.
  • The value for the and or or key must be a list; each element of the list must be a valid definition on its own (i.e., a combination of attribute conditions, connection conditions, nested AND/OR, etc).

Example

The logic in the policy definition shown below is: AND[block 1,block 2,OR[block 3,block 4]].

#....
defintion:
  and:
  - #filter block 1
  - #block 2
  - or:
    - #block 3
    - #block 4

See all examples of Custom Policies in code

Using NOT Logic

You can use not in the same places that you may use and and or to invert the nested condition definition. The value of the not element in the policy may be either a list containing exactly one element (which can also be nested more deeply), or any other type of block.

Example

The definition below inverts the example in the previous section.

#....
defintion:
  not:
    and:
    - #filter block 1
    - #block 2
    - or:
      - #block 3
      - #block 4

The following code is also valid (the child of not is a list of length 1):

#....
defintion:
  not:
  - and:
    - #filter block 1
    - #block 2
    - or:
      - #block 3
      - #block 4

See all examples of Custom Policies in code

Powered By

  • Slack Community
  • About Bridgecrew
  • Platform
  • Terms of use
  • GitHub
  • Docs
  • Contact Us
  • Privacy policy