docker-compose.yml sets ALLOWED_ADMIN_HOSTS but no code reads it #12

New issue

Closed

opened 2026-08-03 09:59:09 +00:00 by james.oates · 2 comments

james.oates commented

2026-08-03 09:59:09 +00:00

Owner

While cleaning up the dead ALLOWED_ADMIN_IPS env var in docker-compose.yml (Task 14 of the network-access-control plan), I noticed ALLOWED_ADMIN_HOSTS in the same environment: block also has no consumer:

grep -rn "ALLOWED_ADMIN_HOSTS" src/
# (no matches)

routes_config.rs has a comment confirming this is intentional-ish: "Note: allowed_admin_hosts is intentionally absent — admin host is set via [admin] block" — so the admin host is configured through the TOML [admin] block instead, and this env var line in docker-compose.yml is stale, same class of issue as the ALLOWED_ADMIN_IPS line that was just removed.

Out of scope for Task 14 (which only covered ALLOWED_ADMIN_IPS from the allowed_ips → access_rules migration), so logging rather than fixing inline. Likely fix: remove the ALLOWED_ADMIN_HOSTS=... line from docker-compose.yml's environment: block, same as was just done for ALLOWED_ADMIN_IPS.

While cleaning up the dead `ALLOWED_ADMIN_IPS` env var in `docker-compose.yml` (Task 14 of the network-access-control plan), I noticed `ALLOWED_ADMIN_HOSTS` in the same `environment:` block also has no consumer: ``` grep -rn "ALLOWED_ADMIN_HOSTS" src/ # (no matches) ``` `routes_config.rs` has a comment confirming this is intentional-ish: "Note: allowed_admin_hosts is intentionally absent — admin host is set via [admin] block" — so the admin host is configured through the TOML `[admin]` block instead, and this env var line in `docker-compose.yml` is stale, same class of issue as the `ALLOWED_ADMIN_IPS` line that was just removed. Out of scope for Task 14 (which only covered `ALLOWED_ADMIN_IPS` from the `allowed_ips` → `access_rules` migration), so logging rather than fixing inline. Likely fix: remove the `ALLOWED_ADMIN_HOSTS=...` line from `docker-compose.yml`'s `environment:` block, same as was just done for `ALLOWED_ADMIN_IPS`.

james.oates commented

2026-10-26 13:36:55 +00:00

Author

Owner

Still live on d3d7d1f. No code reads ALLOWED_ADMIN_HOSTS anywhere in src/, and it is still set in three shipped places:

docker-compose.yml:52 — ALLOWED_ADMIN_HOSTS=localhost,host.docker.internal (and again, commented, at :84)
.env.example:10
makefile:3 and :12

Worse than cosmetic now, because of how the admin gate actually behaves: middleware.rs only applies the host/IP check when [[admin]] has entries, so with no [[admin]] block the admin API is reachable from any host with only API-key auth. An operator reading the shipped compose file reasonably concludes admin access is restricted to localhost. It is not restricted at all, and the variable that appears to do it is inert.

So this should be fixed by deleting the variable from all three files, not by wiring it up — [[admin]] with allow_ips is the real control and a second mechanism would just be another thing to drift. The compose file should carry a commented [[admin]] example pointing at the TOML instead.

Related: the empty-[[admin]]-is-open asymmetry is the one place ER inverts its own secure-by-default rule and has no issue of its own.

Still live on `d3d7d1f`. No code reads `ALLOWED_ADMIN_HOSTS` anywhere in `src/`, and it is still set in three shipped places: - `docker-compose.yml:52` — `ALLOWED_ADMIN_HOSTS=localhost,host.docker.internal` (and again, commented, at :84) - `.env.example:10` - `makefile:3` and `:12` Worse than cosmetic now, because of how the admin gate actually behaves: `middleware.rs` only applies the host/IP check when `[[admin]]` has entries, so with no `[[admin]]` block the admin API is reachable from any host with only API-key auth. An operator reading the shipped compose file reasonably concludes admin access is restricted to localhost. It is not restricted at all, and the variable that appears to do it is inert. So this should be fixed by **deleting** the variable from all three files, not by wiring it up — `[[admin]]` with `allow_ips` is the real control and a second mechanism would just be another thing to drift. The compose file should carry a commented `[[admin]]` example pointing at the TOML instead. Related: the empty-`[[admin]]`-is-open asymmetry is the one place ER inverts its own secure-by-default rule and has no issue of its own.

james.oates referenced this issue

2026-10-26 13:37:27 +00:00

An empty [[admin]] list leaves the admin API open — the one place ER inverts secure-by-default #54

james.oates referenced this issue from a commit

2026-10-26 14:24:42 +00:00

fix!: refuse ALLOWED_ADMIN_HOSTS and ALLOWED_ADMIN_IPS instead of ignoring them

james.oates commented

2026-10-26 14:24:56 +00:00

Author

Owner

Fixed in f46c037, before the v2.0.0 tag — and wider than this issue described.

ALLOWED_ADMIN_IPS is equally inert and was set in .env.example and the makefile alongside the HOSTS one. It's the worse of the two, because it reads as the IP allowlist. Both are handled.

Removed from docker-compose.yml (both the live and commented blocks), .env.example and the makefile. docker-compose.yml now carries a comment pointing at [[admin]] with allow_ips, and noting that with no [[admin]] entry the admin API is open (#54).

Deleting them from our own files only fixes our files, though — a deployment's existing compose would have gone on setting them silently, which is the actual defect. So both are now a hard startup error naming [[admin]]/host/allow_ips as the replacement, matching what ER does with every other removed setting. Breaking, which v2.0.0 already is.

344 tests green, clippy clean, fmt clean. No test sets either variable.

Fixed in `f46c037`, before the v2.0.0 tag — and wider than this issue described. `ALLOWED_ADMIN_IPS` is equally inert and was set in `.env.example` and the makefile alongside the HOSTS one. It's the worse of the two, because it reads as the IP allowlist. Both are handled. Removed from `docker-compose.yml` (both the live and commented blocks), `.env.example` and the makefile. `docker-compose.yml` now carries a comment pointing at `[[admin]]` with `allow_ips`, and noting that with no `[[admin]]` entry the admin API is open (#54). Deleting them from our own files only fixes our files, though — a deployment's existing compose would have gone on setting them silently, which is the actual defect. So both are now a **hard startup error** naming `[[admin]]`/`host`/`allow_ips` as the replacement, matching what ER does with every other removed setting. Breaking, which v2.0.0 already is. 344 tests green, clippy clean, fmt clean. No test sets either variable.

james.oates closed this issue

2026-10-26 14:25:03 +00:00

james.oates referenced this issue

2026-10-26 15:38:38 +00:00

An empty MASTER_API_KEY_FILE falls through silently, and the startup log names the wrong source #61

james.oates referenced this issue

2026-10-27 10:55:00 +00:00

An empty MASTER_API_KEY_FILE falls through silently, and the startup log names the wrong source #61