docs: fix the CSRF-exempt list and describe how secret_env actually reaches a container
**COMMANDS.md** named six CSRF-exempt read-only methods, two of which
(`bitcoin.getinfo`, `monitoring.current`) are not exempt — a client trusting the
doc would send them with the cookie alone and get rejected. The real set is
twelve (`api/rpc/mod.rs:326-340`); listed all of them and said plainly that
everything else needs the header. The rest of the doc verified clean: the 480 /
200 / 160-char caps, the four `assistant_*` config keys, both default model ids,
`is_sender_allowed`, `strip_archy_trigger` / `run_node_cmd`, the three
unauthenticated HTTP endpoints, and `auth.login.totp` all match the code.
**secrets.md** said `secret_env` "sets `<key>` in the container's environment",
which reads as a plain `-e KEY=value` and undersells the design. It isn't:
resolved pairs are registered as podman secrets named
`archy-env-<app-id>-<key>` and referenced by name, precisely so the value stays
out of `podman inspect` and out of plaintext `Environment=` lines in Quadlet
units. Also documented the interpolation-taint rule — a plain `environment`
entry that expands `${SECRET}` (BTCPay's connection strings) is itself treated
as secret-bearing rather than left in the clear, which is what makes it safe to
build connection strings from secrets.
Everything else in secrets.md verified against `container/secrets.rs`: the four
kinds and their file shapes, the bare-filename rule, the every-tick idempotent
`ensure_generated_secrets`, and the atomic 0600 temp-fsync-rename writer.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
co-authored by
Claude Opus 5
parent
7adc3260a6
commit
2c53a7d77f
+12
-2
@@ -60,8 +60,18 @@ container:
|
||||
```
|
||||
|
||||
At apply time the orchestrator reads `/var/lib/archipelago/secrets/<secret_file>`
|
||||
and sets `<key>` in the container's environment to its contents. The value is
|
||||
never written into the manifest, the Quadlet unit, or any log line.
|
||||
and makes it available in the container as `<key>`. It does **not** do this by
|
||||
adding `KEY=value` to the environment — that value would show up in
|
||||
`podman inspect` output and, on the Quadlet path, as a plaintext `Environment=`
|
||||
line in a unit file on disk. Instead the resolved pairs are registered as podman
|
||||
secrets named `archy-env-<app-id>-<key>` and referenced by name, so the value
|
||||
never lands in the manifest, a unit file, `podman inspect`, or a log line.
|
||||
|
||||
**Interpolation taints.** A plain `environment` entry that interpolates a secret
|
||||
— e.g. BTCPay's `ConnectionString=...Password=${BTCPAY_DB_PASS}` — is treated as
|
||||
secret-bearing itself and travels the same protected path, rather than being
|
||||
left in the clear because it was declared under `environment`. So you can build
|
||||
connection strings from secrets without leaking them.
|
||||
|
||||
## How materialisation works
|
||||
|
||||
|
||||
Reference in New Issue
Block a user