72 lines
5.2 KiB
Markdown
72 lines
5.2 KiB
Markdown
# MeshCentral ↔ OpenClaw Bridge — Final Hardening Review
|
|
|
|
**Date:** 2026-08-25
|
|
**Reviewer:** Clawdia (manager review)
|
|
**Scope:** Current implementation under `implementation/src/`
|
|
**Purpose:** Disposition the earlier independent review against the hardened local source.
|
|
|
|
## Verdict
|
|
|
|
**Local read-only MVP gate: PASS.** The implementation passes the local verification gate and contains the required controls for preparing a tightly scoped live read-only test.
|
|
|
|
**Live test: NOT YET APPROVED.** A live connection remains gated on deployment-specific checks and Rob's explicit approval immediately before execution.
|
|
|
|
## Verification evidence
|
|
|
|
- `npm test -- --runInBand`: **11 suites, 90 tests passed**
|
|
- `npm run build`: **passed**
|
|
- `npm run lint`: **passed with no errors or warnings**
|
|
- No live MeshCentral connection has been attempted.
|
|
|
|
## Prior finding disposition
|
|
|
|
| Finding | Current disposition | Evidence / residual risk |
|
|
|---|---|---|
|
|
| Credential/error leakage | **Addressed locally** | Credentials are validated before use; user-facing configuration failures are generic; audit/logging paths use redacted summaries. Residual risk: live secret handling still requires a protected runtime mechanism and operational verification. |
|
|
| Credential validation/sanitization | **Addressed locally** | `validateCredentials()` is called before encoding/storage; credentials are never intentionally logged. Residual risk: the control-channel auth header necessarily contains the credential material in memory during connection. |
|
|
| TLS validation | **Addressed locally** | WebSocket options explicitly set `rejectUnauthorized: true`; no bypass is present. Residual risk: the actual deployment certificate chain/private CA must be verified from the bridge host. |
|
|
| Response validation and size limits | **Addressed locally** | Responses are size-bounded and parsed/validated; action-specific schemas and action matching are enforced. Residual risk: protocol compatibility with the deployed server remains unverified until a read-only test. |
|
|
| Request concurrency/rate limiting | **Addressed locally** | Semaphore and token-bucket controls apply to outbound requests; configuration has bounded validation and safe defaults. Residual risk: limits are protective controls, not a substitute for MeshCentral capacity testing. |
|
|
| Device/group allowlists | **Addressed locally** | Adapter validates allowlist entries and filters/checks device/group targets. Residual risk: the intended PVE3 identifier and group mapping must be confirmed before live use. |
|
|
| Sensitive data in logs | **Addressed locally with operational caveat** | Structured logger and audit utilities redact credential keys, auth headers, token-like values, and encoded secret patterns. Residual risk: logs still contain inventory metadata and must be stored with appropriate permissions/retention. |
|
|
| Separate handshake/request timeout | **Deferred, non-blocking** | A single bounded timeout is used for connection and requests. This does not expand capability or permit unsafe actions; it should be revisited after live read-only validation. |
|
|
| Automatic reconnection/session renewal | **Deferred, non-blocking for first test** | No automatic reconnect is enabled, reducing replay risk. A dropped session fails rather than autonomously replaying requests. |
|
|
| Structured audit logging | **Addressed locally** | Adapter and client use the controlled logger for audit events; redaction is applied. Operational sink/retention must be selected before deployment. |
|
|
|
|
## Live-test entry criteria still open
|
|
|
|
These are deployment facts, not local code failures:
|
|
|
|
1. Confirm `mesh.ledrew.me` resolves to the intended internal MeshCentral service from the proposed bridge host.
|
|
2. Confirm the correct control-channel URL/path and whether TLS is terminated at a reverse proxy.
|
|
3. Verify the certificate chain or approved private CA bundle from the bridge host; never disable verification.
|
|
4. Confirm `sa_clawdia` is dedicated and read-only for this first test.
|
|
5. Confirm the exact PVE3 device ID/group and configure it as the sole allowed target.
|
|
6. Inject the credential through a protected runtime secret mechanism; do not place it in source, prompts, command arguments, or logs.
|
|
7. Confirm audit-log destination, permissions, and retention.
|
|
8. Obtain Rob's explicit approval immediately before the live connection.
|
|
|
|
## Scope restrictions for first live test
|
|
|
|
Allowed only:
|
|
|
|
- Authentication/connection health check
|
|
- Server version
|
|
- Device groups
|
|
- Device inventory
|
|
- Selected metadata for the single approved PVE3 target
|
|
|
|
Prohibited:
|
|
|
|
- Diagnostics that execute commands
|
|
- Remote shell, file transfer, or arbitrary command execution
|
|
- Reboots, shutdowns, service changes, or any state-changing action
|
|
- PVE1/PVE2 production-cluster targeting
|
|
- Public exposure of the bridge or MeshCentral
|
|
|
|
## Risk acceptance
|
|
|
|
No deferred feature is accepted as a reason to enable remote actions. The deferred timeout separation and reconnect behavior are explicitly **non-blocking only for a single, read-only, single-target test** and remain unsuitable for production fleet operation without further design/review.
|
|
|
|
The live-test gate remains closed until the entry criteria above are checked and Rob approves the specific read-only procedure immediately before execution.
|