feat(containers): CLI transparency and per-container isolation posture

Two features answering the same critique of opaque management UIs: show the
operator what the tool actually does, and what their containers actually are.

CLI transparency
- Add src/services/cli-transparency.js, a pure derivation service mapping an
  action key plus typed params to the equivalent docker / docker compose
  command. Covers container lifecycle, remove, rename, bulk, run, image,
  volume, network, prune and Compose stack verbs.
- Shell-escape every argument and mask secret-shaped env and label values
  inside the service, so all callers inherit both. The secret pattern is
  imported from secret-reference-admission.js rather than redefined; two
  independently maintained secret regexes drift, and the one that drifts leaks.
- Add read-only POST /api/cli-preview and GET /api/cli-preview/actions,
  restricted to a fixed allowlist. The endpoint never accepts a caller-supplied
  command string.
- Show the command, collapsed and copyable, in the container-remove and stack
  bulk-action confirmations, and record it on the matching audit entries.
- Report an action with no exact equivalent as unavailable rather than guessing
  a partial command an operator might paste into a production shell.
- Add an optional onMount hook to Modal.confirm so dialog markup can attach
  listeners without inline handlers (CSP script-src-attr none).

Per-container isolation posture
- inspectContainer now returns an additive isolation block: HostConfig.Runtime,
  privileged, capabilities, namespace modes, UsernsMode, security options.
- Add src/services/isolation-posture.js (pure) enumerating how far a container
  can reach past its runtime, including Docker-socket mounts and disabled
  seccomp/AppArmor/SELinux confinement, which no existing check reported per
  container.
- Add a posture check raising one finding per container, only when it has
  host-level reach, is not already sandboxed, and the host has a sandboxed
  runtime registered. That gate is both the product decision and the cost
  guard: the per-container inspect loop never runs on hosts where it would
  find nothing actionable.
- Treat privileged / CapAdd / PidMode as inputs rather than findings so the
  check complements the CIS benchmark instead of repeating it, and cap
  severity at high so posture scoring does not double-count CIS.
- Add GET /api/containers/:id/isolation and a container-detail card, keeping
  the runtime taxonomy server-side.
- Add a shared per-scan docker info cache to the posture context.

English and Romanian labels for both. 107 new tests across 4 suites, weighted
toward shell-injection, secret redaction, the action allowlist and call-count
assertions on the isolation cost gate. Full suite: 327 suites, 3523 passing.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: bogdanpricop

CHANGELOG.md

@@ -2,6 +2,55 @@
 
 All notable changes to Docker Dash are documented here.
 
+## [8.94.0] - 2026-08-10 — CLI transparency and per-container isolation posture
+
+Two features derived from the same critique of opaque management UIs: show the
+operator what the tool actually does, and what their containers actually are.
+
+### Per-container isolation posture
+
+- Expose the per-container isolation model (`HostConfig.Runtime`, privileged,
+  capabilities, namespace modes, `UsernsMode`, security options) from
+  `inspectContainer` as an additive `isolation` block.
+- Add a pure assessment service that enumerates how far a container can reach
+  past its runtime, including Docker-socket mounts and disabled seccomp,
+  AppArmor or SELinux confinement — signals no existing check reported per
+  container.
+- Add a posture check that raises one finding per container, only when the
+  container has host-level reach, is not already sandboxed, and the host has a
+  sandboxed runtime registered; the same gate keeps the per-container inspect
+  loop off hosts where it would find nothing actionable.
+- Treat privileged, capability and namespace switches as inputs rather than
+  findings, so the check complements the CIS benchmark instead of repeating it.
+- Cap finding severity at high: the verdict is "this could be contained better",
+  not "this is breached", and posture scoring must not double-count CIS.
+- Add `GET /api/containers/:id/isolation` and a container-detail card so the
+  runtime taxonomy stays server-side and the teaching surface works on every
+  host, not only where a sandboxed runtime exists.
+- Add a shared per-scan `docker info` cache to the posture context, English and
+  Romanian labels, and 41 tests including call-count assertions on the cost gate.
+
+### CLI transparency
+
+- Add a pure derivation service that turns an action key plus typed parameters
+  into the equivalent `docker` or `docker compose` command, covering container
+  lifecycle, removal, rename, bulk, run, image, volume, network, prune and
+  Compose stack verbs.
+- Shell-escape every argument and mask secret-shaped environment and label values
+  inside the service, so all callers inherit both; a truncated secret is treated
+  as a secret and replaced outright.
+- Add read-only `POST /api/cli-preview` and `GET /api/cli-preview/actions`,
+  restricted to a fixed action allowlist; the endpoint never accepts a
+  caller-supplied command string.
+- Show the equivalent command, collapsed and copyable, in the container-remove
+  and stack bulk-action confirmations, and record it on the matching audit
+  entries.
+- Report an action with no exact equivalent as unavailable rather than guessing a
+  partial command an operator might paste into a production shell.
+- Add an optional `onMount` hook to `Modal.confirm` so dialog markup can attach
+  listeners without inline handlers, English and Romanian labels, and 66 tests
+  covering escaping, redaction and the allowlist.
+
 ## [8.93.0] - 2026-08-06 — Signed Compose blueprint catalog
 
 - Add a curated Compose catalog with owner, support level, lifecycle and

docker-compose.yml

@@ -4,8 +4,8 @@ services:
       context: .
       dockerfile: Dockerfile
       args:
-        APP_VERSION: "${APP_VERSION:-8.93.0}"
-    image: docker-dash:${APP_VERSION:-8.93.0}
+        APP_VERSION: "${APP_VERSION:-8.94.0}"
+    image: docker-dash:${APP_VERSION:-8.94.0}
     container_name: docker-dash
     restart: unless-stopped
     env_file:
@@ -56,7 +56,7 @@ services:
   dd-egress-filter:
     build:
       context: ./docker/egress-filter
-    image: docker-dash-egress-filter:${APP_VERSION:-8.93.0}
+    image: docker-dash-egress-filter:${APP_VERSION:-8.94.0}
     container_name: dd-egress-filter
     restart: unless-stopped
     # Uses the default bridge so target containers on the default bridge can

docs/features/cli-transparency.md

@@ -0,0 +1,86 @@
+# CLI Transparency — "show me the command"
+
+**Introduced:** v8.94.0
+**Always on. No configuration.**
+
+Destructive and bulk container actions show the equivalent `docker` command
+before you confirm them, and the same command is recorded on the audit entry
+afterwards.
+
+The point is not to turn Docker Dash into a CLI. It is to stop being a black box:
+a web UI that hides what it does asks you to trust it, and one that shows you the
+command earns that instead.
+
+---
+
+## 1. Where it appears
+
+| Surface | What you see |
+|---------|--------------|
+| Container **remove** confirmation | A collapsed `CLI equivalent` row with the `docker rm …` command and a copy button |
+| Stack **bulk action** confirmation | One command line per affected container |
+| Audit log | `details.cli` on container action, remove, rename and bulk entries |
+
+The row is **collapsed by default** — an operator who doesn't care pays no extra
+click. Start/stop/restart have no confirmation dialog and are unchanged; no
+confirmation was added just to hang a preview off it.
+
+## 2. What it will and won't render
+
+Commands are derived from a fixed action table, never from a free-form string:
+
+`container.start` · `stop` · `restart` · `pause` · `unpause` · `kill` · `remove` ·
+`rename` · `bulk` · `run` · `image.pull` · `image.remove` · `volume.remove` ·
+`network.remove` · `prune.*` · `stack.up` · `down` · `restart` · `pull`
+
+An action outside this table is reported as having **no equivalent**. It is never
+guessed. A subtly wrong command that an operator pastes into a production shell
+is worse than no command at all, which is also why provider CLIs (`qm`, `govc`,
+`xe`, `incus`) are deliberately out of scope for now — each has its own auth
+model and flag semantics.
+
+## 3. Safety properties
+
+- **Shell-escaped.** Every argument is single-quoted unless it consists only of
+  characters with no shell meaning. A container named `$(id)` or `a'; rm -rf /`
+  renders as one inert argument. Tested against command substitution, chaining,
+  newlines and quote break-out.
+- **Secrets masked.** Environment and label values whose key matches the shared
+  secret pattern render as `KEY=<redacted>`. The key stays visible — you need to
+  know `DB_PASSWORD` is being set. The value is replaced outright, never hashed
+  or truncated; a truncated secret is still a secret.
+  The pattern is imported from `src/services/secret-reference-admission.js` rather
+  than redefined, because two independently-maintained secret regexes drift, and
+  the one that drifts is the one that leaks.
+- **Redaction lives in the service**, not at the call sites, so every caller —
+  UI preview and audit entry alike — inherits it.
+- **No host flag.** The command is labelled *"as run on `<host>`"* instead of
+  carrying `--host`. Pasting a command that silently targets the wrong machine
+  because of your local Docker context is a failure mode worth designing out.
+
+## 4. API
+
+```
+POST /api/cli-preview          { action, params } → { available, command, hostLabel, redacted, reason }
+GET  /api/cli-preview/actions  → { actions: [...] }
+```
+
+`requireAuth` only — deriving a string changes no state, and gating it behind
+`operator` would hide the explanation from exactly the viewers who most need it.
+No `writeable`, no audit entry: nothing happened.
+
+`POST` despite being read-only because the parameters are structured (bulk
+subject arrays, full container definitions) and do not survive a query string
+intact — the same reason GraphQL queries use POST. An unknown action key returns
+`400`; a known action with unusable parameters returns `200` with
+`available: false`.
+
+## 5. Limitations
+
+- Provider CLIs are not covered (see §2).
+- There is no global "CLI mode" that annotates every page — v1 covers the two
+  confirmations where the trust question actually gets asked.
+- The reverse direction (paste a command, run it) is not part of this feature.
+  `src/services/docker-run-parser.js` converts `docker run` into a Compose
+  service for the Stacks converter; executing pasted commands is a different
+  feature with a different threat model.

docs/features/isolation-posture.md

@@ -0,0 +1,123 @@
+# Per-container Isolation Posture
+
+**Introduced:** v8.94.0
+**Always on. No configuration.**
+
+Docker Dash has detected sandboxed OCI runtimes (Kata Containers, gVisor/runsc,
+Firecracker) at the **host** level since v8.8.1, badging them on the System page.
+That answers "is a stronger runtime available here?" but not the question that
+follows: **which containers aren't using it?**
+
+This feature is the per-container half.
+
+---
+
+## 1. Two surfaces, deliberately different audiences
+
+| Surface | Who sees it | When |
+|---------|-------------|------|
+| **Container detail → Isolation card** | Everyone | Always |
+| **Security Posture finding** | Operators with a sandboxed runtime installed | Only when actionable |
+
+The card is unconditional: it shows which runtime backs the container, whether
+that runtime is sandboxed, and — if the container can reach past it — exactly how.
+That is useful whether or not you run gVisor.
+
+The posture finding is conditional, on purpose. See §3.
+
+## 2. What counts as "reach"
+
+Ways a container can reach past its runtime toward the host:
+
+| Signal | Severity |
+|--------|:--------:|
+| Privileged | critical |
+| Docker socket mounted | critical |
+| `CapAdd=ALL`, `SYS_MODULE` | critical |
+| `SYS_ADMIN`, `SYS_RAWIO` | high |
+| Host PID namespace | high |
+| `seccomp=unconfined`, `apparmor=unconfined` | high |
+| `SYS_PTRACE`, `SYS_BOOT`, `NET_ADMIN`, `DAC_READ_SEARCH` | medium |
+| Host network / IPC namespace | medium |
+| SELinux `label=disable` | medium |
+
+Capability spelling is normalised (`SYS_ADMIN`, `cap_sys_admin`, `CAP_SYS_ADMIN`
+are one signal) and de-duplicated. When a container is already privileged its
+capabilities are **not** re-listed — privileged implies all of them, and
+enumerating them again is noise.
+
+Disabled seccomp/AppArmor/SELinux confinement and Docker-socket mounts are
+reported **per container** here for the first time; the CIS benchmark checks
+seccomp and AppArmor on the daemon, not per workload.
+
+## 3. Why the posture check is usually silent
+
+A finding is raised only when all three hold:
+
+1. the container has host-level reach, **and**
+2. it is not already on a sandboxed runtime, **and**
+3. the host has a sandboxed runtime registered.
+
+Condition 3 means most estates see nothing. That is the intended behaviour.
+Without it, the remediation would read "go install gVisor and reconfigure your
+daemon" — a large ask, and one the CIS benchmark already opens by flagging the
+privileged container on its own terms. **Docker Dash does not nag you about
+software you have not installed.**
+
+The same condition is evaluated from one cached `docker info` *before* any
+container work, so on hosts without a sandboxed runtime the per-container inspect
+loop never runs. The product decision and the performance guard are the same line.
+
+Per-host scan cap: 200 running containers. When it truncates, the finding says so
+rather than silently under-reporting.
+
+## 4. Relationship to the CIS benchmark
+
+They are complementary, not overlapping:
+
+- **CIS** reports privileged / `CapAdd` / `PidMode=host` as failures in their own
+  right — *the door is open*.
+- **Isolation posture** treats those same switches as **inputs** and asks a
+  different question — *you own a lock and haven't used it*.
+
+One finding per container, never one per switch. Severity is capped at **high**
+even for critical reach, because the verdict is "this could be contained better",
+not "this is breached" — inflating it would make the posture score double-count
+what CIS already counted.
+
+## 5. Remediation is guidance, not a button
+
+The finding suggests recreating the container with `--runtime=<sandboxed>`
+(Compose: `runtime:` on the service), and warns that Kata and gVisor do not
+support every syscall or device passthrough. There is no one-click fix: moving a
+workload onto a sandboxed runtime can break it, and Docker Dash does not make
+that call for you. Same principle as the exposed-port check, which refuses to
+close ports on your behalf.
+
+If the workload must stay on the shared kernel, the alternative remediation is to
+reduce the reach — drop capabilities, remove the privileged flag or the socket
+mount.
+
+## 6. API
+
+```
+GET /api/containers/:id/isolation
+→ { runtime, sandboxed, sandboxAvailable, sandboxOptions, signals, severity, actionable }
+```
+
+`requireAuth`, read-only. This endpoint exists so the runtime taxonomy (which
+names count as sandboxed) stays in one place — `_categorizeRuntimes` in
+`src/services/docker.js` — instead of being duplicated in the frontend.
+
+## 7. Limitations
+
+- **Docker and Podman only.** Kubernetes, Nomad and Incus have their own
+  isolation models (RuntimeClass, task drivers); mapping them onto Docker's
+  `HostConfig.Runtime` would be a guess.
+- **Running containers only.** A stopped container has no reach.
+- **User-namespace remapping is shown but not scored.** `userns-remap` is off by
+  default nearly everywhere, and a signal that fires on almost every container is
+  not a signal.
+- **`youki` is classified as sandboxed** by the pre-existing host-level runtime
+  patterns, which is arguable — it is a standard OCI runtime written in Rust. Left
+  unchanged because that classification also drives the System page badge.

package-lock.json

@@ -1,6 +1,6 @@
 {
   "name": "docker-dash",
-  "version": "8.93.0",
+  "version": "8.94.0",
   "description": "Full-featured Docker management dashboard",
   "main": "src/server.js",
   "scripts": {

package.json

@@ -391,6 +391,7 @@
   <script src="/js/components/error-boundary.js?v=__VERSION__"></script>
   <script src="/js/components/toast.js?v=__VERSION__"></script>
   <script src="/js/components/modal.js?v=__VERSION__"></script>
+  <script src="/js/components/cli-preview.js?v=__VERSION__"></script>
   <script src="/js/components/template-configurator.js?v=__VERSION__"></script>
   <script src="/js/components/table.js?v=__VERSION__"></script>
   <script src="/js/components/context-menu.js?v=__VERSION__"></script>

public/index.html

@@ -145,6 +145,12 @@ const Api = {
   sendPasswordReset(id, lang) { return this.post(`/auth/users/${id}/send-reset`, { lang, origin: window.location.origin }); },
   sendInvitation(id, lang) { return this.post(`/auth/users/${id}/send-invite`, { lang, origin: window.location.origin }); },
 
+  // ─── CLI Transparency ────────────────────────────
+  // Read-only: derives the equivalent docker command for an action. POST because
+  // the params are structured, not because anything changes. v8.94.0.
+  getCliPreview(action, params = {}) { return this.post('/cli-preview', { action, params }); },
+  getCliPreviewActions() { return this.get('/cli-preview/actions'); },
+
   // ─── Containers ──────────────────────────────────
   getContainers(all = true) { return this.get(`/containers?all=${all}`); },
   getContainer(id) { return this.get(`/containers/${id}/inspect`); },
@@ -164,6 +170,7 @@ const Api = {
     return this.get(`/containers/logs/multi?${params.toString()}`);
   },
   getContainerStats(id) { return this.get(`/containers/${id}/stats`); },
+  getContainerIsolation(id) { return this.get(`/containers/${id}/isolation`); },
   containerAction(id, action) { return this.post(`/containers/${id}/${action}`); },
   removeContainer(id, force = false) { return this.delete(`/containers/${id}?force=${force}`); },
   renameContainer(id, name) { return this.post(`/containers/${id}/rename`, { name }); },