For the complete documentation index, see llms.txt. This page is also available as Markdown.

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

  1. 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.

  2. Select More Options and then select Clear Editor to remove the YAML template example.

  3. Add your custom YAML code.

  4. 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.

  5. 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.

Key
Type
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.

Attribute Operators
YAML values

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.

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

The table below provides instructions on how to use Connection State Operators.

Connection State Operators
YAML values

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?