Request Validation

Cloud Workload Security (CWS) uses workloads and policies to validate API requests. Workloads define request scope. Policies define the checks, and policy sets connect scope to checks. A deployment selects the policy sets to apply.

For a definition of each resource, refer to CWS entities.

How the concepts work together

Request validation combines scope, checks, and enforcement settings:

flowchart TD
    accTitle: CWS request validation
    accDescr: A deployment selects policy sets. Workloads define request scope, policy filters select matching requests, and Rego valid rules validate them. Modules, metadata, and tenant structures supply shared logic and data. Enforce settings and deployment defaults determine whether requests are allowed or blocked.

    A["Deployment's policy sets"] --> B["Workload scope<br/>Included and excluded requests"]
    B --> C["Policy filters<br/>Select applicable policies"]
    C -->|Matching policies| D["Rego validation<br/>Each policy's valid rule"]
    C -->|No matching policy| F["Request decision<br/>Enforce and deployment defaults"]
    E["Rego modules, metadata,<br/>and tenant structures"] -.-> D
    D --> F

Select applicable policies

Deployment and policy sets

The deployment selects the policy sets available for evaluation. Each set groups policies and specifies included and excluded workloads.

Workload scope

A request must match an included workload when inclusions are configured. It must not match an excluded workload. An empty inclusion list adds no inclusion restriction.

Policy filter

Within that scope, each policy's filter selects the requests to check. For example, a workload can select Cloudflare API traffic while a policy filter selects one R2 operation. Workload scope and policy filter must both match for the policy to apply.

Validate with Rego

Each matching policy evaluates a Boolean rule named valid. A true result passes that policy's check. A false result fails it. Use Rego to validate request content, such as whether a change would make a bucket public.

Policies can reuse shared logic and data:

Rego modules supply reusable checking logic.
Rego metadata supplies shared JSON values.
Tenant structures describe cloud resource hierarchies. A package path makes their nodes available to Rego.

Apply enforcement and defaults

Each policy's Enforce setting within its policy set determines how its check result affects the request:

Condition	Effect
A matching policy returns `true`.	That check passes. Another enforcing policy can still block the request.
A matching policy returns `false` with Enforce on.	Block the request.
A matching policy returns `false` with Enforce off.	Record the failed check without blocking on that policy's result.
No policy matches the request.	Apply the deployment's Default mode.

More than one policy can match a request. A failed enforcing policy blocks even when another policy passes. A failed Rego check is not an unmatched request, so it does not fall back to Default mode.

Configure policy error handling with the deployment's On error action setting.

Example: keep R2 buckets private

Suppose a workload selects Cloudflare API requests. Its policy set contains a policy for changing R2 bucket public access. The policy filter selects that operation. Rego permits it only when input.http.request.body.enabled is false.

An attempt to turn on public access matches the filter but fails Rego validation. With Enforce on, CWS blocks the request. For a runnable guardrail example, follow Get started.

Domain ACLs control which destinations a deployment can reach. Allowing a destination does not bypass workload scope or policy checks.

Basic Auth credentials provide client identities that workload and policy filters can match. The cloud provider still applies its own authentication and permissions.

To configure scope and enforcement, follow Configure policies. To inspect decisions, refer to Read proxy logs.