Skip to content

Security & supply chain

A panel that controls your host should earn it

Two separate questions: can you trust the binary you downloaded, and can you trust it once it is running. Both have concrete answers — but neither changes what mounting the Docker socket grants, which is a deployment decision rather than an application one.

Verify what you downloaded

Every release ships checksums, a keyless cosign signature bundle covering the binaries and an SPDX SBOM, plus per-binary build provenance. The container image is signed and carries SLSA provenance as well. Three commands prove the artifact came from the release workflow in this repository and nowhere else.

  1. 01

    Checksums

    Every release ships SHA256SUMS covering the binaries and the SPDX SBOM.

  2. 02

    Keyless signature

    A cosign bundle signs those checksums, tied to the release workflow identity. Needs cosign v3+.

  3. 03

    Build provenance

    Each binary and the container image carry SLSA provenance attestations.

verify a release — copy all three
# 1. Checksums
sha256sum -c SHA256SUMS --ignore-missing

# 2. Keyless signature
cosign verify-blob --bundle SHA256SUMS.bundle \
  --certificate-identity-regexp '^https://github\.com/koduj-dev/docker-commander/\.github/workflows/release\.yml@refs/tags/v' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com SHA256SUMS

# 3. Build provenance
gh attestation verify dockercmd-linux-amd64 --repo koduj-dev/docker-commander

And once it is running

Authentication

  • Argon2id password hashing
  • TOTP 2FA or passkeys (WebAuthn), several per account
  • Passwordless sign-in with a verified passkey, off until you opt in
  • Signed HttpOnly cookies, rate limiting, strict headers
  • Optional LDAP / Active Directory with group → role mapping

Authorization

  • Named RBAC roles, scoped to specific hosts
  • Read-only accounts and global feature flags
  • An audit log of who did what, where
  • MCP tokens can only narrow an account’s sections, hosts and rights

Secrets at rest

  • Registry, SMTP and LDAP credentials and project secrets encrypted with AES-256-GCM
  • Host TLS private keys encrypted too
  • Keys generated on first run, kept in the data dir
  • Stored secrets are never returned by the API

Transport

  • Binds 127.0.0.1 by default — exposure is a deliberate act
  • Automatic Let’s Encrypt HTTPS, your own certificate, or a --make-certs self-signed one
  • SSH daemon host keys verified (known_hosts / trust-on-first-use)
  • A changed SSH host key is refused as a possible MITM
Report a vulnerability privatelyVerifying the bundle needs cosign v3+; releases up to v1.5.0 use the older signature pair.

Try it on one host tonight

It is one binary and a named volume. If you do not like it, delete both — nothing on your Docker hosts was changed to accommodate it.

Docker Commander v1.7.2 — Docker, hardened
docker run -d --name dockercmd \
  -p 127.0.0.1:8470:8470 \
  --group-add "$(stat -c '%g' /var/run/docker.sock)" \
  --read-only --tmpfs /tmp \
  --security-opt no-new-privileges \
  --cap-drop ALL \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v dockercmd-data:/data \
  ghcr.io/koduj-dev/docker-commander:latest

Read-only root filesystem, no added capabilities, no privilege escalation, bound to localhost. On rootless Docker or Docker Desktop, drop the --group-add line.

Show the minimal command
Docker — minimal
docker run -d --name dockercmd -p 127.0.0.1:8470:8470 \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v dockercmd-data:/data \
  ghcr.io/koduj-dev/docker-commander:latest

Fewer flags, and correspondingly fewer guardrails. Fine for a throwaway look on a machine you do not mind losing; the hardened form above is what belongs on anything you keep.

Download v1.7.2Star on GitHub

MIT licensed · no account · no telemetry · Linux, macOS and Windows