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

Attribute Condition: Keys and Values

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.

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

Connection State Condition: Keys and Values

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.

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