Creating Policies

Write OPA/Rego policies for IaC and configuration projects, or Kyverno YAML for Kubernetes clusters. Use the built-in editor, import from templates, or generate with AI.

Creating a Policy

Policy Settings

IaC and Configuration Policies

IaC Type scoping controls which engine the policy applies to. Set it to cloudformation for policies that check CloudFormation template syntax. Leave as any to evaluate against all engines.

Kubernetes Policies

Policy Editor Layout

The policy editor has four panels:

The center code editor uses Monaco (VS Code engine) with full Rego and YAML syntax support, including error underlines and line-level diagnostics.

AI Policy Generation

Generate a policy from natural language — available for all policy types.

Policy Editor (Rego)

The editor has a multi-panel layout:

Rego Basics

Policy Structure

package ops0.terraform.example

# Deny rule — generates an error-severity violation
deny[msg] {
    some_condition

    msg := "Description of the violation"
}

# Warn rule — generates a warning-severity violation
warn[msg] {
    some_other_condition

    msg := "Description of the warning"
}

Key Concepts

Terraform Policy Examples

Access Terraform plan data via input.planned_values.root_module.resources.

S3 Encryption Required

package ops0.terraform.s3.encryption

deny[msg] {
    resource := input.planned_values.root_module.resources[_]
    resource.type == "aws_s3_bucket"
    not resource.values.server_side_encryption_configuration

    msg := sprintf(
        "S3 bucket '%s' must have encryption enabled",
        [resource.values.bucket]
    )
}

Instance Size Limits

package ops0.terraform.ec2.instance_type

allowed_types := {"t3.micro", "t3.small", "t3.medium", "t3.large"}

deny[msg] {
    resource := input.planned_values.root_module.resources[_]
    resource.type == "aws_instance"
    not resource.values.instance_type in allowed_types

    msg := sprintf(
        "Instance '%s' uses '%s'. Allowed: %v",
        [resource.address, resource.values.instance_type, allowed_types]
    )
}

Required Tags

package ops0.terraform.tags.required

required_tags := {"Environment", "Owner", "CostCenter"}

deny[msg] {
    resource := input.planned_values.root_module.resources[_]
    resource.values.tags

    missing := required_tags - {tag | resource.values.tags[tag]}
    count(missing) > 0

    msg := sprintf(
        "Resource '%s' missing required tags: %v",
        [resource.address, missing]
    )
}

No Public RDS

package ops0.terraform.rds.public_access

deny[msg] {
    resource := input.planned_values.root_module.resources[_]
    resource.type == "aws_db_instance"
    resource.values.publicly_accessible == true

    msg := sprintf(
        "RDS instance '%s' must not be publicly accessible",
        [resource.address]
    )
}

Kubernetes Policy Examples (Kyverno)

Kyverno policies are YAML and enforce rules at Kubernetes admission time.

No Root Containers

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-root-user
spec:
  validationFailureAction: Enforce
  rules:
    - name: check-runAsNonRoot
      match:
        any:
          - resources:
              kinds: [Pod]
      validate:
        message: "Containers must not run as root."
        pattern:
          spec:
            containers:
              - securityContext:
                  runAsNonRoot: true

Resource Limits Required

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-resource-limits
spec:
  validationFailureAction: Enforce
  rules:
    - name: check-limits
      match:
        any:
          - resources:
              kinds: [Pod]
      validate:
        message: "CPU and memory limits are required."
        pattern:
          spec:
            containers:
              - resources:
                  limits:
                    memory: "?*"
                    cpu: "?*"

Testing Policies

Use the right panel in the policy editor to test against sample Terraform plan JSON:

Sample input:

{
  "planned_values": {
    "root_module": {
      "resources": [
        {
          "address": "aws_s3_bucket.data",
          "type": "aws_s3_bucket",
          "values": {
            "bucket": "my-bucket",
            "tags": { "Environment": "prod" }
          }
        }
      ]
    }
  }
}

Test output for the S3 + tags policies above:

{
  "deny": [
    "S3 bucket 'my-bucket' must have encryption enabled",
    "Resource 'aws_s3_bucket.data' missing required tags: {\"Owner\", \"CostCenter\"}"
  ]
}

Policy Templates

Import from 50 built-in templates rather than writing from scratch.

Imported policies are tagged source: template internally, distinguishing them from manually written policies. They can be edited freely after import.

Policy Groups

Group policies and attach groups to projects for bulk management.

Deleting a Group

When you delete a policy group:

• The group and all its project mappings are removed
• Built-in (framework-imported) policies that only belong to this group are deleted automatically
• Built-in policies shared with other groups are preserved
• User-created policies are never deleted when a group is deleted

Mapping Policies to Projects

Severity Override

Each direct policy-to-project mapping supports an optional severity override. This lets you apply a policy at a different severity for a specific project without creating a duplicate policy.

For example, apply the same "S3 Encryption Required" policy as warning in dev and error in production by mapping it twice with different overrides.

Effective Policies

A project's effective policies are the union of directly mapped policies and policies from mapped policy groups. Direct mappings take precedence for deduplication — if the same policy is both directly mapped and in a group, the direct mapping's settings (including any override) apply.

View at Policies → By Project → [project].

Deploying Kyverno Policies to Clusters

After creating a Kyverno policy, deploy it to one or more connected Kubernetes clusters:

Deployment Status

After deploying, the policy detail shows a Cluster Deployments table:

If a policy is updated (YAML changed), you need to re-deploy to push the new version to clusters. The deployment status shows Outdated for clusters running an older version.

Undeploying

To remove a policy from a cluster, click Undeploy next to the cluster in the Cluster Deployments table. The ClusterPolicy resource is deleted from the cluster immediately.

Related