Policy Creation Guide

Learn how to create effective governance policies for your cloud infrastructure. From basic rules to complex compliance frameworks with automated remediation.

PolicyCortex Documentation: Quick Start & Installation Guide

Policy Structure Overview

Policy Components

Every PolicyCortex policy consists of metadata, rules, compliance mappings, and optional remediation actions.

Basic Policy Structureyaml
policy:
  name: "my-security-policy"
  description: "Ensure resources follow security best practices"
  version: "1.0"
  category: "Security"

  resource_types:
    - "AWS::S3::Bucket"
    - "AWS::EC2::SecurityGroup"

  rules:
    - id: "rule-001"
      condition: "resource.encryption == null"
      effect: "DENY"
      severity: "HIGH"
      message: "Resource must have encryption enabled"

  compliance_mapping:
    - framework: "SOC2"
      control: "CC6.1"
    - framework: "HIPAA"
      control: "164.312(a)(2)(iv)"

  remediation:
    auto_fix: true
    actions:
      - enable_encryption
      - notify_team

Step-by-Step Policy Creation

Define Policy Metadata

Start by defining what your policy does and which resources it applies to.

Policy Metadatayaml
policy:
  name: "require-s3-versioning"
  description: "S3 buckets must have versioning enabled for data protection"
  version: "1.0"
  author: "Security Team"
  category: "Data Protection"

  resource_types:
    - "AWS::S3::Bucket"

  tags:
    - security
    - s3
    - data-protection

Write Policy Rules

Define the conditions that trigger policy violations using our rule engine.

Policy Rulesyaml
rules:
  - id: "versioning-required"
    condition: |
      resource.versioning.status != "Enabled" or
      resource.versioning.status == null
    effect: "DENY"
    severity: "MEDIUM"
    message: "S3 bucket must have versioning enabled"

  - id: "mfa-delete-required"
    condition: |
      resource.versioning.mfaDelete != "Enabled" and
      resource.publicAccessBlock != true
    effect: "WARN"
    severity: "LOW"
    message: "Consider enabling MFA delete for public buckets"

Add Compliance Mappings

Map your policy to relevant compliance frameworks and controls.

Compliance Mappingyaml
compliance_mapping:
  - framework: "SOC2"
    control: "CC6.1"
    description: "Logical access security measures"

  - framework: "NIST_CSF"
    control: "PR.DS-1"
    description: "Data-at-rest is protected"

  - framework: "AWS_FOUNDATIONAL"
    control: "S3.15"
    description: "S3 bucket should have versioning enabled"

  - framework: "CIS_AWS"
    control: "2.1.3"
    description: "Ensure S3 bucket versioning is enabled"

Rule Syntax Reference

Condition Operators

  • == Equal to
  • != Not equal to
  • in Contains value
  • not in Does not contain
  • matches Regex pattern
  • exists Field is present
  • length Array/string length

Resource Context

  • resource.* Resource properties
  • account.id AWS account ID
  • region Resource region
  • tags.* Resource tags
  • environment Environment context
  • relationships.* Related resources

Advanced Policy Examples

Multi-Resource Policy

Create policies that validate relationships between multiple resource types for comprehensive security coverage.

Cross-Resource Validationyaml
policy:
  name: "secure-database-access"
  description: "Databases must be in private subnets with proper security groups"
  resource_types:
    - "AWS::RDS::DBInstance"
    - "AWS::EC2::SecurityGroup"

  rules:
    - condition: |
        resource.type == "AWS::RDS::DBInstance" and
        relationships.subnet.routeTable.routes[*].gatewayId contains "igw-"
      effect: "DENY"
      severity: "HIGH"
      message: "RDS instance must be deployed in private subnet"

    - condition: |
        resource.type == "AWS::EC2::SecurityGroup" and
        relationships.dbInstances != null and
        resource.ingressRules[*].cidrBlocks contains "0.0.0.0/0"
      effect: "DENY"
      severity: "CRITICAL"
      message: "Database security group must not allow public access"

Environment-Specific Policy

Apply different security requirements based on environment tags and context for flexible governance.

Production Environment Rulesyaml
policy:
  name: "production-security-requirements"
  description: "Enhanced security requirements for production workloads"

  scope:
    environments: ["production", "prod"]
    tags:
      Environment: ["Production", "Prod"]

  rules:
    - condition: |
        resource.type == "AWS::S3::Bucket" and
        tags.Environment in ["Production", "Prod"] and
        resource.encryption == null
      effect: "DENY"
      severity: "CRITICAL"
      message: "Production S3 buckets must have encryption enabled"

    - condition: |
        resource.type == "AWS::EC2::Instance" and
        environment == "production" and
        resource.imageId not in approved_ami_list
      effect: "DENY"
      severity: "HIGH"
      message: "Production instances must use approved AMI"

  variables:
    approved_ami_list:
      - "ami-0abcdef1234567890"
      - "ami-1234567890abcdef0"

Testing Your Policies

Policy Validation

Test and validate your policies before deployment to ensure they work as expected without disrupting operations.

Test Policy Against Sample Resourcesbash
policycortex policy validate --file my-policy.yaml

policycortex policy test \
  --policy my-policy.yaml \
  --resources test-resources.json \
  --verbose

policycortex policy deploy \
  --file my-policy.yaml \
  --dry-run \
  --environment staging

policycortex policy impact \
  --policy my-policy.yaml \
  --account 123456789012 \
  --regions us-east-1,us-west-2