Skip to main content
Policies allow you to enforce compliance, security, and operational standards across your infrastructure deployments. Policies are evaluated during builds and deploys, blocking or warning when violations are detected.

​
What are Policies?

Policies are rules written in OPA Rego or Kyverno that validate your infrastructure before deployment. Each policy can either:
  • Deny - Block the build or deployment when a violation is detected
  • Warn - Log a warning but allow the build or deployment to continue
Policies are evaluated at different phases depending on the component type:
  • Build-time: Policies run during the component build process
  • Deploy-time: Policies run after the plan is generated, before applying changes
  • Sandbox runs: Policies run during sandbox infrastructure provisioning

​
Policy Types

Nuon supports policies for different component types, each with its own input format:
TypeApplies ToEngineEvaluation PhaseInput Format
container_imageExternal container imagesOPABuildImage metadata (SBOM, signatures, attestations)
helm_chartHelm chart componentsOPADeployKubernetes AdmissionReview
kubernetes_manifestKubernetes manifest componentsOPADeployKubernetes AdmissionReview
terraform_moduleTerraform module componentsOPADeployTerraform JSON plan
kubernetes_clusterKubernetes cluster resourcesKyvernoDeployKubernetes resources
sandboxSandbox infrastructureOPASandbox runTerraform JSON plan

​
Policy Engines

​
OPA (Open Policy Agent)

OPA policies are written in Rego, a declarative query language. Policies must be in the nuon package and use deny or warn rules. The input structure varies by policy type:
Policy TypeInput Structure
terraform_module, sandboxinput.plan.resource_changes, input.plan.terraform_version
helm_chart, kubernetes_manifestinput.review.object, input.review.kind
container_imageinput.image, input.tag, input.metadata
Example: Terraform policy 
package nuon

# Deny unencrypted S3 buckets
deny contains msg if {
    some resource in input.plan.resource_changes
    resource.type == "aws_s3_bucket"
    resource.change.actions[_] in ["create", "update"]
    not resource.change.after.server_side_encryption_configuration
    msg := sprintf("S3 bucket '%s' must have encryption enabled", [resource.address])
}

# Warn about missing tags
warn contains msg if {
    some resource in input.plan.resource_changes
    resource.change.actions[_] in ["create", "update"]
    not resource.change.after.tags.Environment
    msg := sprintf("Resource '%s' is missing Environment tag", [resource.address])
}
Example: Kubernetes/Helm policy 
package nuon

# Deny containers running as root
deny contains msg if {
    input.review.kind.kind == "Pod"
    some container in input.review.object.spec.containers
    container.securityContext.runAsUser == 0
    msg := sprintf("Container '%s' must not run as root", [container.name])
}
Example: Container image policy 
package nuon

# Deny unsigned images
deny contains msg if {
    not input.metadata.signed
    msg := sprintf("Image %s:%s must be signed", [input.image, input.tag])
}

​
Kyverno

Kyverno policies use YAML syntax and are designed for Kubernetes resources. Kyverno is only supported for kubernetes_cluster policy types: 
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-labels
spec:
  validationFailureAction: Enforce
  rules:
    - name: check-team-label
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        message: "All pods must have a 'team' label"
        pattern:
          metadata:
            labels:
              team: "?*"

​
How do you configure Policies?

Policies are part of your app configuration. To create or update policies, add them to your app config and sync: 
nuon apps sync
Policies list Please go through the Configuring Policies guide for details. Note that unlike components, policies do not need to be built, they are evaluated directly during build and deploy workflows.

​
Policy Evaluation

​
Build-Time Evaluation

Build-time policies are evaluated during the component build process:
  • container_image: Policies evaluate image metadata (SBOM, signatures, attestations) fetched from the registry
If a deny rule matches during build-time evaluation, the build fails with status policy_failed.

​
Deploy-Time Evaluation

Deploy-time policies are evaluated after the plan is generated, before applying changes:
  • terraform_module: Policies evaluate the Terraform JSON plan
  • helm_chart: Policies evaluate the Kubernetes AdmissionReview objects
  • kubernetes_manifest: Policies evaluate the Kubernetes AdmissionReview objects
If a deny rule matches during deploy-time evaluation, the workflow step fails and changes are not applied.

​
Sandbox Evaluation

Sandbox policies (type = "sandbox") are evaluated during sandbox infrastructure runs. They receive the Terraform JSON plan for the sandbox infrastructure.

​
Viewing Policy Results

​
Dashboard

Policy violations are displayed in the workflow step details. The Policy Evaluation card shows:
  • Passed: All policy checks passed successfully
  • Denies: Policy violations that blocked the workflow (red)
  • Warnings: Policy warnings that were logged but didn’t block (orange)
Each violation includes the policy name and the specific message from your deny or warn rule. Workflow policy violations You can also view a list of all policy evaluations for an install, or filter by their status, type etc. Policy evaluations list

​
CLI

Build failures due to policy violations show the policy_failed status: 
nuon builds create -c my-component

# Output:
# ✗ component build failed policy check: Image nginx:latest must be signed
Workflow steps display policy violation counts in the output: 
nuon installs workflows steps list -w <workflow-id>

# Output shows policy column with ✗ (denies) and ⚠ (warnings):
# Step          Status    Policy
# deploy-api    error     ✗ 2
# deploy-db     success   ✓
# deploy-cache  success   ⚠ 1
Get detailed violation messages for a specific step: 
nuon installs workflows steps get -w <workflow-id> -s <step-id>

​
Policy Examples

We maintain a collection of example policies organized by component type to help you get started.
The example repository includes:
  • terraform/ - Policies for Terraform modules (encryption, tagging, IAM security, cost controls)
  • kubernetes/ - Policies for Helm charts and Kubernetes manifests (pod security, resource limits, networking)