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 policies with AI.

Creating a Policy

Choose Policy Tab

Select IaC Policies, Configuration Policies, or Kubernetes Policies depending on the target.

Click Create Policy

Opens the policy editor with a blank policy.

Configure Settings

Set the name, category, severity, and other metadata.

Write or Generate Code

Write Rego/YAML manually, use a template, or generate with AI.

Test the Policy

Run the policy against sample input to verify behavior.

Save and Activate

Save the policy and map it to projects or policy groups.

Policy Settings

IaC and Configuration Policies

Field	Required	Description
Name	Yes	Policy name
Description	No	What this policy checks
Category	Yes	security, cost, compliance, tagging, best-practices, custom
Severity	Yes	error (blocks deploy), warning (non-blocking), info (advisory)
Enabled	Yes	Toggle enforcement on/off

Kubernetes Policies

Field	Required	Description
Name	Yes	Policy name
YAML	Yes	Kyverno ClusterPolicy or Policy YAML
Enabled	Yes	Toggle enforcement on/off
Cluster Mappings	No	Which clusters to deploy this policy to

AI Policy Generation

Generate a policy from a natural language description. Available for all policy types.

Click "Generate with AI"

Opens the AI generation dialog.

Enter a Prompt

Describe what the policy should enforce. Example: "Block any EC2 instance that doesn't have the Environment and Owner tags."

Select Category and Severity

Choose the appropriate category and severity level.

Review Output

The AI generates complete Rego code (for IaC/configurations) or Kyverno YAML (for Kubernetes). Edit as needed.

Save

Save the generated policy directly from the dialog.

AI Requirements

AI generation requires AI features to be configured at the organization level in Settings → API Configuration.

Policy Editor (Rego)

The editor has a multi-panel layout for writing and testing IaC/configuration policies:

Panel	Purpose
Left	Policy settings and metadata
Center	Rego code editor with syntax highlighting
Right	Test input (JSON) and output (violations)
Bottom	Validation messages and errors

Rego Basics

Policy Structure

package ops0.terraform.example

import future.keywords.if
import future.keywords.in

# Deny rule - returns violation messages
deny[msg] {
    # Condition that triggers violation
    some_condition_is_true

    msg := "Description of the violation"
}

Key Concepts

Concept	Description
`package`	Namespace for the policy
`deny[msg]`	Rule that returns violation messages
`input`	The data being evaluated (plan JSON, manifest, etc.)
`sprintf`	Format strings with variables

Terraform Policy Examples

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

S3 Encryption Required

package ops0.terraform.s3

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

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_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 tags: %v",
        [resource.address, missing]
    )
}

No Public RDS

package ops0.terraform.rds

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 written in 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: "?*"

Image Registry Whitelist

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: restrict-image-registries
spec:
  validationFailureAction: Enforce
  rules:
    - name: validate-registries
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        message: "Images must be from approved registries."
        pattern:
          spec:
            containers:
              - image: "gcr.io/my-project/* | docker.io/myorg/*"

Kyverno Validation

Before deploying Kyverno policies to clusters, ops0 validates the YAML syntax. The validation check ensures:

Valid YAML structure
Correct Kyverno API version and kind
Valid rule patterns and match expressions
No conflicting rule definitions

If validation fails, the editor shows specific error messages to help you fix the YAML.

Testing Policies

Test Panel (Rego)

Use the right panel in the policy editor to test against sample input:

Paste Sample JSON

Add a Terraform plan JSON or manifest in the Input panel.

Click Run Test

Evaluate the policy against the input.

View Results

Violations appear in the Output panel.

Sample Terraform Plan Input

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

Test Output

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

Policy Templates

Import from the built-in template library instead of writing from scratch:

Browse Templates

Go to Policies → Templates to view available templates by category.

Preview

Review the policy code and description.

Import

Click Import to create a new policy from the template. Customize name, severity, and category.

Category	Templates
AWS Security	S3 encryption, no public access, security group rules
AWS Cost	Instance limits, GP3 volumes, reserved instances
GCP Security	Storage encryption, firewall rules
Azure Security	Storage account encryption, NSG rules
Kubernetes	Security contexts, resource limits, image policies
Tagging	Required tags, naming conventions

Policy Groups

Organize policies into groups and attach groups to projects for bulk management.

Go to Policy Groups Tab

Select the Policy Groups tab on the Policies page.

Create Group

Click Create Group. Provide a name, description, and group type (iac, configurations, or kubernetes).

Add Policies

Select policies to include in the group.

Map to Projects

Attach the group to one or more projects. All policies in the group apply to every mapped project.

Field	Description
Name	Group name
Type	`iac`, `configurations`, or `kubernetes`
Enabled	Toggle all policies in the group
Policies	Count of included policies
Projects	Count of mapped projects

Mapping Policies to Projects

Policies can be assigned to projects in two ways:

Method	Use When
Direct mapping	A policy applies to specific projects only
Policy group	A set of policies applies to many projects

Each mapping supports an optional severity override so you can apply a policy at a different severity than its default for a specific project.

Effective Policies

A project's effective policies are the combination of directly mapped policies and policies inherited from its policy groups. View the effective list at Policies → Effective → [Project].

Policies Overview

Policy types, severity levels, and platform capabilities.

Compliance Dashboard

Monitor compliance posture and manage violations.

Enforce Security Policies

Step-by-step guide to setting up policy enforcement.