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. Replace [RUNNER-ID] with the ID of the runner whose policy you want to edit, and replace [GITHUB-ORG] in the image registry examples with your GitHub Container Registry organization or user name. For the field-by-field walkthrough, see Configure a sandbox policy.

CoreWeave Serverless sandboxes are in public preview.

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/[GITHUB-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", "cw-kata-nvidia-gpu"],
      "defaultCpuRuntimeClass": "kata-qemu",
      "defaultGpuRuntimeClass": "cw-kata-nvidia-gpu",
      "allowedSeccompProfiles": ["RuntimeDefault"]
    },
    "lifecycle": { "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": { "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/[GITHUB-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": { "defaultLifetimeSeconds": 900 },
    "volumes": { "allowedMedia": ["STORAGE_MEDIUM_DISK"], "maxSize": "10Gi" }
  }
}

The 15-minute default is the useful part: a CI job that declares nothing self-terminates quickly. The policy carries no lifetime cap: requests above the platform maximum of 30 days are rejected at create time, and anything under it is allowed, so set max_lifetime_seconds on the create request where a hard per-job bound matters.

VM-isolated execution with no default egress

This policy requires VM isolation and supplies no default egress rules. It blocks outbound DNS traffic on UDP/TCP port 53, but permits sandboxes to declare other egress because allowedEgress is empty.

policy.json

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

This policy does not enforce complete network isolation. An empty allowedEgress list permits explicit destination rules, and platform storage access is granted separately. dnsEgress blocks outbound port 53, but does not block DNS over other permitted transports, such as HTTPS.

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/[GITHUB-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": { "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.

This example sets egress only. To constrain inbound access to CUSTOM-visibility ports, add allowedIngress and, if needed, defaultIngress. See Constrain network access.

Pin admin defaults with the base layer

Any of the policies above can also carry a base fragment: admin attachments applied to every sandbox on the runner, whatever it asks for. This variant of the internal worker policy pins node selection, a pull secret for the private registry, and a cost-attribution label on all sandboxes.

policy.json

{
  "displayName": "Internal workers, pinned scheduling",
  "base": {
    "spec": {
      "nodeSelector": { "workload": "sandbox" },
      "tolerations": [
        { "key": "sandbox-only", "operator": "Exists", "effect": "NoSchedule" }
      ],
      "imagePullSecrets": [{ "name": "regcred" }]
    },
    "metadata": {
      "labels": { "cost-center": "sandboxes" }
    }
  },
  "constraints": {
    "resources": {
      "defaultCpu": "1",
      "defaultMemory": "2Gi",
      "maxCpu": "8",
      "maxMemory": "16Gi",
      "requireLimits": true
    },
    "image": { "allowedRegistries": ["ghcr.io/[GITHUB-ORG]"] },
    "security": {
      "allowPrivileged": false,
      "allowedRuntimeClasses": ["kata-qemu"],
      "defaultCpuRuntimeClass": "kata-qemu",
      "allowedSeccompProfiles": ["RuntimeDefault"]
    },
    "lifecycle": { "defaultLifetimeSeconds": 604800 }
  }
}

The base fragment is a Kubernetes pod-specification subset with camelCase keys, unlike the constraint fields around it, and unknown keys are rejected. It accepts scheduling and runtime plumbing only: nodeSelector, tolerations, imagePullSecrets, volumes, topologySpreadConstraints, hostAliases, DNS settings, a single containers entry limited to name, env, envFrom, volumeMounts, and volumeDevices, and pod labels and annotations. Security-sensitive fields are rejected: securityContext, runtimeClassName, initContainers, affinity, host namespaces, hostPath volumes, non-default service accounts, and namespace, which stays runner-owned. Typed concerns such as lifetime, images, and egress belong in constraints, not in base. On a CKS cluster, template attachments specialize this fragment per template: imagePullSecrets and tolerations are unioned and deduplicated, other lists append, map keys are overridden per key, and same-name conflicts reject the create. For the current enforcement status of base, see the base layer.

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

​VM-isolated execution with no default egress

​Internal worker cluster

​Pin admin defaults with the base layer

​Vary the posture across clusters

​See also

GPU data science cluster

Shared agent cluster with allowlisted egress

Ephemeral CI cluster

VM-isolated execution with no default egress

Internal worker cluster

Pin admin defaults with the base layer

Vary the posture across clusters

See also