Add a container image for the server

Why: the server is a single static binary with no dependencies, so its
container should be nothing but that binary. Shipping one also makes the
master key easy to lose, which needed handling rather than documenting.

What:
- Dockerfile: two stages, runtime is scratch plus the binary and a CA bundle
  for reaching an OIDC provider, running as uid 65532. About 9 MB. The build
  stage copies only go.mod, cmd/keeporgd and internal, so client or docs
  changes do not invalidate it.
- The image has no shell, so HEALTHCHECK runs `keeporgd -healthcheck`, a new
  flag that probes /healthz on the configured address and exits non-zero
  with a reason. podman needs --format docker to keep the healthcheck at
  all, which the Makefile passes when it picks podman.
- New -master-key-file flag, so a mounted secret works without a config file.
- The server now checks at startup whether the master key still opens the
  stored vault keys, and says so. Without it, a container restarted without
  its key discovers the problem one failed merge at a time.
- make docker, docker-run and docker-save; a compose example with read_only,
  cap_drop ALL and no-new-privileges.
- The client and the server now version independently, so their Debian
  changelogs are split per package and `make changelog` takes PKG=.
  Server 0.3.0; the clients stay at 0.2.0.

Proved: built with podman and run. The container serves /healthz and /web,
its own healthcheck reports healthy, and a vault created through it was
edited from the same base by keepassxc-cli twice, merged by the server into
version 3, and read back with both entries intact. Restarted without the
master key it warns "1 of 1 stored vault keys do not open with this master
key" and answers a merging push with 409 merge_failed, leaving the vault
untouched; restored, it logs "1 vault keys available for merging" and merges
again. The same key supplied through -master-key-file from a mounted file
works identically. Both .deb packages build with their own changelog, and
make check is clean.
This commit is contained in:
2026-10-30 09:17:12 +01:00
parent a9308a3e89
commit dacfe20494
13 changed files with 377 additions and 15 deletions
+40
View File
@@ -0,0 +1,40 @@
keeporgd (0.3.0) unstable; urgency=medium
* Container image: a scratch-based image of about 9 MB holding the static
binary and a CA bundle, running as an unprivileged user. It has no
shell, so HEALTHCHECK runs the binary's own -healthcheck probe.
* New -master-key-file flag, so a mounted secret can be used without a
configuration file.
* At startup the server now reports whether the master key still opens the
stored vault keys. A container restarted without its key would otherwise
discover this one failed merge at a time.
-- tiredsysadmin <rcmd@garage.rcmd.space> Fri, 30 Oct 2026 09:15:50 +0100
keeporgd (0.2.0) unstable; urgency=medium
* Server-side merging. A vault the server can open has its two concurrent
saves folded together in memory, by KeePass's own synchronization rules,
instead of one being refused. The losing version of an edited entry is
kept in that entry's history.
* New vault creation: a web interface at /web, and `keeporg vault -create`,
both of which build the KDBX file and set its password.
* Vault keys are stored encrypted under a master key in
/etc/keeporg/master.key, created on first start. Back it up separately
from /var/lib/keeporg.
* The KDBX 4 codec, its merge engine, and the ChaCha20, BLAKE2b and Argon2
it needs are part of the package; they carry no new dependencies.
-- tiredsysadmin <rcmd@garage.rcmd.space> Thu, 29 Oct 2026 17:28:45 +0100
keeporgd (0.1.0) unstable; urgency=medium
* First release.
* keeporgd: synchronization server with nested group access control,
invite-link and OIDC registration, built-in TOTP second factor,
versioned KDBX blobs and server-sent update notifications.
* keeporg: desktop client that mirrors assigned databases as ordinary
.kdbx files, pushes every save and applies remote changes, with
server-wins, client-wins and manual merge strategies.
-- tiredsysadmin <rcmd@garage.rcmd.space> Thu, 29 Oct 2026 12:00:00 +0000
+51
View File
@@ -0,0 +1,51 @@
# A deployment of the KeepOrg server, showing the two things that are easy
# to get wrong: where the master key comes from, and that it does not live
# in the data volume.
#
# podman-compose up -d (or docker compose up -d)
#
# Generate the master key once, and keep a copy somewhere safe:
# head -c 32 /dev/urandom | base64 > master.key
#
# Without it the server still runs and still synchronizes; it only refuses
# to create or merge vaults.
services:
keeporgd:
# Override with KEEPORG_VERSION; `make docker` tags the version from
# versions.mk and :latest.
image: keeporgd:${KEEPORG_VERSION:-0.3.0}
build:
context: ../..
args:
VERSION: "${KEEPORG_VERSION:-0.3.0}"
restart: unless-stopped
# Terminate TLS in front of this, and set external_url to the address a
# browser sees: invite links, device approval and the OIDC redirect are
# built from it.
command:
- "-addr=:8765"
- "-data=/var/lib/keeporg"
- "-url=https://keeporg.example.com"
ports:
- "127.0.0.1:8765:8765"
environment:
# Preferred: the key never touches a disk the container can write.
# Read it from your secret store and pass it in.
KEEPORG_MASTER_KEY: "${KEEPORG_MASTER_KEY:?set KEEPORG_MASTER_KEY, see the comment above}"
# Only read on the very first start, when no accounts exist yet.
KEEPORG_ADMIN_PASSWORD: "${KEEPORG_ADMIN_PASSWORD:-}"
volumes:
- keeporg-data:/var/lib/keeporg
# Only needed instead of KEEPORG_MASTER_KEY above, or to mount a
# server.json. Keep it on different storage from keeporg-data.
# - keeporg-config:/etc/keeporg
# The server writes one directory and needs no privileges at all.
read_only: true
cap_drop: ["ALL"]
security_opt: ["no-new-privileges:true"]
user: "65532:65532"
volumes:
keeporg-data:
# keeporg-config: