Namespaces and containers

Linux namespaces isolate particular global resources, such as process identifiers, mount views, network stacks, and user identities. The namespace types solve different problems. A private network stack does not independently establish a memory budget, and a private mount view does not make every reachable file harmless. Containers commonly combine namespaces with resource controls and additional restrictions, so evaluate the combination rather than attributing every property to a single mechanism.

Draw a containment matrix for a build worker: process visibility, filesystem access, network destinations, credentials, devices, and CPU or memory consumption. For each row, record the mechanism and an observable test. A worker that cannot see neighboring process IDs might still reach a credential service over the network. A reproducible packaging workflow and a hostile-code sandbox need different evidence even if both run the same image format.

A user namespace can map an identity inside the namespace to a different identity outside it. An apparent root user in the contained view therefore need not be host root. The mapping's permitted operations and file ownership still require careful configuration. Treat identity translation separately from the question of which files, sockets, and devices the process can access. A mounted privileged socket can defeat the intent of an otherwise narrow identity mapping.

The kernel's no_new_privs flag prevents an execution from gaining privileges through mechanisms such as set-user-ID execution or file capabilities; it is inherited and cannot be unset. It is not a universal ban on all possible privilege changes. For a platform, express the desired authority as an allowlist, remove unnecessary capabilities, and test the deployed runtime configuration. A declarative checkbox is useful only when its effective kernel behavior matches the policy being promised.

An internal stateless service and an arbitrary third-party compiler have different exposure. Shared-kernel containment can be a reasonable part of a defense for trusted services while a stronger boundary may be appropriate for hostile workloads. Compare kernel attack surface, patch cadence, device access, and operational recovery. Virtualization also has costs and residual risks; the choice should follow an explicit adversary and availability model rather than a claim that any one technology is categorically safe.

Measure the operational benefit without confusing it with a security proof. Layer sharing may reduce stored bytes, and a standardized runtime may simplify replacement, but neither observation establishes isolation. Test that a terminated worker loses credentials, that private mounts disappear, and that logs remain attributable to the correct tenant. When an incident spans several containers on one host, preserve enough host-level evidence to investigate the shared boundary instead of relying exclusively on each container's restricted view.