Policy examples - CoreWeave Docs

This page collects five complete policies for common cluster postures, so you can start from a working document rather than build one from scratch. A cluster has exactly one policy, so these examples are alternatives rather than a set to combine. Pick the posture that matches what the cluster is for, then adjust it. Each example is a full policy document: apply it with cwic sandbox runner policy edit [RUNNER-ID] -f policy.json, or send it as the policy field of a runner update. For the field-by-field walkthrough, see Configure a sandbox policy.

CoreWeave sandboxes are in public preview. For access, contact your CoreWeave account team, CoreWeave Support, or email support@coreweave.com.

GPU data science cluster

A cluster for long-lived per-user work: generous compute, GPU nodes, and internet access for pulling datasets and packages, with the instance metadata endpoint carved out.

policy.json

{
  "displayName": "Data science, GPU",
  "constraints": {
    "resources": {
      "defaultCpu": "4",
      "defaultMemory": "16Gi",
      "maxCpu": "16",
      "maxMemory": "128Gi",
      "maxGpuCount": "2",
      "requireLimits": true
    },
    "instance": { "allowedInstanceTypes": ["h100"] },
    "image": { "allowedRegistries": ["ghcr.io/[YOUR-ORG]"] },
    "network": {
      "allowedEgress": [
        { "cidr": { "cidr": "0.0.0.0/0", "except": ["169.254.169.254/32"] } }
      ],
      "defaultEgress": [
        { "cidr": { "cidr": "0.0.0.0/0", "except": ["169.254.169.254/32"] } }
      ]
    },
    "security": {
      "allowPrivileged": false,
      "allowedRuntimeClasses": ["kata-qemu", "kata-qemu-nvidia-gpu"],
      "defaultCpuRuntimeClass": "kata-qemu",
      "defaultGpuRuntimeClass": "kata-qemu-nvidia-gpu",
      "allowedSeccompProfiles": ["RuntimeDefault"]
    },
    "lifecycle": { "maxLifetimeSeconds": 604800, "defaultLifetimeSeconds": 86400 }
  }
}

Both runtime classes are listed because allowedRuntimeClasses fails closed. A sandbox can only pin a class you name, and the two defaults decide what it gets when it pins nothing.

Shared agent cluster with allowlisted egress

A multi-tenant cluster for agent workloads. Agents reach a fixed set of upstreams and each other within the organization, and nothing else.

policy.json

{
  "displayName": "Agents, allowlisted egress",
  "constraints": {
    "resources": {
      "defaultCpu": "1",
      "defaultMemory": "2Gi",
      "maxCpu": "4",
      "maxMemory": "8Gi",
      "requireLimits": true
    },
    "network": {
      "allowedEgress": [
        { "cidr": { "cidr": "140.82.112.0/20" }, "ports": [{ "port": 443 }] },
        { "cidr": { "cidr": "151.101.0.0/16" }, "ports": [{ "port": 443 }] },
        { "tenant": "TENANT_SCOPE_SAME_ORG" }
      ],
      "defaultEgress": [
        { "cidr": { "cidr": "140.82.112.0/20" }, "ports": [{ "port": 443 }] }
      ]
    },
    "security": {
      "allowPrivileged": false,
      "allowedRuntimeClasses": ["kata-qemu"],
      "defaultCpuRuntimeClass": "kata-qemu",
      "allowedSeccompProfiles": ["RuntimeDefault"]
    },
    "lifecycle": { "maxLifetimeSeconds": 43200, "defaultLifetimeSeconds": 3600 }
  }
}

A sandbox that declares nothing gets the first CIDR only. A sandbox that needs to reach other sandboxes in the organization declares the tenant rule itself, and the policy permits it because the rule fits the envelope.

Ephemeral CI cluster

Short-lived, small, and narrow. Sandboxes exist for the length of a test run.

policy.json

{
  "displayName": "CI",
  "constraints": {
    "resources": {
      "defaultCpu": "250m",
      "defaultMemory": "512Mi",
      "maxCpu": "2",
      "maxMemory": "4Gi",
      "requireLimits": true
    },
    "image": { "allowedRegistries": ["ghcr.io/[YOUR-ORG]"] },
    "network": {
      "allowedEgress": [
        { "cidr": { "cidr": "140.82.112.0/20" }, "ports": [{ "port": 443 }] }
      ],
      "defaultEgress": [
        { "cidr": { "cidr": "140.82.112.0/20" }, "ports": [{ "port": 443 }] }
      ]
    },
    "security": {
      "allowPrivileged": false,
      "allowedRuntimeClasses": ["gvisor"],
      "defaultCpuRuntimeClass": "gvisor",
      "allowedSeccompProfiles": ["RuntimeDefault"]
    },
    "lifecycle": { "maxLifetimeSeconds": 3600, "defaultLifetimeSeconds": 900 },
    "volumes": { "allowedMedia": ["STORAGE_MEDIUM_DISK"], "maxSize": "10Gi" }
  }
}

The one-hour maximum is the useful part. A hung CI job cannot outlive it, whatever the client asks for.

Untrusted code execution

The tightest posture on this page. VM isolation is mandatory, no egress is permitted at all, and the sandbox cannot request its way out of either.

policy.json

{
  "displayName": "Untrusted execution",
  "constraints": {
    "resources": {
      "defaultCpu": "500m",
      "defaultMemory": "512Mi",
      "maxCpu": "2",
      "maxMemory": "2Gi",
      "requireLimits": true
    },
    "image": { "allowedImages": ["ghcr.io/[YOUR-ORG]/sandbox-base:pinned"] },
    "network": {
      "allowedEgress": [],
      "defaultEgress": [],
      "denyDns": true
    },
    "security": {
      "allowPrivileged": false,
      "allowedCapabilities": [],
      "allowedRuntimeClasses": ["kata-qemu"],
      "defaultCpuRuntimeClass": "kata-qemu",
      "allowedSeccompProfiles": ["RuntimeDefault"]
    },
    "lifecycle": { "maxLifetimeSeconds": 1800, "defaultLifetimeSeconds": 300 },
    "metadata": { "maxAnnotationCount": 0 },
    "volumes": { "allowedMedia": ["STORAGE_MEDIUM_DISK"], "maxSize": "5Gi" }
  }
}

An empty allowedEgress list means anything is declarable, not that nothing is. Sandboxes on this cluster get no egress because defaultEgress is empty and the runner denies by default, but a sandbox that declares its own rules is not bounded by an empty envelope. Where a cluster must never reach the network, confirm the posture against the runner’s enforcement rather than relying on the envelope alone.

allowedImages pins one image rather than a registry, so a sandbox cannot select an arbitrary image from a trusted registry.

Internal worker cluster

Long-running background workers that other sandboxes in the organization reach over a service, with outbound access for third-party API calls.

policy.json

{
  "displayName": "Internal workers",
  "constraints": {
    "resources": {
      "defaultCpu": "1",
      "defaultMemory": "2Gi",
      "maxCpu": "8",
      "maxMemory": "16Gi",
      "requireLimits": true
    },
    "image": { "allowedRegistries": ["ghcr.io/[YOUR-ORG]"] },
    "network": {
      "allowedEgress": [
        { "cidr": { "cidr": "0.0.0.0/0", "except": ["10.0.0.0/8", "169.254.169.254/32"] } },
        { "tenant": "TENANT_SCOPE_SAME_ORG" }
      ],
      "defaultEgress": [{ "tenant": "TENANT_SCOPE_SAME_ORG" }]
    },
    "security": {
      "allowPrivileged": false,
      "allowedRuntimeClasses": ["kata-qemu"],
      "defaultCpuRuntimeClass": "kata-qemu",
      "allowedSeccompProfiles": ["RuntimeDefault"]
    },
    "lifecycle": { "maxLifetimeSeconds": 2592000, "defaultLifetimeSeconds": 604800 }
  }
}

Egress is scoped so workers reach the public internet and sibling sandboxes in the organization, with private space and the metadata address carved out.

Inbound access is not policy-controlled yet. Ingress constraints are not enforced, and a sandbox that declares ingress rules is rejected, so this example sets egress only.

Vary the posture across clusters

Because a policy belongs to a cluster, different postures are different clusters rather than different documents on one cluster. A team that needs both an open data science environment and a locked-down execution environment runs two clusters and gives each the matching policy. To vary one dimension by region, apply the same policy to each cluster with the region-specific values changed. There is no shared or inherited policy document, so keep the source of truth in version control and apply it per cluster.

​GPU data science cluster

​Shared agent cluster with allowlisted egress

​Ephemeral CI cluster

​Untrusted code execution

​Internal worker cluster

​Vary the posture across clusters

​See also

GPU data science cluster

Shared agent cluster with allowlisted egress

Ephemeral CI cluster

Untrusted code execution

Internal worker cluster

Vary the posture across clusters

See also