Harden Podman and Kubernetes sandbox execution

[eshulman2]

Problem

Forge containers have resource limits and rootless Podman networking, but the runtime contract does not consistently require non-root execution, a read-only root filesystem, capability dropping, seccomp, no-new-privileges, or Kubernetes service-account isolation.

The Kubernetes driver proposed by PR #243 also needs an explicit pod security posture; selecting a service account or accepting the default token mount can expose the cluster API to agent-controlled code.

Proposed solution

Harden Podman and Kubernetes execution using the common sandbox security policy:

• run the agent as an unprivileged UID/GID
• drop Linux capabilities and prevent privilege escalation
• apply a maintained seccomp profile
• make the container root filesystem read-only
• provide only explicit writable workspace and temporary paths
• disable host namespace sharing and privileged/container-engine mounts
• disable automatic Kubernetes service-account token mounting by default
• enforce resource requests/limits and bounded temporary storage
• fail closed when the configured runtime cannot apply required controls

Acceptance criteria

• Forge's normal implementation and review tasks succeed as non-root.
• Podman uses capability drop, no-new-privileges, seccomp, and read-only-root controls.
• Kubernetes Jobs use restrictive pod/container security contexts.
• Kubernetes service-account tokens are not mounted by default.
• Only declared paths are writable.
• Tests attempt and fail to write outside allowed paths, escalate privileges, and access an undeclared service-account token.
• Documentation identifies any compatibility escape hatches and marks them unsafe.

Dependencies

• Make sandbox runner pluggable with different execution drivers #30 / PR Make sandbox runner pluggable with Kubernetes driver support #243
• Define sandbox driver capabilities and execution requirements #265

Estimate

AI-assisted: 3–6 engineering days, plus live Kubernetes/OpenShift verification.