Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[CAS] Added ARM framework to custom build policies #1015

Merged
merged 8 commits into from
Dec 3, 2024
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Next Next commit
Initial commit
JBakstPaloAlto committed Dec 3, 2024
commit 439aa90b2a60036f9a5f439fe0d5b869b1841067
Original file line number Diff line number Diff line change
@@ -3,7 +3,8 @@
[.task]
== Code Editor

Prisma Cloud supports Code Editor capability where you can create a policy rule for custom Configuration policies during Build-time checks. Code Editor is the default view for Build policy rule and as an example a YAML policy template is always available on the Prisma Cloud console.
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
@@ -14,9 +15,18 @@ The Code Editor is a suitable option when you want to create complex custom poli
//+
//image::governance/code-editor.png
+
The Code Editor is as a default view with an example of a YAML template.
+
In this example, you see the YAML template with custom secrets where `secrets` is a `category`.
The Code Editor provides a default view with an example of a YAML template.

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
//+
//In this example, you see the YAML template with custom secrets where `secrets` is a `category`.
//+
//image::governance/code-editor-7.png

@@ -425,3 +435,11 @@ definition:
- "my-super-secret-password-regex"


=== ARM capabilities in the Code editor

* ARM is an Azure-specific framework
* You can define a policy that either applies to both ARM and Bicep with shared arguments and syntax, or you can limit the policy to either ARM or Bicep
* The ARM framework supports explicit and implicit dependencies. This does not include embedded child and loop dependencies
* ARM amd Bicep share the same resource types. By default, an ARM policy applies to both ARM and Bicep unless unless explicitly restricted to ARM
* If you select ARM as the framework, the definitions are automatically updated to align with ARM's requirements
* ARM supports periodic scans, PR scans, IDEscans and CLI scans
Original file line number Diff line number Diff line change
@@ -5,10 +5,18 @@ Prisma Cloud includes out-of-the-box policies that enable you to detect misconfi

You can create custom build policies for the following frameworks:

* *Terraform* - Policies written using Terraform attributes will apply for Terraform (.tf and plan files).
* *Bicep*: Policies defined using Bicep resources and attributes will apply for tailored Azure Bicep resource governance.
* *CloudFormation* - Policies written using CloudFormation attributes will apply for CloudFormation, AWS Serverless Application Model (SAM), and Cloud Development Kit (CDK).
* *Kubernetes* - Policies written using Kubernetes attributes will apply for Kubernetes, Helm, and Kustomize.
* *Terraform* - Policies written using Terraform attributes will apply for Terraform (.tf and plan files)
* *Bicep*: Policies defined using Bicep resources and attributes will apply for tailored Azure Bicep resource governance
* *ARM*

* ARM is an Azure-specific framework
* You can define a policy that either applies to both ARM and Bicep with shared arguments and syntax, or you can limit the policy to either ARM or Bicep
* The ARM framework supports explicit and implicit dependencies. This does not include embedded child and loop dependencies
* ARM amd Bicep share the same resource types. By default, an ARM policy applies to both ARM and Bicep unless unless explicitly restricted to ARM
* If you select ARM as the framework, the definitions are automatically updated to align with ARM's requirements
* ARM supports periodic scans, PR scans, IDEscans and CLI scans
* *CloudFormation* - Policies written using CloudFormation attributes will apply for CloudFormation, AWS Serverless Application Model (SAM), and Cloud Development Kit (CDK)
* *Kubernetes* - Policies written using Kubernetes attributes will apply for Kubernetes, Helm, and Kustomize

An *AI & Machine Learning* category enables granular control over build configurations for machine learning and artificial intelligence workloads. This category can be leveraged in relevant dashboards through the IaC Category filter, facilitating streamlined policy management for AI resources.

Original file line number Diff line number Diff line change
@@ -4,6 +4,7 @@ To create code-based policies for your infrastructure, use these examples as gui

* <<bicep-example,Bicep Example>>
* <<terraform-examples, Terraform Examples>>
* << ARM Example,[#arm-example]>>
* <<cloudformation-examples, Cloud Formation Examples>>
* <<kubernetes-examples,Kubernetes Examples>>
* <<ss-examples,Secrets Security Examples >>
@@ -56,6 +57,50 @@ definition:
value: Enabled
----

[#arm-example]
=== ARM Example

[source,json]
----
metadata:
name: "Ensure Azure Synapse Workspace has extended audit logs"
guidelines: "..."
category: "logging"
definition:
and:
- cond_type: filter
attribute: resource_type
value:
- Microsoft.Synapse/workspaces
operator: within
- cond_type: connection
resource_types:
- Microsoft.Synapse/workspaces
connected_resource_types:
- Microsoft.Synapse/workspaces/extendedAuditingPolicies
operator: exists
- or:
- and:
- cond_type: attribute
resource_types:
- Microsoft.Synapse/workspaces/extendedAuditingPolicies
attribute: properties.state
operator: exists

- cond_type: attribute
resource_types:
- Microsoft.Synapse/workspaces/extendedAuditingPolicies
attribute: properties.state
operator: equals
value: Enabled
- cond_type: attribute
resource_types:
- Microsoft.Synapse/workspaces/extendedAuditingPolicies
attribute: properties.state
operator: not_exists

----

[#terraform-examples]
=== Terraform Examples

Original file line number Diff line number Diff line change
@@ -57,7 +57,7 @@ Policies are categorized by type. Options include Elasticsearch, General, IAM, K

. Select the target *Framework*.
+
NOTE: Framework options include: Terraform, Kubernetes, CloudFormation and Bicep.
NOTE: Supported frameworks include Terraform, Kubernetes, CloudFormation, Bicep, and ARM. You can assign multiple frameworks to a single policy; for example, a policy can be configured to support both Bicep and ARM.

. Select a *Cloud Provider*.


Unchanged files with check annotations Beta

}
batchPublish(process.argv.slice(2))
.then((results) => console.info(JSON.stringify(results, undefined, 2), `published ${results.length} docs`))

Check warning on line 95 in bin/batch-publish.js

GitHub Actions / build

Unexpected console statement
.catch(console.error);

Check warning on line 96 in bin/batch-publish.js

GitHub Actions / build

Unexpected console statement
const checkSitemapIndex = async () => {
const res = await fetch(`${ORIGIN}/sitemap-index.xml`);
if (!res.ok) {
console.error(`ERROR: Failed to fetch sitemap-index: ${res.status}`);

Check warning on line 21 in bin/check-sitemap-index.js

GitHub Actions / build

Unexpected console statement
process.exit(1);
}
const index = create(text).toObject();
if (!index.sitemapindex?.sitemap) {
console.error('ERROR: Invalid sitemap-index, unexpected structure');

Check warning on line 29 in bin/check-sitemap-index.js

GitHub Actions / build

Unexpected console statement
process.exit(1);
}
return;
}
if (typeof existingMaps[pathname] === 'undefined') {
console.warn(`WARNING: Sitemap exists in sitemap-index, but not in docs repository: ${pathname}`);

Check warning on line 52 in bin/check-sitemap-index.js

GitHub Actions / build

Unexpected console statement
}
existingMaps[pathname] = true;
}, {});
// eslint-disable-next-line no-unused-vars
const missing = Object.entries(existingMaps).filter(([_, v]) => !v).map(([k]) => k);
if (missing.length) {
console.error(`ERROR: ${missing.length} sitemap(s) missing from sitemap-index: \n\t- ${missing.join('\n\t- ')}`);

Check warning on line 60 in bin/check-sitemap-index.js

GitHub Actions / build

Unexpected console statement
process.exit(1);
}
};
checkSitemapIndex().catch(console.error);

Check warning on line 65 in bin/check-sitemap-index.js

GitHub Actions / build

Unexpected console statement
};
generateRedirects()
.then((count) => console.info(`[bin/generate-redirects] generated ${count} redirects`))

Check warning on line 128 in bin/generate-redirects.js

GitHub Actions / build

Unexpected console statement
.catch(console.error);

Check warning on line 129 in bin/generate-redirects.js

GitHub Actions / build

Unexpected console statement
try {
const stat = await fs.stat(adocPath);
if (!stat.isFile()) {
console.warn(`invalid adoc (directory), excluding from sitemap: ${adocPath}`);

Check warning on line 289 in bin/generate-sitemaps.js

GitHub Actions / build

Unexpected console statement
return;
}
} catch (e) {