Prepare the Taskstream runner safely
Use this page when you prepare the isolated execution boundary for future Taskstream shell and Lua capabilities. The runner is a separate internal component. The Workspace server never receives a Docker or Podman socket.
Deploying the runner does not enable shell or lua. Both types remain contained under the current restricted security contract. Do not enable a tenant feature merely because runner health is positive.
Check the prerequisites
- Run the component as a dedicated non-root user.
- Select exactly one rootless driver: Docker or Podman.
- Confirm that this user owns the Unix socket and that only the owner can access it.
- Use fully pinned image digests for both shell and Lua modes.
- Provide the runtime binary and fixed seccomp profile without write bits, and provide all certificates as external files.
- Keep the server key and the future Workspace client key owner-only. Never copy key material into jobs, environment variables, logs, or tickets.
The runner never starts plain HTTP. It requires TLS 1.3 and a client certificate issued by the configured CA. There is no insecure fallback and no automatic switch between Docker and Podman.
Interpret readiness correctly
GET /v1/health returns only ready or unavailable. ready confirms the local mTLS, rootless runtime, image, seccomp, and probe-container checks. It does not confirm Taskstream authority, a tenant feature, or approval of an existing job.
If health remains unavailable, stop the rollout. Inspect runtime ownership, pinned images, the seccomp file, and certificates in the privileged operations environment. Do not copy raw failures into Taskstream logs and never bypass the check with a rootful socket.
Understand the isolation contract
Every future execution receives a fresh container without networking or host volumes. The root filesystem stays read-only, the process environment is cleared, Linux capabilities are dropped, and both no-new-privileges and the fixed seccomp profile apply. CPU, memory, processes, tmpfs, runtime, and output are bounded. Cancellation, timeout, client disconnect, and shutdown use the same cleanup path.
The server capability response remains the only editing authority for Taskstream types. Check the current contract in Automation > Taskstream > Jobs; historical shell or Lua values remain visible but inert.