Files
sencho/docs/features/resources.mdx
T
Anso 2a4955f56d feat: add dedicated Security page and policy-pack foundation (#1362)
* feat: add dedicated Security page and policy-pack foundation

Bring vulnerability scanning, scan history, suppressions, Compose risks,
secrets, policy packs, and scanner setup into one node-scoped Security
command center instead of scattering them across Resources and Settings.

- New top-level Security view with Overview, Images, Compose risks,
  Secrets, Policies, Suppressions, History, and Scanner setup tabs
  (status masthead + signal rail; controlled tabs with deep-link support).
- Backend: GET /security/overview rollup and GET /security/policy-packs
  static catalog (auth-only, Community). DatabaseService gains an uncapped
  scan-status count and a node-eligible block-policy count, and
  getImageScanSummaries now projects secret and misconfig counts.
- Reuse existing surfaces: the scan-history sheet, the control-governed
  suppression and acknowledgement panels, and the scan-detail sheet (now
  with an initial-tab prop so it opens on the matching finding type).
- Extract a shared SeverityBadge (from Resources) and a TrivyManager
  (from Settings) so both surfaces render identical controls.
- Resources "Scan history" now links into the Security page History tab.
- Docs for the new Security surface and tests for the new endpoints,
  helpers, nav wiring, and tabs.

* refactor: consolidate scanner and policy management onto the Security page

Remove the Settings "Vulnerability Scanning" section now that the Security
page covers the same ground, with every option preserved:

- Scanner install / update / uninstall / auto-update live on the Scanner setup
  tab (TrivyManager).
- Scan policies, the honor-suppressions toggle, and the replica
  managed-by-control / demote controls move into a new ScanPolicyManager on the
  Policies tab (paid; Community sees only the policy-pack catalog).
- CVE suppressions and acknowledgements remain on the Suppressions tab.

Wiring removed: the registry section and the now-empty Security settings group,
the SectionId, the SettingsSectionContent case and the isPaid prop it was the
sole consumer of, and SecuritySection itself. The dashboard configuration-status
"Vulnerability scanning" row now navigates to the Security page Policies tab.

Docs that pointed at "Settings -> Security -> Vulnerability Scanning" are swept
to the relevant Security page tabs.

* fix: harden Security page scanner refresh, policy-load errors, and secret-only badges

Address independent-review findings on the Security page:

- Scanner setup now refreshes Trivy state when the active node changes, so the
  displayed scanner status matches the node TrivyManager's actions target (both
  follow x-node-id). Previously, switching nodes on the tab left stale state.
- ScanPolicyManager surfaces an explicit error state on a failed policy fetch
  instead of falling through to a false "No scan policies configured".
- The shared SeverityBadge and the Images findings column no longer label a scan
  "clean" when it has secrets or misconfigurations but no CVE severity
  (highest_severity is derived from vulnerabilities only); they show a "Findings"
  state and the secret/misconfig counts instead.
- The Overview enforcement note points to the Policies tab, not the removed
  Settings section.
- The History tab auto-opens the scan-history sheet only on a deep-link (mount
  with the History tab active), not on every manual tab selection.

Adds tests for the badge secret/misconfig state and the policy-load error state.
2026-06-12 10:41:39 -04:00

230 lines
14 KiB
Plaintext
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
---
title: Resources Hub
description: Browse, filter, scan, and clean up Docker images, volumes, networks, and unmanaged containers from a single view.
---
The **Resources** tab shows everything Docker is storing on your host, broken down by ownership, with one-click cleanup, on-demand vulnerability scanning, and a topology view of how your containers connect.
<Frame>
<img src="/images/resources/resources-reclaim.png" alt="Resources Hub with the You can reclaim banner, Docker Disk Footprint treemap, Quick Clean panel, and the Images tab populated below" />
</Frame>
## Reclaim hero
When there is reclaimable disk space (unused images, stopped containers, or dangling volumes), an amber banner leads the view with the total amount you can free and a `·`-separated breakdown of what contributes to it (for example, `16 unused images · 10 dangling volumes`). Click **Review & prune** to open a single confirmation dialog scoped to every reclaimable resource at once.
The hero stays hidden when there is nothing to reclaim, keeping the view focused on the rest of your inventory.
To set the banner aside without pruning, use the **×** in its top-right corner. It stays hidden on that browser until the reclaimable total grows past the amount it held when you dismissed it, so a small, stubborn remainder will not keep reappearing while a genuine new build-up still surfaces.
To keep the banner off for a node entirely, open **Settings → Monitoring → Docker & Storage** and switch off **Show reclaimable-space banner**. It is on by default and applies per node.
<Note>
The banner and the **Review & prune** action are admin-only. Read-only roles still see the rest of the page but cannot trigger destructive operations.
</Note>
## Docker Disk Footprint
The left card under the hero shows how your Docker disk usage is distributed:
| Segment | Meaning |
|---------|---------|
| **Sencho managed** (green) | Images and volumes used by stacks in your `COMPOSE_DIR` |
| **External** (amber) | Images and volumes used by Docker projects outside Sencho |
| **Reclaimable** (neutral) | Unused images, stopped containers, and dangling volumes safe to delete |
Each segment shows its size and its share of the total footprint. Tile area is proportional to bytes. Click any segment to filter the resource tabs below to that category.
## Quick Clean
The right card under the hero exposes four prune actions. Each tile has a single primary button that targets **Sencho-managed resources only**, so by default the action will not touch external Docker projects.
| Action | What it removes |
|--------|----------------|
| **Prune Unused Images** | Images with no running containers in Sencho stacks |
| **Prune Unused Volumes** | Volumes not attached to any Sencho container |
| **Prune Dead Networks** | Networks not connected to any Sencho container |
| **Purge Unmanaged Containers** | Containers Sencho doesn't recognize (started outside it) |
The first three tiles also show a **More options** menu with a single destructive entry, **All Docker (includes external)**, that broadens the prune to every Docker resource on the host. Use it carefully, since it can affect other Compose projects sharing the same daemon. The **Purge Unmanaged Containers** tile has no menu and always targets unmanaged containers only.
A confirmation dialog appears before any destructive operation, with a summary of what will be removed. While the operation runs, a loading notification keeps you informed; on completion it is replaced with a success or error notification, including how much space was reclaimed.
<Note>
Quick Clean is admin-only. The panel is hidden for users without admin permissions.
</Note>
## Resource tabs
Below the hero, four tabs partition your inventory: **images**, **volumes**, **networks**, and **Unmanaged**. The Unmanaged tab shows a count badge whenever orphan containers are detected.
A **Scan history** button sits on the right of the tab strip when image vulnerability scanning is configured for the node. It takes you to the [Security page](/features/security) History tab so you can review past results without launching a new scan. See [Vulnerability scanning](/features/vulnerability-scanning) for the full workflow.
<Note>
Sencho protects its own image, network, and named volumes from accidental deletion. The matching rows carry a **Sencho** pill alongside the managed status and the delete control is disabled.
</Note>
### Images
Lists all Docker images on the host with their ID, repository tag, size, and status.
**Filter chips:** `All`, `Managed`, `External`. Each chip shows the matching count, for example `All 31 · Managed 14 · External 17`.
**Status column** combines two pieces of information per row:
- A usage badge: `In Use` plus the stack name when the image runs in a Sencho-managed stack, `In Use` plus `External` when it runs in another Docker project, or `Unused` when no container references it.
- A severity badge from any image scan: `Clean`, `LOW`, `MEDIUM`, `HIGH`, `CRITICAL`, or `UNKNOWN`. Click the badge to open the scan results.
**Per-row actions** sit on the right:
- **Inspect** (eye) opens the image detail sheet.
- **Scan** (shield) opens a menu with `Scan (vulnerabilities)` and `Full scan (vulnerabilities + secrets)`. The full scan is a paid-tier option.
- **Delete** (trash, admin-only) removes the image. Sencho warns before deleting an image that is still in use.
#### Inspect image
Click the eye icon on any image row to open a detail sheet with three sections:
- **Overview** lists the ID, size, creation date, architecture and OS, author, and all repository tags.
- **Config** shows the default `Cmd`, `Entrypoint`, `WorkingDir`, `User`, exposed ports, environment variables, and labels. Env vars and labels are collapsible.
- **Layers** lists the layer history in build order. Each row shows the layer index, size, age, and the build command (`CreatedBy`). Empty layers (metadata-only, zero bytes) are dimmed.
The inspect sheet is read-only and available to all roles.
### Volumes
<Frame>
<img src="/images/resources/resources-volumes-tab.png" alt="Volumes tab with Largest 5 and Recently changed landing cards above the volume list" />
</Frame>
Lists all Docker volumes with name, driver, mount point, and managed status.
A two-card landing strip sits above the table:
- **Largest 5** ranks volumes by on-disk size, with the total volume count alongside.
- **Recently changed** highlights volumes created or touched in the last 24 hours, with relative timestamps such as `24m ago`.
**Filter chips:** `All`, `Managed`, `External`, each with its count.
<Warning>
Deleting a volume is permanent. Any data stored in it will be lost. Always back up important volume data before pruning.
</Warning>
#### Browse volume contents
Click the folder icon on any volume row (admin-only) to open a read-only browser for that volume. The panel shows a directory tree on the left and a file viewer on the right.
- **Read only.** No edits, no writes, no deletions. The browser launches a short-lived helper container with the volume mounted read-only.
- **Size cap.** Files are read up to 5 MB. Larger files show a truncation banner.
- **Binary files** are displayed as a hex view. Plain text is shown directly.
- **Symlinks** are listed but never followed. Reading a symlink path returns an error.
- **Audit log.** Every file read is recorded in the audit log, including failed reads, with the volume and path. Use this for compliance and incident review.
<Warning>
Volumes commonly contain database files, password hashes, certificates, and other secrets. Treat the volume browser as a high-power admin tool.
</Warning>
### Networks
<Frame>
<img src="/images/networks/networks-list.png" alt="Networks tab in List view with filter chips, view-mode toggle, Create Network button, and the network table" />
</Frame>
Lists all Docker networks with ID, name, driver, scope (`local`, `global`, `swarm`), and managed status. System networks (`bridge`, `host`, `none`) are shown but cannot be deleted.
**Filter chips:** `All`, `Managed`, `External`, each with its count.
A **List | Topology** view-mode toggle sits on the right of the toolbar. **List** is the default tabular view; **Topology** is a graph view of how containers connect to networks (covered below).
#### Create Network
In **List** view, the **+ Create Network** button (admin-only) opens the creation dialog.
<Frame>
<img src="/images/networks/create-network.png" alt="Create network dialog with Name, Driver, Subnet, Gateway fields, and Internal and Attachable toggles" />
</Frame>
| Field | Required | Description |
|-------|----------|-------------|
| **Name** | Yes | Alphanumeric, hyphens, underscores, and dots |
| **Driver** | No | `bridge` (default), `overlay`, `macvlan`, `host`, or `none` |
| **Subnet** | No | CIDR notation, for example `172.20.0.0/16` |
| **Gateway** | No | Gateway IP, for example `172.20.0.1` |
| **Internal** | No | Isolates the network from external access |
| **Attachable** | No | Allows containers to be manually attached |
The footer shows a **DRIVER** chip that mirrors the selected driver, and a **Create network** button that stays disabled until the form is valid.
#### Inspect network
Click the eye icon on any network row to open a detail sheet.
<Frame>
<img src="/images/networks/network-inspect.png" alt="Network inspect sheet for arr-net showing the Overview, IPAM configuration, and Connected containers sections" />
</Frame>
The sheet is grouped into sections:
- **Overview** lists the ID, driver, scope, creation date, and the internal/attachable flags.
- **IPAM configuration** shows the subnet, gateway, and IP range for each configured address pool.
- **Options** lists driver-specific options applied to the network (rendered only when present).
- **Connected** shows every container attached to the network, with its name, IPv4 address, and MAC address. The section header counts the containers.
- **Labels** lists all Docker labels on the network (rendered only when present).
#### Network topology
Switch to the **Topology** view to see an interactive graph of your Docker networks and the containers attached to them. The graph uses an automatic hierarchical layout (networks on top, containers below) that scales cleanly regardless of how many networks and containers you have.
<Frame>
<img src="/images/networks/network-topology.png" alt="Network topology graph with arr-net at top and the connected containers fanned out below it, mini-map and zoom controls visible" />
</Frame>
- **Network nodes** are dashed-border cards showing the network name and driver, color-coded by status (managed, external, system).
- **Container nodes** are cards showing the container name, a state indicator, the stack badge, the image name, and the IPv4 address per network.
- **Edges** are animated, color-coded connections between networks and their containers.
- **Click-to-logs.** Click any running container node to open its log viewer directly.
- **Refresh.** Use the refresh button in the toolbar to re-fetch the topology on demand.
- Pan, zoom, and drag nodes to explore the graph.
- A **mini-map** in the bottom-right gives an overview of the full graph. Zoom and fit-view controls sit on the bottom-left.
##### Show system networks
By default, system networks (`bridge`, `host`, `none`) are hidden so the graph stays focused on user networks. Toggle **Show system networks** to include them, which is useful for debugging containers attached to the default bridge.
<Frame>
<img src="/images/networks/network-topology-toggle.png" alt="Topology with Show system networks toggled on; arr-net plus the bridge, none, and host system networks all visible at the top" />
</Frame>
### Unmanaged
<Frame>
<img src="/images/resources/resources-unmanaged-tab.png" alt="Unmanaged tab with Select all checkbox, Purge Selected action, and a container row grouped under External Project: sencho" />
</Frame>
Lists containers running on the host that are not part of any Sencho-managed stack: containers started with `docker run`, or Compose projects outside your `COMPOSE_DIR`. The tab shows a count badge when any are detected. The running Sencho container itself is excluded from this list so it cannot be purged by accident.
Containers are grouped by their external Compose project. Each group has an **External Project** header with the project name and a container count. Each container row shows:
- A row checkbox for multi-selection.
- The container name (or short ID if unnamed).
- A state pill, for example `running`.
- The image reference, in monospace below the name.
The toolbar above the list provides a **Select all** checkbox and a destructive **Purge Selected (N)** button. The button stays disabled until at least one row is checked, and is admin-only.
When no unmanaged containers are detected, the tab shows a success state with the message "No unmanaged containers" and the subline "All running containers are managed by Sencho."
## Troubleshooting
<AccordionGroup>
<Accordion title="The delete button is greyed out on an image, network, or volume row">
The row carries a **Sencho** pill, which means the resource is the running Sencho instance's own image, attached network, or named volume. Sencho refuses to delete the resources that keep itself running so an admin cannot take the dashboard offline by accident. Bind-mounted host paths are not shown in the Volumes tab and are not affected.
</Accordion>
<Accordion title="I expected to see the Sencho container in the Unmanaged tab and it is not there">
The Unmanaged tab filters the running Sencho container out by design so it cannot be selected and purged. Other containers started outside Sencho (with `docker run` or by a Compose project outside `COMPOSE_DIR`) still appear normally. To inspect the Sencho container itself, use **Host Console** or `docker ps` on the host.
</Accordion>
<Accordion title="The reclaim banner will not go away, or shows a small amount that will not prune">
The banner mirrors what Docker reports as reclaimable on the node, and it counts only the resources a standard prune can actually remove. After a prune, some storage drivers still report a few megabytes as reclaimable that the prune does not free. To stop the banner drawing attention to a stubborn remainder, dismiss it with the **×** in its top-right corner; it stays hidden until the reclaimable total grows past that point. To turn it off for the node entirely, switch off **Show reclaimable-space banner** in **Settings → Monitoring → Docker & Storage**.
</Accordion>
</AccordionGroup>