From 3536ed884c4661a9d2f44a57fc1e8ebce6285d10 Mon Sep 17 00:00:00 2001 From: Marcel Date: Sat, 6 Jun 2026 14:37:03 +0200 Subject: [PATCH] =?UTF-8?q?docs(adr):=20fix=20ADR-028=20=C2=A712=20false?= =?UTF-8?q?=20API-key=20claim,=20stale=20TBD,=20and=20=C2=A77=20title?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit §12 stated OLLAMA_API_KEY guards against lateral movement — contradicts §7's empirical finding that it is not enforced. Replaced with an accurate note referencing §7. Stale pre-merge placeholder in Consequences ("Three TBD items must be resolved") removed; all three are resolved. §7 section title updated from "0.6.5" to "0.6.5 and 0.30.6" to match the body text. Co-Authored-By: Claude Sonnet 4.6 --- docs/adr/028-ollama-docker-compose-service.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/adr/028-ollama-docker-compose-service.md b/docs/adr/028-ollama-docker-compose-service.md index e65e8186..24a2d1bd 100644 --- a/docs/adr/028-ollama-docker-compose-service.md +++ b/docs/adr/028-ollama-docker-compose-service.md @@ -110,7 +110,7 @@ if (!apiKey.isBlank()) { Sending `Authorization: Bearer ` (empty token) has undefined or potentially broken behavior depending on the Ollama version. This mirrors the `trainingToken` guard in `RestClientOcrClient.java:107`. -### 7. OLLAMA_API_KEY behavior in Ollama 0.6.5 +### 7. OLLAMA_API_KEY behavior in Ollama 0.6.5 and 0.30.6 **Empirically verified (2026-06-06) on both `0.6.5` and `0.30.6`:** `OLLAMA_API_KEY` does **not** enforce request authentication in either version. @@ -185,7 +185,7 @@ The model is pre-pulled by `ollama-model-init` before the main service starts (v **Primary control:** `archiv-net` network isolation. Ollama has no externally exposed port (`expose:` only, not `ports:`). The Caddyfile must not route any path to the Ollama service. -**Defense-in-depth:** `OLLAMA_API_KEY` guards against lateral movement from a compromised backend container. +**Note on `OLLAMA_API_KEY`:** Per §7, `OLLAMA_API_KEY` is not enforced in Ollama 0.6.5 or 0.30.6 and provides no authentication barrier against a compromised backend container. `archiv-net` network isolation is the sole effective security control. The env var is retained for forward compatibility only — do not rely on it for access control. Both `ollama` and `ollama-model-init` receive the ADR-019 hardening baseline: @@ -235,5 +235,5 @@ The init container re-pulls the model on next startup. - **Memory pressure:** OCR + Ollama together consume ~14 GB on a 16 GB host. Running the observability stack simultaneously risks OOM kills. Monitor with `docker stats`. - **CPU inference latency:** `qwen2.5:7b-instruct-q4_K_M` is chosen for CPU viability, but inference on 8 vCPUs will be noticeably slower than GPU-accelerated alternatives. This is acceptable for the family archive use case (low concurrency, not real-time). -- **Three TBD items** (OLLAMA_API_KEY empty-string behavior, `read_only` feasibility, init container peak RSS) must be resolved before the PR is merged. See Decisions §7, §8, §9. +- All three empirical TBD items from the original issue spec were resolved — see §7 (OLLAMA_API_KEY not enforced), §8 (`read_only: true` works), §9 (peak RSS ~108 MiB). - Model upgrades require a `docker volume rm` to free old weights before pulling the replacement. Document this in runbook/DEPLOYMENT.md.