sharang/compliance-scanner-agent
1
0
Fork 0
Code Issues 79 Pull Requests 1 Actions Packages Projects Releases 1 Wiki Activity

Epic · Werkbank — dynamic-execution runner (pull queue, pluggable executors, on-prem) #194

New Issue
Closed
opened 2026-07-17 08:14:30 +00:00 by sharang · 2 comments
sharang commented 2026-07-17 08:14:30 +00:00
Owner
Copy Link
Copy Source

Extract dynamic-test execution out of the cloud agent into Werkbank — a separate, sandboxed, pull-based runner. Repo: https://gitea.meghsakha.com/sharang/werkbank · Design: docs/DESIGN.md

Why

Dynamic testing needs privileged execution (containers, QEMU/KVM), must reach targets our cloud can't, and must respect data residency. Running it inside the agent makes the agent host-root-equivalent and can't run on a customer's premises. One execution plane serves soft-PLC provisioning (#183), QEMU firmware boot (#149), DAST, and pentest.

Locked decisions

  • Pull transport + DB-table queue (Mongo collection; lease/heartbeat/visibility-timeout). Swap for a broker later only if throughput demands it.
  • CI-runner-style executors: Shell, Docker, and later K8s. QEMU runs inside the Docker executor (containerized) — no separate VM executor. Host is unknown; the executor abstraction insulates jobs from it.
  • Thin slice first, then generalize.
  • Own repo (sharang/werkbank), sharing the job/result contract via compliance-core.

How #183 maps

PR #193's provision_and_test is already a self-contained job body returning plain data -> it becomes the plc-provision job; DockerSoftPlc -> the Docker executor; the in-agent PLC_RUNTIME_ENABLED path -> the embedded/degenerate mode.

Stories (thin slice = 1 through 5)

  1. Job + result contract in compliance-core.
  2. DB-table job queue in the control plane (enqueue/lease/heartbeat/complete + visibility timeout).
  3. Runner skeleton (repo scaffold, config, pull loop, lease/heartbeat, Executor trait).
  4. Docker executor + plc-provision — lift provision_and_test in -> thin-slice end-to-end.
  5. Control-plane cut-over — agent enqueues plc-provision and persists runner results.
  6. qemu-boot job — firmware dynamic (#149), QEMU-in-container.
  7. On-prem runner mode — tenant-scoped, outbound-only, results-only egress, data-residency.
  8. K8s executor, then Shell executor.
  9. Registration, labels & routing — capability-matched leasing.
  10. Observability & hardening — event/log streaming, signed leases, ephemeral per-job creds.

Relates to #183 (soft-PLC), #149 (QEMU firmware).

Extract dynamic-test execution out of the cloud agent into **Werkbank** — a separate, sandboxed, pull-based runner. Repo: https://gitea.meghsakha.com/sharang/werkbank · Design: [docs/DESIGN.md](https://gitea.meghsakha.com/sharang/werkbank/src/branch/main/docs/DESIGN.md) ## Why Dynamic testing needs privileged execution (containers, QEMU/KVM), must reach targets our cloud can't, and must respect data residency. Running it inside the agent makes the agent host-root-equivalent and can't run on a customer's premises. One execution plane serves soft-PLC provisioning (#183), QEMU firmware boot (#149), DAST, and pentest. ## Locked decisions - **Pull transport + DB-table queue** (Mongo collection; lease/heartbeat/visibility-timeout). Swap for a broker later only if throughput demands it. - **CI-runner-style executors**: Shell, Docker, and later K8s. QEMU runs *inside* the Docker executor (containerized) — no separate VM executor. Host is unknown; the executor abstraction insulates jobs from it. - **Thin slice first**, then generalize. - **Own repo** (sharang/werkbank), sharing the job/result contract via compliance-core. ## How #183 maps PR #193's provision_and_test is already a self-contained job body returning plain data -> it becomes the plc-provision job; DockerSoftPlc -> the Docker executor; the in-agent PLC_RUNTIME_ENABLED path -> the embedded/degenerate mode. ## Stories (thin slice = 1 through 5) 1. Job + result **contract** in compliance-core. 2. **DB-table job queue** in the control plane (enqueue/lease/heartbeat/complete + visibility timeout). 3. **Runner skeleton** (repo scaffold, config, pull loop, lease/heartbeat, Executor trait). 4. **Docker executor + plc-provision** — lift provision_and_test in -> thin-slice end-to-end. 5. **Control-plane cut-over** — agent enqueues plc-provision and persists runner results. 6. **qemu-boot job** — firmware dynamic (#149), QEMU-in-container. 7. **On-prem runner mode** — tenant-scoped, outbound-only, results-only egress, data-residency. 8. **K8s executor**, then **Shell executor**. 9. **Registration, labels & routing** — capability-matched leasing. 10. **Observability & hardening** — event/log streaming, signed leases, ephemeral per-job creds. Relates to #183 (soft-PLC), #149 (QEMU firmware).
sharang added the epicenhancement labels 2026-07-17 08:14:30 +00:00
sharang commented 2026-07-17 08:15:25 +00:00
Author
Owner
Copy Link
Copy Source

Stories filed:

Thin slice (do first, in order):

  • #195 — WB-01 · Job + result contract in compliance-core
  • #196 — WB-02 · DB-table job queue (control plane)
  • #197 — WB-03 · Werkbank runner skeleton
  • #198 — WB-04 · Docker executor + plc-provision job (thin slice)
  • #199 — WB-05 · Control-plane cut-over to enqueue plc-provision

Then:

  • #200 — WB-06 · qemu-boot job (firmware dynamic, #149)
  • #201 — WB-07 · On-prem runner mode
  • #202 — WB-08 · K8s executor, then Shell executor
  • #203 — WB-09 · Registration, labels & capability-matched routing
  • #204 — WB-10 · Observability & security hardening

Design doc: https://gitea.meghsakha.com/sharang/werkbank/src/branch/main/docs/DESIGN.md

Stories filed: **Thin slice (do first, in order):** - #195 — WB-01 · Job + result contract in compliance-core - #196 — WB-02 · DB-table job queue (control plane) - #197 — WB-03 · Werkbank runner skeleton - #198 — WB-04 · Docker executor + plc-provision job (thin slice) - #199 — WB-05 · Control-plane cut-over to enqueue plc-provision **Then:** - #200 — WB-06 · qemu-boot job (firmware dynamic, #149) - #201 — WB-07 · On-prem runner mode - #202 — WB-08 · K8s executor, then Shell executor - #203 — WB-09 · Registration, labels & capability-matched routing - #204 — WB-10 · Observability & security hardening Design doc: https://gitea.meghsakha.com/sharang/werkbank/src/branch/main/docs/DESIGN.md
sharang commented 2026-07-17 08:19:05 +00:00
Author
Owner
Copy Link
Copy Source

Moved to the Werkbank tracker: sharang/werkbank#1. Closing here — Werkbank is tracked in its own repo.

Moved to the Werkbank tracker: sharang/werkbank#1. Closing here — Werkbank is tracked in its own repo.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
P0-demo
CERTifAI P0 demo build tickets (CS-*)
 bug
critical
enhancement
epic
Tracking issue spanning multiple sub-issues
 high
infrastructure
onboarding
Multi-target onboarding wizard redesign
 performance
security
v0.3.0
No labels enhancement epic
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
Benjamin_Boenisch sharang (Sharang Parnerkar)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: sharang/compliance-scanner-agent#194