Custom Policies allow monitoring and enforcing of cloud infrastructure configuration in accordance with your organization's specific needs. For example, for certain resource types, you may want to enforce a tagging methodology or a special secure password policy; or you may want to restrict usage of a new service depending on the types of other services it is connected to.
Bridgecrew Cloud handles Custom Policies in a manner similar to the handling of built-in policies:
- They are checked in each scan.
- They are reflected in the Incident list.
- For each Incident, relevant information is displayed, including a list of affected Resources, Guidelines, statistics, etc.
- You can Suppress an Error by account, resource, tag, or for all instances.
- You can create a Jira issue for an incident.
Bridgecrew Tools for Creating Custom Policies
You can choose either:
Before building a Custom Policy you should gather the following:
Guidelines - as with built-in Policies, the Guidelines are displayed with the details of each Error to explain the issue to the user and related personnel for investigation and prevention in the future.
Benchmark (optional, only via Visual Policy Editor) - you can associate a Custom Policy with a benchmark and section. The Custom Policy will be checked in every scan but, when exporting Reports, will only appear in reports for the associated benchmark, in the section defined.
Cloud Provider and Resource Type - each Custom Policy must be associated with a Provider and specific Resource Type.
Details for Policy Definition - attributes, values, and resource connection types to be checked.
The Bridgecrew platform utilizes the Terraform attribute library and syntax. See the Terraform Registry for lists of supported attributes and connection types per cloud provider.
Custom policies include:
- Metadata - Policy name, guidelines, severity and category.
- Scope - cloud provider to which the Policy is applied
- Definition - the conditions and logic for compliance with the Policy.
The table below presents examples of Custom Policies.
|azurerm-block-allow-all-cidr||azurerm||azurerm_network_security_group||source_address_prefix||Not Equal||0.0.0.0/0, "*"|
|aws-networking-deny-public-ssh - see note below||aws||aws_security_group_rule||cidr_blocks||Not equal||0.0.0.0/0|
The Custom Policy "aws-networking-deny-public-ssh" uses 2 rules with arguments for cidr_blocks and to_port.
You can create Policies with as many nested arguments as needed.
For example to express a more complex ingress policy for an AWS security group you could use all of the following arguments:
Updated over 1 year ago