k3os overlayFS host directory exposure through misconfigured mounts

Question

k3os deploys a read-only root filesystem mounted through initramfs to safeguard base OS binaries from unintended writes. The overlayFS configuration option, when present in the k3os definition, permits administrators to designate specific directories as writable while preserving the immutability of the core root. This design prevents accidental host service exposure in typical container workloads, yet the interaction between overlay layer path mappings and container runtime port handling introduces configuration points where a mis-specified mount can inadvertently grant host-level accessibility. Services requiring write access, such as logging or stateful data directories, must be assigned dedicated writable mounts or data directories; otherwise they may fall back to the read-only root or trigger fallback behaviors. The extent to which overlayFS path mappings translate to host-visible directories depends on the exact mount syntax and the container runtime's namespace isolation settings.

Under what overlayFS path mapping configuration does a host directory become accessible from the booted k3os environment? How does the containerd integration enforce port isolation when the root filesystem remains read-only? What is the minimal writable mount specification required for system logging without compromising the read-only root integrity?

Tasadduq Burney · Answer

When overlayFS exposes a host directory in k3os
A host directory becomes accessible from the booted k3os environment when the overlay mount maps a host path into lowerdir or upperdir without the private bind-mount flag. In that case the host path is part of the overlay mount tree and can be reached from the running system, which weakens the read-only root design intended to protect base OS binaries.
Confirmed facts

k3os boots from initramfs with a read-only root that serves as the overlay lowerdir.
The writable upperdir is defined in the k3os overlay configuration.
containerd assigns each container its own network namespace, so port binding is independent of filesystem mount layout.
System logging needs a dedicated writable directory; otherwise logging falls back to the read-only root or triggers fallback behavior.

Steps for this case

Inspect the active overlay mount: mount | grep overlay or cat /proc/mounts.
Confirm the mount option includes private and that upperdir points to a dedicated directory such as /var/lib/k3os/overlay/logs, not a broad host path.
Verify containerd is not using host networking for the workload; check the container configuration or runtime config for network namespace isolation.

Minimal writable mount for logging
Create a dedicated host directory for overlay upperdir, for example /var/lib/k3os/overlay/logs, and configure the overlay with lowerdir set to the read-only root and upperdir set to that directory with the private flag. This keeps log writes outside the read-only root while preventing other host processes from reaching the writable layer.
Assumption: this behavior applies to k3os releases that use initramfs-booted read-only roots with containerd; exact mount syntax varies by k3os version. Missing diagnostic: Is the logging directory already bind-mounted on the host outside the overlay? If yes, choose a different path because an existing host bind mount can bypass overlay isolation.

k3os overlayFS host directory exposure through misconfigured mounts

1 answer

When overlayFS exposes a host directory in k3os

Confirmed facts

Steps for this case

Minimal writable mount for logging

Your perspective belongs here.

0 question comments