The Control Group resource provides a mechanism for grouping controls into control frameworks, and into sections within a control framework. For instance, the AWS mod will have separate top-level control groups for CIS, NIST, PCI, etc. Each of these control groups may have sub-level control groups to organize controls to reflect that particular framework - one for each section or subsection in CIS, one fore each CSF Core Function and subcategory for NIST, etc.
By default, controls will be grouped with aggregated totals at each control group, though an alternate grouping may be selected if desired. A control_group may specify a single control_group as a parent. If no parent is specified, then the control group is a child of the mod.
Because control groups are resources, you can run them or refer to them with hcl syntax as {mod}.control_group.{name}. The name must be unique in the namespace (mod). Typically, controls and control groups in a given framework should be named in a way that mimics the hierarchy in order to provide an easy to follow structure. This is a convention that we will follow, but not a strict requirement. For example:
# run all the cis controls
steampipe check aws.control_group.cisv130
# run all cis section 2 controls
steampipe check aws.control_group.cisv130_2
# run all cis section 2.1 controls
steampipe check aws.control_group.cisv130_2_1
Control Group Arguments
Argument
Description
title
Optional
Display title
description
Optional
A longer description of the control
parent
Optional
The parent control group. If none is specified, the control group parent is the mod.
labels
Optional
An array of metadata specific to the framework. This structure is up to the mod author and varies by framework and provider. While labels are just strings, a colon may be used as a delimiter to signify key:value.
The Control Group resource provides a mechanism for grouping controls into control frameworks, and into sections within a control framework. For instance, the AWS mod will have separate top-level control groups for CIS, NIST, PCI, etc. Each of these control groups may have sub-level control groups to organize controls to reflect that particular framework - one for each section or subsection in CIS, one fore each CSF Core Function and subcategory for NIST, etc.
By default, controls will be grouped with aggregated totals at each control group, though an alternate grouping may be selected if desired. A
control_group
may specify a singlecontrol_group
as aparent
. If no parent is specified, then the control group is a child of the mod.Because control groups are resources, you can run them or refer to them with hcl syntax as
{mod}.control_group.{name}
. The name must be unique in the namespace (mod). Typically, controls and control groups in a given framework should be named in a way that mimics the hierarchy in order to provide an easy to follow structure. This is a convention that we will follow, but not a strict requirement. For example:You may run all controls in a group:
Control Group Arguments
key:value
.