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 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/[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", "kata-qemu-nvidia-gpu"],
      "defaultCpuRuntimeClass": "kata-qemu",
      "defaultGpuRuntimeClass": "kata-qemu-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.

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/[GITHUB-ORG]/sandbox-base:pinned"] },
    "network": {
      "allowedEgress": [],
      "defaultEgress": [],
      "denyDns": true
    },
    "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" }
  }
}

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/[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.

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.

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

​Untrusted code execution

​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

Untrusted code execution

Internal worker cluster

Pin admin defaults with the base layer

Vary the posture across clusters

See also