OpsRehearse v0.1 runs on a trusted local machine or isolated lab host. It is not designed for internet exposure, untrusted users, production targets, or shared multi-tenant use.
The primary security objective is to prevent a rehearsal action from escaping the managed demo target or remaining active after the exercise ends.
- host integrity;
- control-plane data and operator credentials;
- Help Desk target integrity and deterministic baseline;
- target and control-plane database credentials;
- Runner action credentials;
- Runbooks, evidence, reports, and audit history;
- correctness of verification results;
- availability of reset and cleanup paths.
Browser input is untrusted. The control plane validates all identifiers, text, state transitions, and evidence content. Rendered logs and notes are escaped as data.
The control plane is not trusted to define executable behavior. The Runner accepts only authenticated, short-lived envelopes for compiled action kinds and applies its own parameter schemas and limits.
The Runner has target-scoped credentials for the built-in demo environment. It cannot use those credentials against the control plane or another environment.
The target may expose health, log, and reset interfaces on the isolated network. It cannot mutate exercise state or evidence directly.
These are separate PostgreSQL services with separate credentials and connection limits. The fault action must never open a connection to the control-plane database.
The Runner has no Docker socket, privileged container mode, host filesystem mount, or host shell. The v0.1 fault is implemented through the target PostgreSQL protocol and the target's fixed reset interface.
Risk: An action parameter contains a shell command, executable path, or script.
Controls:
- fixed compiled action registry;
- strict parameter schemas with unknown fields rejected;
- no shell action kind;
- no process-launch parameter;
- no Docker socket or host shell.
Acceptance criterion: Contract tests submit command, script, executable, and shell metacharacter fields to every action type and the Runner rejects each request before side effects.
Risk: A valid action runs against an unintended database or production-like environment.
Controls:
- target ID and environment class in every envelope;
- v0.1 accepts only
builtin-helpdeskanddemo; - database host, port, database name, and credential reference are compiled configuration, not request parameters;
- target credential cannot access the control-plane database.
- the reserved management interface exposes fixed seed and reset operations, not SQL or generic administration.
Acceptance criterion: Requests with any other target, environment, hostname, port, or database identifier are rejected.
Risk: The action consumes all database connections, including those needed for safe inspection or recovery.
Controls:
- action-specific connection ceiling;
- target database configured with reserved administrative capacity;
- the Runner opens connections only with the dedicated fault role;
- the fault role has no reserved-capacity privilege;
- the target management service owns reserved-capacity access and exposes only fixed bounded operations;
- recovery closes locally held connections without requiring a new database connection;
- hard fault lease of ten minutes.
Acceptance criterion: The active fault never exceeds its configured ceiling, reserved capacity remains available only to the target management path, the fault role cannot use that capacity, and lease expiry closes every held connection.
Risk: A retried request starts a second fault or repeats reset unexpectedly.
Controls:
- signed short-lived envelope;
- unique idempotency key;
- issued-at and expiry validation;
- one active fault per target;
- stored action result returned for duplicate keys.
Acceptance criterion: Replaying an accepted envelope does not create another side effect and returns the original action identity.
The v0.1 transport authenticates canonical action envelopes and Runner results with HMAC-SHA256. The signing secret is provided at runtime, is not present in either application database, and is never included in evidence or reports. HMAC does not make an untrusted network safe; v0.1 remains limited to an isolated local network.
Risk: The operator loses control while fault connections remain open.
Controls:
- Runner-local lease deadline;
- Runner-local active-action journal;
- automatic recovery on lease expiry;
- restart reconciler closes held connections before accepting work.
Acceptance criterion: Disconnecting the control plane or restarting the Runner cannot leave fault connections active beyond the lease plus a 15-second cleanup allowance.
Risk: Two runs alter the same target and invalidate evidence or reset state.
Controls:
- control-plane active-run lock;
- Runner target lock;
- reset-status gate;
- target rejects mismatched exercise correlation identifiers.
Acceptance criterion: A second exercise cannot enter injecting while another run is non-terminal or the reset lock is set.
Risk: Logs, errors, or operator notes store credentials or sensitive request data.
Controls:
- structured log allowlist for automatic collection;
- token, password, authorization-header, and connection-string redaction;
- bounded excerpts rather than full log archives;
- payload size limits;
sensitivityandredaction_statusfields;- reports use redacted evidence only.
Acceptance criterion: Seeded credentials in test logs and notes are replaced before persistence and do not appear in generated reports.
Risk: A support request or log line injects HTML, script, terminal control sequences, or misleading report structure.
Controls:
- store evidence as data, not markup;
- escape rendered values;
- strip terminal control sequences;
- report generation uses fixed templates;
- log source and timestamp remain visible.
Acceptance criterion: HTML, script, Markdown heading, and terminal-control test payloads render as inert text.
Risk: An operator supplies a probe URL that accesses arbitrary local or remote services.
Controls:
- probe destinations are registered with the built-in target;
- action envelopes reference a probe key, not a URL;
- redirects are disabled;
- target network is isolated.
Acceptance criterion: Probe requests cannot supply or alter scheme, host, port, path, or redirect destination.
Risk: A shallow health endpoint passes while the request path or worker remains broken.
Controls:
- mandatory verification includes API, database, worker, backlog, and stability checks;
- checks produce evidence;
- operator cannot override
unverified; - reset is separate from recovery verification.
Acceptance criterion: Breaking any mandatory dependency causes verification to fail even when the liveness endpoint returns success.
Risk: Reset removes the exercise record or changes the final result.
Controls:
- target data and control-plane evidence use separate databases;
- reset changes only the built-in target;
- report includes both verification and reset results;
- reset failure creates a global run lock.
Acceptance criterion: Evidence hashes and report inputs remain unchanged across target reset.
Risk: An untrusted user gains operator access.
Controls:
- v0.1 binds to local or explicitly configured lab interfaces;
- one local password hash, no default credential;
- secure session cookie settings;
- CSRF protection on mutations;
- no claim of untrusted-network safety.
Acceptance criterion: Installation requires creation of a non-default operator credential, and state-changing browser requests require a valid session and CSRF token.
- Validation uncertainty results in rejection.
- Runner uncertainty about target identity results in rejection.
- Runner uncertainty about an unfinished fault results in cleanup and a target lock.
- Verification uncertainty results in
unverified. - Reset uncertainty results in
reset_failedand blocks the next run. - Evidence redaction uncertainty marks evidence restricted and excludes its payload from the report.
The v0.1 security suite covers action-schema bypass, replay, expiry, concurrent run attempts, target confusion, lease expiry, Runner restart, credential redaction, report injection, SSRF attempts, CSRF, and reset isolation.
Dependency scanning and secret scanning are release checks. Their presence does not make the release enterprise-ready.
- One trusted local operator.
- No SSO or multi-factor authentication.
- No tenant isolation.
- No production target.
- No general external adapter.
- No remote Runner fleet.
- No high-availability control plane.
Changing any limitation requires a new threat-model review before implementation.