policy field, and because a cluster hosts at most one runner, one policy governs one cluster.
For the task-oriented walkthrough, see Configure a sandbox policy. For worked examples, see Policy examples.
CoreWeave sandboxes are in public preview. For access, contact your CoreWeave account team, CoreWeave Support, or email support@coreweave.com.
Top-level fields
An empty policy is valid and declares a fully permissive posture. Both
base and constraints are optional, so a cluster’s posture is always stated rather than inherited by accident.
Resolution order
A sandbox resolves in two stages:- Base. Runtime defaults, then
base, then the sandbox spec. The sandbox wins for individual values. List attachments frombaseare always applied. - Constraints. Clamps are validated against the fully resolved spec. A violation is rejected, never silently rewritten, with one exception:
max_lifetime_secondsis clamped to the policy maximum and the applied value echoed.
base supplied is checked on the same terms as a value the sandbox supplied.
base
A fragment of runtime defaults and attachments. On a Kubernetes runner, this is a pod specification fragment.
base is where infrastructure settings live that a sandbox has no business declaring: the scheduler, node selectors, tolerations, affinity, priority class, topology spread, service accounts, image pull secrets, platform volumes, DNS configuration, and pod metadata such as pinned annotations.
constraints
PolicyConstraints groups the typed clamps a policy enforces. Every group is optional, and an omitted group applies no restriction.
ResourceConstraints
The ceilings differ from the maximums:
max_cpu bounds one container’s request, while cpu_ceiling bounds the resolved total, which matters when base contributes containers of its own.
ImageConstraints
NetworkConstraints
Network constraints work as an envelope. A sandbox declares the access it needs, and the policy decides whether the request fits. The policy never adds access a sandbox did not request.
Containment is checked by type. A declared CIDR must fit an allowed CIDR, a declared tenant scope must appear as an allowed scope, and declaring
any requires an any entitlement.
EgressRule
Each rule names exactly one destination, optionally narrowed by port.
IngressRule
Ingress rules never name a source, because inbound packets carry no name.
CidrBlock
PortRange
TenantScope
SelectorBlock
Matching is by exact label pairs. A selector entitlement is required for a declared selector: an
any entitlement covers address-shaped destinations but never selectors, so an open egress policy does not silently grant label-based selection of co-located workloads.
SecurityConstraints
allowed_runtime_classes is the one list where empty means “nothing,” not “anything.” A sandbox can only select a runtime class you name explicitly.
Host-reaching settings are policy-only and never appear on a sandbox spec, whatever the isolation in use.
InstanceConstraints
LifecycleConstraints
A policy without a lifetime bound is rejected.
Lifetime is the one field the policy clamps. A sandbox that requests more than
max_lifetime_seconds receives the maximum, and the applied value is echoed on the result. Every other constraint rejects a violation instead of narrowing it.
MetadataConstraints
VolumeConstraints
StorageMedium
Omit
STORAGE_MEDIUM_MEMORY from allowed_media to forbid RAM-backed volumes.
Validation rules
A policy is rejected when any of the following hold:constraints.lifecycle.max_lifetime_secondsis absent or not greater than zero.- The encoded document exceeds 256 KiB.
- The policy is null. A configured policy cannot be cleared, only replaced.
default_egresscarries DNS names on a runner that cannot enforce them.
See also
- Configure a sandbox policy: the task-oriented walkthrough for every group on this page.
- Policy examples: five complete policies for common cluster postures.
- Policies overview: how a sandbox resolves against a policy.
- Deploy and manage a runner: where the policy lives and how to set it.