The pod hardening stopped postgres, web and the frontend from starting

[krlex]

Found by installing the chart into a real k3s cluster for the first time. The hardening from #7 had been rendered and reviewed, but never run — and it takes down three of the three stateful components.

postgres  chown: /var/lib/postgresql/data/pgdata: Operation not permitted
frontend  chown("/var/cache/nginx/client_temp", 101) failed
web       chown("/var/lib/nginx/body", 65534) failed

All three start as root on purpose, fix ownership on their own runtime directories, then drop to their own user. capabilities.drop: [ALL] takes CHOWN with everything else, so they die in the entrypoint before they ever get to dropping privileges. The result is an install with nothing serving and a database that never comes up — CrashLoopBackOff on postgres, web and frontend, and a task pod that never goes Ready because the schema is never created.

The fix

Each of the three gets exactly what its entrypoint needs, and keeps the blanket drop for the rest:

	added
web, frontend	CHOWN, SETUID, SETGID, NET_BIND_SERVICE
postgres	CHOWN, FOWNER, DAC_OVERRIDE, SETUID, SETGID

Components that already run as their own user from PID 1 — task, redis, opa, otelCollector, init, assistant — are untouched and still drop everything.

Second bug in the same block

assistantOllama was listed twice, and the second entry ({}) silently won. The Ollama container had no hardening at all while appearing to have it. Now listed once.

Verified

Two-node k3s cluster (1 server + 1 agent), chart installed with task.privileged=true task.hostCgroup=true:

• without the fix — postgres, web, frontend all CrashLoopBackOff, 7 restarts
• with the fix — all three 1/1 Running; redis, opa and the collector unaffected throughout

Note

This is exactly the gap PLAN-2026-08 warns about: the chart's security work was never validated against a cluster. It is worth deciding whether a smoke install belongs in CI before the next chart change.