Skip to content

Known gaps of the Compose bundle

What the bundle does not do, or does not protect, today, and why. The steps to run the bundle are in Deploying with Compose.

  • A venv build is not interrupted by a shutdown (#48). docker stop (and Compose restarts/down) sends SIGTERM: the worker stops claiming and lets a running task finish for up to 20 s (LAKANA_RUN__DRAIN_GRACE_SECONDS) before releasing it to another worker; the bundle sets stop_grace_period: 45s. A task whose venv is still being built is not stopped by that. If Compose sends SIGKILL first, or the worker is lost, the platform ends what it held after about a minute: queries and deploys FAILED with the cause worker_lost (a write that had already committed ends SUCCEEDED), tasks released or reclaimed. Nothing stays RUNNING for ever; see A worker that is lost and When a worker is lost.
  • SeaweedFS's internal HTTP APIs are closed to the worker (#14); what is and is not protected. SeaweedFS's master (9333), volume server (8080) and filer have HTTP APIs that need no credentials. They run in seaweedfs-core, on the seaweed-internal network, which only SeaweedFS's own containers (seaweedfs-core, the seaweedfs S3 gateway and the one-shot bucket) join and which has no route out of the host. The server and every worker are not on it: from a worker, seaweedfs-core does not resolve, and seaweedfs answers over HTTP on port 8333 only, with S3 that needs the keys. The filer also runs with -disableHttp. Not protected: the gateway's gRPC port; see The gRPC port of the SeaweedFS gateway. The isolation relies on Docker's own network isolation (the default); iptables: false, Podman or rootless setups may not provide it. A person with Docker access to the host can still reach SeaweedFS (docker exec), and the S3 keys in .env give full access to the lakana bucket, as always. The pinned SeaweedFS version is updated with Lakana releases.

The gRPC port of the SeaweedFS gateway

The seaweedfs S3 gateway also listens on a gRPC port, 18333. SeaweedFS cannot turn it off, and it has no authentication. It is reachable from the worker, because the gateway is on the network the worker uses. User SQL cannot use it (DuckDB's HTTP filesystem cannot speak gRPC), but a Python task runs as trusted code in the worker and could remove the storage identity, which makes storage unavailable until the gateway restarts. See the SeaweedFS item above for what else is and is not protected.

A symlinked parent directory of the profile file

The CLI and the SDK read a profile file (it holds your token) through a single O_NOFOLLOW open and refuse a file that anyone but you can read. A symlink as the file itself is therefore refused. A symlink in a parent directory of the file is a known limitation that the check does not close. Keep the profile directory (by default ~/.config/lakana) a real directory that only you can write to.