Toolbox images

Dieser Inhalt ist noch nicht in deiner Sprache verfügbar.

Roadmap 0.2 In 0.1, workers run in-process or locally and use the tools available there. The container runner is on main (opt-in, ships with 0.2) and uses a generic run-node image; toolbox images are still planned.

An agent declares the toolbox it needs in its agents.md:

runtime:
  runner: kubernetes-job
  toolbox: trivy
  egress:
    - ghcr.io

What a toolbox image is

Minimal: distroless or Alpine base with only the listed binaries (for example git + node, trivy, jira-cli). No shell where possible.
Locked down: runs as non-root with a read-only root file system.
Reproducible: built from a catalogue in the repository and pinned by digest (the catalogue has no digests yet).
Verifiable: to be signed with cosign, shipped with an SBOM (syft) and vulnerability-scanned (trivy) in CI. None of this is built yet.
Fenced in: outbound traffic per toolbox is allowlisted (Kubernetes NetworkPolicy or the container network).

Secrets are injected per step, scoped to what the step may use, and revoked when it ends. The credential broker for this is on main, opt-in with the container runner, and ships with 0.2.

Why not one big image?

A single image with every tool gives every agent every capability. With toolboxes, an agent that triages CVEs cannot push to Git, because git is not in its image and GitHub is not in its egress allowlist. The audit gate still checks each call; the toolbox removes whole classes of mistakes before they can happen.