feat: enforce secure container mounts, identity, and limits

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

dries/ocman#379

dries commented

2026-07-18 00:16:58 +02:00

Owner

Parent

#375

What to build

Harden managed OpenCode containers so container mode provides real defense-in-depth rather than merely relocating the process. Provision the minimum config, skills, provider credentials, mounts, user identity, capabilities, and resource access needed for normal agent work.

Unsafe conveniences must not be silent defaults. In particular, do not mount a container-engine socket, complete home directory, SSH directory, host credential store, or unrelated repositories.

Acceptance criteria

Containers run as a non-root UID/GID compatible with host workspace ownership.
The root filesystem is read-only where OpenCode permits, with explicit writable paths only where required.
Linux capabilities are dropped, privilege escalation is disabled, host PID/network namespaces are not used, and privileged mode is rejected.
CPU, memory, and PID limits have documented safe defaults and configurable overrides.
Project and worktree mounts expose only the selected repository and its ocman-managed worktrees.
OpenCode config and ocman skills are provisioned through dedicated generated/read-only paths rather than broad home mounts or dangling host symlinks.
Provider secrets are injected minimally and are not embedded in images, labels, logs, diagnostics, or command output.
Host SSH agents, keys, keychains, forge credentials, and package credentials are not exposed by default; opt-ins describe their risk.
The Docker/Podman socket is never mounted into an agent container.
Generated files remain readable and writable from host git and terminals.
Network behavior is explicit: provider/package access works, host service reachability is not accidentally broadened, and future egress restriction points are documented.
Tests inspect the generated runtime configuration and reject unsafe mount/privilege combinations.
Security documentation includes the threat boundary and residual risks, especially source/secret exfiltration over allowed network access.

Blocked by

#378

## Parent #375 ## What to build Harden managed OpenCode containers so container mode provides real defense-in-depth rather than merely relocating the process. Provision the minimum config, skills, provider credentials, mounts, user identity, capabilities, and resource access needed for normal agent work. Unsafe conveniences must not be silent defaults. In particular, do not mount a container-engine socket, complete home directory, SSH directory, host credential store, or unrelated repositories. ## Acceptance criteria - [ ] Containers run as a non-root UID/GID compatible with host workspace ownership. - [ ] The root filesystem is read-only where OpenCode permits, with explicit writable paths only where required. - [ ] Linux capabilities are dropped, privilege escalation is disabled, host PID/network namespaces are not used, and privileged mode is rejected. - [ ] CPU, memory, and PID limits have documented safe defaults and configurable overrides. - [ ] Project and worktree mounts expose only the selected repository and its ocman-managed worktrees. - [ ] OpenCode config and ocman skills are provisioned through dedicated generated/read-only paths rather than broad home mounts or dangling host symlinks. - [ ] Provider secrets are injected minimally and are not embedded in images, labels, logs, diagnostics, or command output. - [ ] Host SSH agents, keys, keychains, forge credentials, and package credentials are not exposed by default; opt-ins describe their risk. - [ ] The Docker/Podman socket is never mounted into an agent container. - [ ] Generated files remain readable and writable from host git and terminals. - [ ] Network behavior is explicit: provider/package access works, host service reachability is not accidentally broadened, and future egress restriction points are documented. - [ ] Tests inspect the generated runtime configuration and reject unsafe mount/privilege combinations. - [ ] Security documentation includes the threat boundary and residual risks, especially source/secret exfiltration over allowed network access. ## Blocked by - #378

dries added the

labels

dries referenced this issue

2026-07-18 00:17:32 +02:00

test: qualify shared OpenCode SQLite across containers #382

2026-07-18 00:17:46 +02:00

feat: ship container runtime settings, diagnostics, and lifecycle UX #383

2026-07-18 00:18:34 +02:00

epic: optionally run managed OpenCode instances in containers #375