#Runtime Isolation and Network Controls

Agent Sandbox manages workload lifecycle; it does not replace Kubernetes authorization, network isolation, Pod security, image governance, or the runtime security boundary. Use defense in depth for every workload that executes untrusted or dynamically generated code.

#Defense in Depth

A secure deployment combines controls at several layers:

No single layer eliminates the need for the others.

#Pod Security Baseline

Use a restricted-compatible Pod and container security context unless a reviewed workload has a documented exception:

spec:
  podTemplate:
    spec:
      automountServiceAccountToken: false
      securityContext:
        runAsNonRoot: true
        runAsUser: 1000
        runAsGroup: 1000
        seccompProfile:
          type: RuntimeDefault
      containers:
        - name: worker
          image: example.registry/approved/sandbox-runtime:1.0.0
          securityContext:
            allowPrivilegeEscalation: false
            capabilities:
              drop:
                - ALL
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              cpu: 500m
              memory: 512Mi

Avoid privileged containers, host networking, hostPath, host device mounts, and unnecessary Linux capabilities. Apply ResourceQuota and LimitRange in business namespaces so one tenant cannot exhaust shared cluster resources.

#RBAC and Service Accounts

Sandbox workloads should not receive Kubernetes API credentials by default. Set automountServiceAccountToken: false unless the workload has an explicit API requirement.

When API access is required:

1. Create a dedicated ServiceAccount in the business namespace.
2. Grant only the resource names and verbs the application needs.
3. Prefer a namespaced Role and RoleBinding over cluster-wide permissions.
4. Separate platform-administrator access from workload access.
5. Do not inject platform management tokens, cluster-admin credentials, or unrelated long-lived secrets.

A business user normally needs access to Sandbox resources and, when required, read access to the managed Pod and pods/exec. The user does not need permission to edit CRDs, the controller Deployment, ClusterRoles, or resources in other namespaces.

#NetworkPolicy Order

A default-deny policy can immediately break DNS, required internal APIs, telemetry, sidecars, or the business endpoint. Apply network controls in this order:

1. Label the Sandbox workload through podTemplate.metadata.labels.
2. Define allow rules for DNS and explicitly approved destinations.
3. Apply the allow policy.
4. Verify DNS and required endpoint connectivity from a test Sandbox.
5. Apply or tighten the default-deny posture.
6. Verify connectivity again and inspect CNI policy events when behavior differs from the manifest.

For an unmanaged template, the business namespace owns the NetworkPolicy lifecycle. Do not use an unrestricted 0.0.0.0/0 egress rule as a substitute for identifying the required business destinations. Avoid access to cloud metadata services and internal network ranges unless the workload has an approved requirement.

NetworkPolicy enforcement depends on the cluster CNI. A successfully accepted Kubernetes object is not proof that the selected CNI enforces every requested rule.

#Select a RuntimeClass

List the RuntimeClasses installed by the cluster administrator:

kubectl get runtimeclass

Select an existing runtime in the Sandbox Pod template:

spec:
  podTemplate:
    spec:
      runtimeClassName: kata-qemu

kata-qemu is only an example name. Use the exact RuntimeClass configured in the target cluster. If the RuntimeClass does not exist or its nodes are unavailable, the Pod remains unscheduled.

A practical risk-based strategy is:

• Use the standard runtime for low-risk, trusted internal tasks when the cluster security baseline is sufficient.
• Use gVisor or another sandboxed runtime when it is installed, validated, and suitable for the workload.
• Use Kata Containers for higher-risk or untrusted execution when VM-backed isolation and compatible nodes are available.

Agent Sandbox does not install or operate these runtimes.

#Kata Containers Boundary

With Kata Containers, the workload runs inside a lightweight virtual machine with a guest kernel. Compared with a standard container that shares the host kernel, this adds a guest VM and hypervisor boundary between the workload and the node.

Kata is well suited to higher-risk tasks such as user-submitted code, LLM-generated code, browser automation, external file processing, and multi-tenant tool execution. Its actual isolation strength depends on node virtualization, the hypervisor, Kata configuration and version, device exposure, storage mounts, networking, and credential injection.

Warm pools can reduce the startup latency of a Kata-backed workload. A warm pool is a performance mechanism, not a security boundary.

#What Agent Sandbox Does Not Replace

Agent Sandbox and Kata Containers do not replace:

• Kubernetes authentication and least-privilege authorization.
• Pod Security and admission controls.
• NetworkPolicy and CNI enforcement.
• Image signing, provenance, version pinning, and vulnerability management.
• Secret minimization and rotation.
• ResourceQuota, LimitRange, scheduling governance, and audit.
• Application-level validation of user input, uploaded files, tools, and external destinations.

Treat the controller and platform routing components as trusted control-plane services. Treat Sandbox workloads as untrusted unless the application has a stronger, verified trust model.