Writing Cloud Custodian Compliance Policies

Follow

Writing Cloud Custodian Compliance Policies

Kion includes the open-source Cloud Custodian rules engine, so you can easily write and run YAML policies against your cloud resources, like EC2 instances, VPCs, root users, etc. This article explains the basics of writing your own Cloud Custodian compliance policy and how webhook actions work in Kion. We suggest also reading the Cloud Custodian documentation for more in depth information and for example policies.

These policies are implemented using Kion compliance checks. For information about adding policies to compliance checks, see Add a Compliance Check.

Compliance Policy Basics

A Cloud Custodian policy should define, at a minimum:

  • name. A unique name for the policy.
  • resource. The type of resource the policy runs against.
  • filters. Filters narrow down the resources that the policy runs against. Filters can include tag, type, key, value, and logic statements (and, or, not).
  • actions. Actions to take on the resources. This must include an action that posts the findings to Kion via a webhook. Optionally, it can also include actions to automatically remediate the finding.

The name, resource, and filters sections are native c7n YAML. You can copy/paste pre-written policies from other sources (such as GitHub repos), and add the webhook to post to Kion.

The actions section contains a webhook for posting to Kion and automatic remediation actions. The actions section typically includes the following variables:

  • {{CT::CheckId}}. The check ID that will be scanned.
  • {{CT::Authorization}}. The authorization token for ingesting findings via the public scan API.
  • {{CT::CallbackURL}}. The callback URL cloud custodian will POST to for ingesting findings via the public scan API.

The compliance check frequency and regions are set when creating a compliance check and do not need to be included in the policy code.

When adding or editing a compliance check, the Validate Policy button ensures your policy code is valid.

AWS

ClosedPolicy creation example for AWS

AWS Policy References

  • Resource types. You can find a list of resources and their common actions in Cloud Custodian's article: AWS Reference.
  • Filters. You can find a list of common filters in Cloud Custodian's article: AWS Common Filters.
  • Actions. Remember, the actions section contains a webhook for posting to Kion and automatic remediation actions. In most cases, you can use the webhook in the example above to post to Kion. You can find a list of common remediation actions in Cloud Custodian's article: AWS Common Actions.

Azure

ClosedPolicy creation example for Azure

Azure Policy References

  • Resource type. You can find a list of resources and their common actions and filters in Cloud Custodian's article: Azure Reference.
  • Filters. You can find a list of common filters in Cloud Custodian's article: Azure Common Filters.
  • Actions. Remember, the actions section contains a webhook for posting to Kion and automatic remediation actions. In most cases, you can use the webhook in the example above to post to Kion. You can find a list of common remediation actions in Cloud Custodian's article: Azure Common Actions.

Including Metadata

Metadata is information that is not typically captured by Kion. You can add metadata fields to any policy to capture additional information like IP addresses, instance state, launch time, and more.

ClosedPolicy with metadata example

Advanced Logic for Compliance Policies

Cloud Custodian supports various types of advanced and conditional logic.

The following policy is an example using or and not logic. This checks if the default security group has a value for either IpPermissions OR IpPermissionsEgress. Use this as a guideline to incorporate this logic into your own policies. The or could be replaced with and to only find cases where the default security group has a value for BOTH IpPermissions AND IpPermissionsEgress.

policies:
- name: cis_sg-default-allowing-traffic
resource: aws.security-group description: | CIS 1.2.0 - 4.3 Ensure the default security group for every VPC restricts all traffic filters: - GroupName: default - or: - not: - IpPermissions: empty - not: - IpPermissionsEgress: empty actions: - type: webhook url: '{{CT::CallbackURL}}' method: POST batch: true headers: Authorization: '`{{CT::Authorization}}`' body: |- { "compliance_check_id": `{{CT::CheckId}}`, "account_number": account_id, "region": region, "scan_started_at": execution_start, "findings": resources[].{resource_name: GroupId, resource_type: `security-group`, data_json: {ingress_rules: IpPermissions, egress_rules: IpPermissionsEgress}} }

Advanced Logic References

 

Was this article helpful?
0 out of 0 found this helpful