IM Engineer Study Notes
← Back to list
Infrastructure & Cloud
#컨테이너#네임스페이스#cgroups#OCI#runc#샌드박스런타임
Last updated · 2026-10-16

Container Isolation & Runtime

1. Overview

A. Definition

Container isolation and runtime technology refers to the combination of OS-level isolation facilities in the Linux kernel — namespaces, control groups (cgroups), privilege reduction (capabilities), and system-call filtering (seccomp) — that makes many processes running on a single kernel appear to run in independent execution environments, together with the software layer (the runtime) that creates, runs, and terminates them according to the OCI (Open Container Initiative) standard.

Unlike hypervisor-based virtual machines, which virtualize hardware and load a separate kernel for every guest OS, containers share the host kernel and isolate only at the process level. There is therefore no boot process and no need for a guest OS image of hundreds of megabytes, so containers start within tens of milliseconds and can be densely packed by the hundreds or thousands on a single node. But sharing the kernel also means that "the strength of isolation depends on the correctness of kernel features and the quality of configuration," and this is the starting point for container security and runtime design.

B. Background and necessity

First, a VM replicates an entire OS just to isolate one application, resulting in low resource efficiency and slow deployment. In a world that splits workloads into dozens or hundreds of small microservices, the cost of booting a multi-gigabyte VM per service became unsustainable. Containers solved this by providing a lightweight unit that "packages only the application and its dependencies."

Second, the "it works on my laptop but not in production" environment-mismatch problem was severe. A container image fixes libraries, runtime, and configuration into a single immutable artifact, guaranteeing reproducibility across development, test, and production. This reproducibility became the prerequisite for CI/CD automation, namely [[ci-cd-pipeline]] and [[gitops]].

Third, in 2013 Docker popularized Linux kernel features by wrapping them in an easy CLI and image format, and in 2015 the OCI was launched and standardized the image format, runtime, and distribution specifications, forming an ecosystem free of vendor lock-in. As a result, Docker, containerd, CRI-O, and Podman interoperate, and [[kubernetes]] can treat the runtime as replaceable through the CRI (Container Runtime Interface).

C. Characteristics

Container isolation simultaneously carries three characteristics: (1) a shared kernel — the source of performance and density and also the weak point of the security boundary, (2) a declarative immutable image — the basis of reproducibility and supply-chain traceability, and (3) standards-based replaceability — vendor neutrality through OCI/CRI. Depending on where these three are balanced, isolation levels ranging from pure containers to sandboxed runtimes and lightweight VMs are selected.

2. Core Components of Container Isolation

A container is not a single technology but a combination of multiple kernel features. We first survey the whole structure, then explain the principle of each component.

graph TD
    subgraph Host["Host (single shared kernel)"]
        K["Linux kernel"]
        subgraph C1["Container A"]
            P1["Application process"]
        end
        subgraph C2["Container B"]
            P2["Application process"]
        end
    end
    K -->|"Namespaces (what can be seen)"| C1
    K -->|"Namespaces (what can be seen)"| C2
    K -->|"cgroups (how much can be used)"| C1
    K -->|"cgroups (how much can be used)"| C2
    K -->|"capabilities/seccomp/LSM (what can be done)"| C1
    K -->|"capabilities/seccomp/LSM (what can be done)"| C2

A. Namespaces — isolation of visibility

A namespace partitions "what a process can see." A PID namespace makes a container's internal process perceive itself as PID 1, so it cannot see the host's other processes. A NET namespace provides an independent network stack (interfaces, routing tables, firewall rules), so each container can have its own IP and port space. In addition there are the MNT (filesystem mounts), IPC (shared memory/semaphores), UTS (hostname), USER (user/group ID mapping), CGROUP, and TIME namespaces — eight types in the kernel as of 2024.

The USER namespace is particularly central to security. Mapping the container's internal root (UID 0) to an unprivileged host user (e.g., UID 100000) means that even if a container escape occurs, the attacker gains only ordinary user privileges on the host, greatly reducing the damage. This is the foundation of the rootless containers explained later.

B. Control groups (cgroups) — isolation of resources

cgroups limit and measure "how much resource a group of processes can use." They control CPU quota (e.g., 0.5 vCPU), memory limit (e.g., 512 MiB), block I/O bandwidth, PID count, and so on, preventing one container's runaway from paralyzing the whole node — the noisy-neighbor problem. If the memory limit is exceeded, for instance, the OOM Killer terminates that container's processes to protect the other workloads.

Today the standard is cgroups v2, which simplifies the hierarchy and manages resource types in a unified way. Working with systemd, it operates as a single unified hierarchy; cgroups v2 reached GA in Kubernetes 1.25, enabling precise load control based on memory-pressure signals (PSI, Pressure Stall Information).

C. Privilege reduction and system-call filtering — isolation of actions

capabilities split the traditionally "all-or-nothing" root privilege into roughly forty finer-grained privileges. A container runtime by default grants only a minimal set, having removed dangerous privileges such as CAP_NET_RAW and CAP_SYS_ADMIN. seccomp (secure computing) uses BPF filters to restrict, via a whitelist, the system calls a process may issue, reducing the kernel attack surface — Docker's default profile blocks 44 dangerous system calls out of roughly 300. If an LSM (Linux Security Module) such as SELinux or AppArmor is layered on to control file and network access at the mandatory-access-control level, a second line of defense operates even when a namespace is breached.

Category Control question Main functions Impact on isolation failure
Namespaces what is seen PID/NET/MNT/USER, 8 types exposure of other containers' or host resources
cgroups how much is used CPU/memory/I/O/PID limits resource exhaustion, denial of service
capabilities what is done root privilege subdivision privilege escalation, host takeover
seccomp/LSM how the kernel is called system-call/MAC restriction kernel-vulnerability exploitation, escape

As the table shows, the three categories answer different questions and must work together as defense in depth. The implication at the heart of container security design is that no single one of them alone constitutes complete isolation.

3. Container Runtime Architecture and Execution Procedure

Runtimes are divided by role into a high-level runtime (orchestrating image management, networking, storage) and a low-level runtime (the OCI runtime that actually sets up namespaces and cgroups and launches the process). We explain these layers through the call flow when Kubernetes launches a Pod.

sequenceDiagram
    participant K as kubelet
    participant HL as containerd / CRI-O (high-level)
    participant S as containerd-shim
    participant LL as runc / crun (low-level OCI)
    participant KN as Linux kernel
    K->>HL: CRI gRPC call (RunPodSandbox/CreateContainer)
    HL->>HL: pull/unpack OCI image, compose rootfs
    HL->>S: create shim process (decouple container lifecycle)
    S->>LL: pass OCI bundle (config.json + rootfs)
    LL->>KN: clone() + set namespaces/cgroups/capabilities
    KN-->>LL: launch isolated PID 1 process
    LL-->>S: return result and exit
    S-->>HL: report container state (shim stays resident)

A. High-level runtime and CRI

So as not to be tied to a specific runtime, the kubelet communicates through a gRPC standard called the CRI (Container Runtime Interface). When Kubernetes deprecated the Docker-specific connection layer (dockershim), removing it in 1.24 in 2020, containerd and CRI-O became the de-facto standard high-level runtimes. The high-level runtime pulls OCI images from the image registry, merges the layers, connects networking (CNI) and storage (CSI), and then builds the OCI bundle (rootfs + config.json).

B. The shim and the low-level OCI runtime

The containerd-shim stays resident, taking on the role of parent of the container process, so that even if the containerd daemon restarts the running container does not die — it decouples the lifecycle. The actual isolation setup is performed by the low-level runtime runc (Go). runc creates namespaces with the clone()/unshare() system calls, applies cgroups, capabilities, and seccomp, and then execs the user process. Recently, OCI-compatible alternative runtimes such as crun (written in C to reduce memory use and startup latency) and youki (written in Rust) have appeared and are seeing growing adoption in high-density, low-latency environments.

C. Images and the supply chain

The reproducibility of the execution procedure rests on the OCI image spec (content-addressed layers plus a manifest). An image with the same digest (SHA-256) is identical everywhere, so combining image signing, [[sbom]], and vulnerability scanning lets the software supply-chain integrity be verified. In other words, the runtime is expanding to be responsible not only for "isolated execution" but also for "execution of verified artifacts."

4. Comparison of Hardened and Sandboxed Runtimes

To compensate for the limits of a shared kernel, runtimes that raise the isolation strength have appeared. Rather than a plain list, we compare them focusing on why each choice was made.

Approach Isolation boundary Kernel sharing Startup speed Density/efficiency Representative use
Standard container (runc) namespaces/cgroups directly shares host kernel very fast (tens of ms) highest general microservices
gVisor (runsc) user-space guest kernel intercepts system calls fast high multi-tenant PaaS
Kata Containers lightweight VM (hardware) guest kernel separated medium (hundreds of ms) medium tenants with different trust boundaries
Firecracker microVM microVM (hardware) guest kernel separated fast (~125 ms) high serverless (FaaS)

gVisor, released by Google, has a self-made guest kernel (Sentry) running in user space intercept and handle a container's system calls. It dramatically reduces the system-call surface that touches the host kernel directly, lowering the risk of escape through a kernel vulnerability. However, because it relays system calls, it incurs performance degradation for I/O-intensive workloads — a trade-off that makes it suitable for multi-tenant environments running low-trust code in isolation.

Kata Containers wraps each Pod in a lightweight VM on a hypervisor such as QEMU or Cloud Hypervisor, providing hardware-level kernel separation. Because it preserves the standard container interfaces (OCI/CRI) as-is, one can choose stronger isolation by changing only runtimeClassName without modifying the application. [[confidential-containers]] is an extension that adds TEE memory encryption on top, showing that Kata-based lightweight-VM isolation becomes the foundation of confidential computing.

Firecracker is a microVM that AWS built for Lambda and Fargate; it finishes booting within about 125 ms and lowers the per-VM memory overhead to roughly 5 MiB, densely running thousands of isolated function instances on a single host. As a case combining the strong isolation of a VM with the fast startup of a container, it is a practical example of relaxing the conventional belief that "isolation strength and performance must conflict" through an attack-surface-minimizing design.

5. Deep Dive: Trends and Practical Application

A. Spread of rootless containers

Traditionally the container daemon ran as root, so if the daemon was hijacked the whole host was at risk. The rootless approach, which leverages the USER namespace, runs the daemon/runtime as an unprivileged user and maps the container's internal root to an ordinary host user. Podman adopted a daemonless, rootless structure by default, and Kubernetes also supports a rootless kubelet experimentally, so the "least privilege" principle is shifting to become the runtime default.

B. Combination with Wasm runtimes

There is also a clear move to bring WebAssembly ([[webassembly]]) into the container ecosystem. Using containerd's runwasi shim, a Wasm module can be packaged as an OCI image and deployed like a Pod. Wasm starts in sub-milliseconds and guarantees memory isolation at the language level, so it is drawing attention as a complement to lightweight containers in the ultra-low-latency workloads of serverless and edge ([[edge-computing]]).

C. Kernel-level visibility and security — eBPF

[[ebpf]]-based tools (Cilium, Falco, Tetragon) observe and enforce a container's system calls and network flows directly in the kernel, performing runtime threat detection and network-policy enforcement. In finance, for example, it is increasingly common to detect anomalous behavior toward the container runtime (an unexpected shell execution, a privilege-escalation attempt) with eBPF and implement runtime security (a kind of workload self-protection similar to [[rasp]]). This shows isolation expanding from "static configuration" to "dynamic detection and response."

6. Considerations and Implications

From a professional engineer's perspective, adopting container isolation/runtime must be judged comprehensively on the following.

  • Designing the isolation-level vs. performance trade-off: Applying VM-grade isolation to every workload worsens cost and performance. A realistic approach is a layered isolation strategy based on runtimeClassName that selectively applies gVisor/Kata only to low-trust workloads, using the trust boundary (code inside the same organization vs. external tenant code) as the criterion.
  • Making least privilege the default: Removing capabilities, enforcing seccomp/AppArmor profiles, rootless and read-only root filesystems, and USER-namespace mapping should be made the default policy. The Restricted profile of [[kubernetes-pod-security-standards]] should be enforced at the admission stage to prevent configuration omissions.
  • Control that includes supply-chain trust: Isolated execution alone does not stop malicious or vulnerable images. Image-signature verification, [[sbom]] generation, vulnerability scanning, and registry access control should be connected via CI/CD and [[policy-as-code]] to enforce "run only verified artifacts."
  • Linking observability with runtime threat response: Alongside static isolation configuration, eBPF-based runtime detection ([[edr]], Falco) and central logging/[[observability]] should be combined to build a system that detects and responds early at the moment isolation is breached.
  • Securing standards and vendor neutrality: Choosing an OCI/CRI-compliant runtime avoids lock-in to a specific vendor and, as the dockershim-removal case shows, maintains a replaceable architecture prepared for ecosystem change.

In sum, container isolation is not a single feature but a trusted-execution system combining kernel isolation elements, the runtime layers, the supply chain, and observability; the professional engineer is asked for the capability to design the balance point among security, performance, and operational efficiency to fit the organization's trust model.

References

In one line: Container isolation/runtime isolates processes on a shared kernel via Linux namespaces (visibility), cgroups (resources), and capabilities/seccomp (actions) and runs them through OCI/CRI standard runtimes (containerd→runc), complementing the shared kernel's security limits with sandboxed/lightweight VMs such as gVisor, Kata, and Firecracker plus rootless and eBPF observation to design the balance between isolation strength and performance.