When mlock Is Gone, Swap Policy Becomes Part of Secret-Server Hardening

After adapting to the OpenBao 2.6 memory model, the next question was what replaced the protection we expected from mlock. Simply deleting an unsupported option would have fixed validation without preserving the security objective. The objective was preventing sensitive pages from being casually swapped out, while the previous mechanism was only one implementation of that objective. Treating mechanism and requirement as the same thing would have left a silent gap.

The container received equal memory and memory-swap limits plus zero swappiness, and the unnecessary IPC_LOCK capability was removed. That reduced both swap exposure and privilege surface.

The service documentation now states the memory-model rationale alongside the Compose settings. Future upgrades can test the invariant directly instead of assuming the old directive must remain forever. Good hardening starts from invariants: define the property you need, then select controls supported by the current platform. This avoids cargo-cult security configuration that survives long after the underlying behavior changes. The concrete hserver evidence is commit 47464d4, so this note is tied to an actual production change rather than a hypothetical failure.