Code Editor
Prisma Cloud’s Code Editor allows you to define advanced custom policies for build-time checks. Users can leverage YAML templates, logic operators, and framework support to create complex policies tailored to specific compliance or security requirements.
The Code Editor is a suitable option when you want to create complex custom policies that include both Attribute and Connection-State with a support of AND/OR logic. However, for custom secrets Code Editor supports only an OR logic.
How to Create Custom Policies
Select Governance > Add Policy > Config > Add Policy Details* and then select Next.
The Code Editor provides a default view with an example of a YAML template. See YAML Policy Attribute below for details of the YAML file attributes.
Select More Options and then select Clear Editor to remove the YAML template example.
Add your custom YAML code.
Select Test to test your custom code.
Each test displays up to 30 results. Prisma Cloud scans all integrated repositories to identify resources that match your custom policy, providing a maximum of 30 results per test. You can review these results for detailed information about impacted resources and misconfigurations. If your custom code contains errors, the console will display suggested solutions.
Select Validate and Next to access Compliance Standards to complete the custom Build-time check policy.
You are in Step 2 of Create Custom Policies for Build-Time Checks. You are required to complete the rest of the steps to see your new custom Build-time check policy on the Prisma Cloud console.
YAML Policy Attributes
The Yaml file includes the following arguments:
guidelines: Sets general rules for policy creation
category: Specifies the type of policy
frameworks: Identifies the applicable framework. If no framework is specified, the policy applies to all frameworks. If a framework is specified, the policy applies only to the selected framework
scope: Defines the level of applicability for the policy
provider: Specifies the cloud provider or source for the resources
definition: Contains the logic and conditions for the policy, including attributes, operators, and resource connections
Limitation
Nesting connection condition types within a 'NOT' block is not currently supported.
EXAMPLE
Key Capabilities of the Code Editor
Attribute-Based Policies
Attribute when defined in a policy describes attribute configurations for resources. Each resource must contain values the attribute configuration has specified or display the presence or absence of the attribute configuration. The syntax and attribute configurations used in YAML templates is similar to Terraform.
In this example, the attribute defines a back-up configuration for Redshift clusters.
The table below provides instructions on how to use Attributes with matching keys and values.
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_exists, intersects, not_intersects
Value (not relevant for operator: exists, not_exists)
string
User input
The table below provides instructions on how to use Attribute Operators.
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 Exists
jsonpath_exists
Intersects
intersects
Not Intersects
not_intersects
Attribute Operators support IaC scans. The regex operator can be implicitly used for Secrets. As seen in this example, there is no "regex" explicitly defined. It’s implicit when creating a secret policy.
Connection-Based Policies
Connection State when defined in a policy specifies a connect or disconnect between resources of different types.
In this example, aws_lb and aws_elb must have connection with aws_security_group or aws_default_secuirty_group to be compliant.
The table below provides instructions on how to use Connection State types.
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
The table below provides instructions on how to use Connection State Operators.
Exists
exists
Not Exists
not_exists
Logical (AND/OR) Operators
A policy may include layers of defined Attributes and Connection State, or both. To define the connection between the two AND/OR logic is used. Using Code Editor you can customize the Attribute, Connection State or both at multiple layers.
In this example, you see the both AND/OR logic applied to Attribute.
In this example, you see the AND/OR logic applied to both Attribute and the Connection State.
In this example, you see the OR logic applied to Custom Secrets.
Last updated
Was this helpful?

