Containers: image format, runtime boundary and failure semantics

A container image is packaged content. A container runtime is a lifecycle implementation. A Linux container is one or more processes running on the host kernel under a composed set of namespaces, cgroups, credentials, capabilities, LSM, seccomp, mounts and networking policy. Treating any one layer as “the container” produces security and operations mistakes.

OCI images and layers

An OCI manifest references a configuration object and ordered filesystem layer blobs by digest. A layer is a filesystem changeset. Applying layers requires whiteout semantics; it is not equivalent to blindly unpacking every tar archive into an arbitrary directory.

Pin deployments to an immutable digest. Verify descriptor digest, size and media type as content is fetched. Registry authentication controls access to blobs; provenance/signature admission is an additional policy and must fail according to the product’s trust model. A content digest proves identity of bytes, not that those bytes are safe.

Layers improve distribution reuse but do not create runtime isolation. Secrets copied into an earlier layer are not made safe by deleting them in a later layer. Build contexts, caches and attestations need their own controls.

OCI runtime and shared-kernel isolation

The runtime consumes a bundle with config.json and a root filesystem, configures the declared platform state, then starts the process. For Linux, the OCI specification describes namespace, cgroup, capability, seccomp, mount and LSM fields.

Namespace types are independent. If a namespace type is omitted, the runtime can inherit the runtime namespace for that type. A PID namespace does not imply a network namespace; a mount namespace does not impose a memory limit. Containers using a conventional runtime still share the host kernel, so kernel attack surface, capabilities, devices and host configuration matter.

Use rootless/user namespaces where compatible, drop capabilities, set noNewPrivileges, apply seccomp and LSM policy, mount minimally, avoid host namespace/device exposure, and keep the host kernel patched. None of those controls alone is a complete security boundary.

cgroup v2 memory behavior

memory.high is a throttle/reclaim boundary and does not directly invoke the OOM killer. memory.max is the hard usage boundary; if reclaim cannot reduce usage, an OOM killer can act within the cgroup. memory.oom.group controls whether a workload is treated as an indivisible group, subject to documented exceptions.

Diagnose with memory.events/memory.events.local, kernel events and runtime state. Status 137 is commonly the shell-style 128 + SIGKILL(9) result. It does not prove why SIGKILL happened: cgroup OOM, an operator, a timeout, host OOM or another controller can kill a process. Correlation is required.

Bridge networking

A container joins a specific network namespace and network. On a user-defined Docker bridge, members receive scoped connectivity and DNS behavior. Containers on different bridge networks are isolated by default except through explicit published/routed paths. The legacy default bridge has different, less desirable behavior and should not be generalized into “all containers share one bridge”.

Published ports, host networking and privileged network capabilities expand the boundary. Model ingress, east-west and egress policy separately, including IPv6 and DNS.

runc, gVisor and Kata are not interchangeable

A conventional OCI runtime configures processes against the shared host kernel. gVisor runsc inserts a userspace Sentry kernel and brokers a restricted host interface. Kata Containers integrates with the container ecosystem while running workloads behind a guest kernel in lightweight VMs.

All can accept OCI-oriented workflows, but compatibility is empirical. Test required syscalls, filesystems, networking, accelerators, observability agents, startup behavior and performance. “Stronger isolation” is not permission to skip resource controls or patching.

Scenarios

A digest-pinned manifest and every referenced blob are verified before ordered layer application.

The OCI runtime composes independent kernel controls before starting the process.

A user-defined bridge and explicit host routing replace the false model of one universal shared bridge.

memory.high, memory.max, OOM telemetry and status 137 are kept semantically separate.

gVisor interposes a userspace kernel and requires workload compatibility testing.

Kata places a guest-kernel/VMM boundary behind the container integration surface.

Operational checklist

• Deploy immutable image digests and enforce provenance policy before execution.
• Set CPU, memory, PIDs and I/O controls; monitor pressure and throttling, not only usage.
• Keep container, runtime and host-kernel security boundaries visible in threat models.
• Use user-defined networks and explicit ingress/egress policy.
• Reproduce OOM and node-pressure incidents and verify the exact telemetry/runbook path.

Primary sources

• OCI runtime specification: https://github.com/opencontainers/runtime-spec
• OCI Linux configuration: https://github.com/opencontainers/runtime-spec/blob/main/config-linux.md
• OCI layer specification: https://github.com/opencontainers/image-spec/blob/main/layer.md
• Linux cgroup v2: https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html
• Docker bridge driver: https://docs.docker.com/engine/network/drivers/bridge/
• gVisor architecture: https://gvisor.dev/docs/