Security assurance

For: operators assessing a deployment's security.

Orchestrator Zero has not had an independent security review or penetration test. Automated checks do not establish that independent assurance. Assess the security model and threat boundaries before relying on a control.

Deployment boundaries

The threat model explains the scope of each control, including management's certificate authority, tenant payload access from nodes, tier-0 execution, webhook responses and retained API keys. Put workloads that must not share payload access in separate tenants. Labels do not provide that separation.

Keep sandbox and credential requirements beside the configuration that enforces them: sandbox tiers, protected files, egress and credential injection.

Quota accounting after a crash

Usage rows and owner or team quota charges are separate writes. Outstanding durable reservations and saved retries repair missing charges, applying each charge once. A crash can still lose a charge when no recovery record survives: an unreserved call interrupted between its usage and quota writes, for example, or a failed charge kept only in memory.

Failed metering writes are retained on disk when the metering directory is available. An orderly stop retries them for up to five seconds and logs writes left for the next start. If that directory cannot be opened, retries use memory and may be lost on shutdown.

Review usage and quota totals after an unclean stop. This limitation remains open. See Contracts and limits for enforcement during a run.

Runtime selection by an edge

For released node builds, rolling back to an older release requires a rollback allowance signed by management. Development builds without an ordered release version can move freely. Within an accepted release, the edge selects the runtime so that rollouts can roll back.

An attacker controlling an edge can select an older runtime still listed by an accepted signed release. They cannot select one absent from every signed release that the node accepts. See Release verification.

Error records and source text

Internal errors returned by the runtime and admin APIs, node and join routes, connection pages, streams, uploads and diagnostic reports use fixed wording; the server log retains the cause.

Refusals still explain the input that was rejected. Job steps can record provider or plugin answers, and errors from a source the caller selected can quote that source. Previously recorded failed changes keep their existing text. Account for those records when deciding who may read job content and logs.

Release verification

Releases use the release key and include SBOMs and SLSA provenance. Keyless Sigstore signing and GitHub build attestations are not available. Follow Check a release to verify the artifacts that are supplied.

Report a problem

Email [email protected] with [security] at the start of the subject. Describe the affected version, configuration, impact and steps to reproduce. Do not publish exploit details in an issue or pull request. Reporting does not require repository access.