Policy Rules

Policy Rules allow you to automatically attach custom policies to workloads based on defined matching criteria. Note that all matching is evaluated against pod labels, annotations, and environment variables — not those set on the workload owner object (e.g. Deployment or StatefulSet).

Overview

Policy Rules provide a powerful way to automatically apply specific policies to workloads whose pods match certain criteria. This enables you to:

• Automatically apply appropriate policies to workloads based on their pod characteristics
• Reduce manual policy management overhead
• Ensure consistent policy application across similar workloads
• Scale policy management across large clusters

Creating Policy Rules

To create a policy rule:

1. Navigate to the Policies page
2. Click on the Rules tab
3. Click Create new policy rule

Rules Definition

Define one or more rules to identify workloads that should be associated with the policy. The policy is applied to all workloads whose pods match any of the defined rules.

Detected Workload Tag

A tag automatically added to workloads that match the rule criteria, indicating which rule was applied. The tag can be used for:

• Filtering workloads in the rightsizing page
• Visibility in the workload overview dialog

Define Detected Workload Identifiers

The identifiers are used to match workloads with the policy rule. All matching is evaluated against pod labels, annotations, and environment variables — not the labels or annotations set on the workload owner object (e.g. Deployment or StatefulSet). Multiple identifiers within a rule are combined with an AND operator, while multiple rules are combined with an OR operator.

Match Options

Logic Operators

• Within a rule: Multiple identifiers use AND logic (all conditions must match)
• Between rules: Multiple rules use OR logic (any rule can match)

Enforcing Policy Rules

Policy rules are enforced automatically for any workload matching the defined criteria.

Default Behavior

• If no rules match, ScaleOps applies the recommended auto-detected policy
• If the workload’s policy is managed manually (via UI actions or YAMLs), rules will not apply

Overriding Manual Policies

To apply custom rules instead of manual policies:

1. Use the Restore Detected Policy actions at the cluster, namespace, or workload level in the Workload Rightsizing page
2. Remove any annotations or YAMLs (e.g., AutomatedNamespace) that override policy behavior

Examples

Example 1: Pods with Annotation and Environment Variable

Configuration:

• Rule: Workloads whose pods have annotation team/a AND environment variable production
• Logic: Both conditions must be met (AND operator)

Use Case: Apply a specific policy to production workloads from a particular team.

Example 2: Pods with Label or Annotation

Configuration:

• Rule 1: Workloads whose pods have label system=Core
• Rule 2: Workloads whose pods have annotation production=true
• Logic: Either condition can match (OR operator between rules)

Use Case: Apply a policy to either core system components or production workloads.

Best Practices

When to Use Policy Rules

• Environment-based policies: Different policies for dev, staging, and production
• Team-based policies: Specific policies for different development teams
• Workload-type policies: Different policies for batch jobs, web services, databases
• Cost optimization: Apply cost-focused policies to non-critical workloads

Configuration Tips

1. Start simple: Begin with a single rule and expand as needed
2. Use specific identifiers: Prefer key-value pairs over keys-only for more precise matching
3. Test thoroughly: Validate that your rules match the intended workloads
4. Monitor effectiveness: Regularly review which workloads are being matched by your rules
5. Document your rules: Keep clear documentation of what each rule is intended to match

Common Patterns

Troubleshooting

Rule not applying? Check for:

• Manual policy overrides (UI actions or YAMLs)
• Incorrect identifier syntax
• Missing labels/annotations on target pods (rules match pod labels/annotations, not the workload owner)
• Conflicting rules with higher precedence