Verify the daemon context when adopting Docker rootless mode

Running a process as an ordinary container user is different from running the daemon without root.

Source facts

Docker rootless mode runs both the daemon and containers as a non-root user. It executes them inside a user namespace. Docker distinguishes this from userns-remap, where the daemon itself remains privileged. Its prerequisites include newuidmap, newgidmap and subordinate UID/GID allocations.

Source: Docker documentation — Rootless mode.

Applicability

Review rootless daemon identity and prerequisites, distinguishing it from user-namespace remapping and an independently running rootful daemon.

DSE recommendation

DSE recommends inventorying required host integrations before moving a workload to rootless operation. Record the service-owning user, daemon endpoint, storage location, startup behavior, and administrative access path. Review any feature that previously depended on host privileges rather than compensating by adding broad exceptions. Make the active Docker context visible to administrators so commands do not accidentally target another daemon. Treat non-root execution as one defense in a broader image, secret, networking, and patching design.

Verification

On an approved test host, inspect the effective daemon user and active endpoint, then exercise the application’s required storage and networking functions. Confirm automatic service startup and recovery under the intended user context. Verify that unsupported requirements are identified before production migration rather than discovered during an outage. Retain the endpoint and user identity with the test output. Ask another administrator to target the intended daemon explicitly and inspect its workloads, so a working command against a different context cannot close the migration check.

Official reference

Docker documentation — Rootless mode. Reviewed October 20, 2026.