[0xmhha]

Summary

playground-backend now runs sandboxes on Kubernetes as Pods under a gVisor RuntimeClass, instead of through a node's Docker socket (kingsejong-lang/playground-backend#23). This updates §5 of the security protocol to match:

• Item 2: gVisor requirement for both modes. Adds the admission rules that apply to every Pod in the sandbox namespace: gVisor RuntimeClass, no privileged or root containers, no added capabilities, no host namespaces or ports, emptyDir volumes only, no token mount, no init or ephemeral containers, digest-pinned images from the configured registry, Pod Security restricted, default-deny network, and a Pod-count quota.
• Item 3: how the container settings map onto Pods.
  • gVisor networking is off.
  • /workspace and /tmp are memory emptyDir volumes, and /workspace is not noexec.
  • A static helper in the image sets the rlimits before execve.
  • podPidsLimit bounds the host side.
  • Every run gets its own uid, which the backend already did.
• Item 5: under gVisor, a Python run that ends with MemoryError is reported as a memory-limit violation.
• Item 8: on Kubernetes, no component holds a container-runtime socket. The execution service may only manage and exec into Pods in the sandbox namespace.

No change to the RPC contract or generated code.