containers-internals
Containers Internals covers the low-level mechanisms that power Docker and Podman: process namespaces for isolation, cgroups v2 for resource limits, overlayfs for layered storage, and seccomp-bpf for syscall filtering. Explore runc, the OCI spec, Linux capabilities, rootless user namespaces, and practical escape mitigations.
Containers Internals explains how namespaces and cgroups enforce process and resource isolation in Linux containers.
AI-generated summary based on this skill's SKILL.md
Install
mohitmishra786/low-level-dev-skills/containers-internals · repository language: JavaScript
git clone https://github.com/mohitmishra786/low-level-dev-skills
cp -r low-level-dev-skills/skills/virtualization/containers-internals ~/.claude/skills/containers-internalsnpx skillfed install mohitmishra786/low-level-dev-skills/containers-internalsFrequently asked questions
AI-generated answers based on this skill's SKILL.md and metadata
How do Linux namespaces work in containers?
Containers Internals explains that Linux namespaces isolate process views of system resources. CLONE_NEWPID creates a new process tree; CLONE_NEWNET isolates network interfaces and routing; CLONE_NEWNS isolates mount points; CLONE_NEWUSER maps UIDs/GIDs for rootless containers. Tools like unshare and nsenter let you inspect and manipulate namespaces directly. The kernel enforces these boundaries, making processes in one namespace unable to see or interact with resources in another.
What are cgroups v2 memory limits and how do they cause OOM?
Containers Internals covers cgroups v2 as the unified resource controller for CPU, memory, and I/O. Memory limits set hard caps; when a process exceeds them, the kernel triggers OOM kill. CPU throttling enforces shares or quotas, slowing tasks rather than killing them. Debugging involves reading cgroup.stat, memory.events, and cpu.stat files. Kubernetes and container runtimes translate resource requests into cgroup settings; misconfiguration causes premature OOM or CPU starvation.
How does overlayfs enable Docker's layered storage?
Containers Internals describes overlayfs as a union filesystem that stacks read-only base layers with a writable top layer. Docker images are composed of immutable layers; overlayfs merges them on-the-fly without copying data. The lowerdir points to image layers, upperdir to the container's changes, and workdir to temporary state. Copy-on-write semantics mean only modified files consume extra space, making containers lightweight and fast to start.
What is runc and how does it relate to the OCI specification?
Containers Internals explains that runc is a reference OCI runtime—a low-level tool that spawns containers from OCI bundle directories. The OCI spec defines the runtime format: a config.json file describing namespaces, cgroups, mounts, and capabilities, plus a rootfs directory. runc reads this config and uses Linux syscalls (clone, unshare, cgroup_create) to set up isolation. Docker and Podman use runc under the hood; you can build minimal containers manually with runc without Docker.
How do you write and audit seccomp profiles for container sandboxing?
Containers Internals covers seccomp-bpf as a kernel mechanism that filters syscalls via Berkeley Packet Filter rules. A seccomp profile is a JSON file listing allowed/blocked syscalls and their arguments. Tools like audit logs show blocked calls; strace reveals which syscalls a process needs. Start permissive, audit blocked calls, then tighten the profile. Kubernetes and runc apply profiles via the OCI spec; tight profiles reduce attack surface by preventing dangerous syscalls like ptrace or module_load.
What are common container escape vectors and how do you mitigate them?
Containers Internals identifies escape routes: privileged containers (CAP_SYS_ADMIN), kernel exploits, unpatched runtimes, and misconfigured seccomp. Mitigations include dropping unnecessary capabilities (use CAP_NET_BIND_SERVICE instead of CAP_SYS_ADMIN), enabling seccomp profiles, running rootless (user namespaces), keeping the kernel and runtime patched, and using read-only root filesystems. Defense-in-depth layering—namespaces, cgroups, capabilities, seccomp, and AppArmor—makes escapes exponentially harder.
SKILL.md
rendered from the published skill — quoted content, verbatim
Containers Internals
Purpose
Guide agents through Linux container internals: namespaces (clone, unshare, nsenter), cgroups v2 resource limits, overlayfs storage, runc and the OCI runtime spec, seccomp-bpf filtering, Linux capabilities for privilege dropping, and container escape mitigations.
When to Use
- Understanding how Docker/Podman isolate processes under the hood
- Debugging container resource limits (OOM, CPU throttling)
- Writing custom seccomp profiles for sandboxed workloads
- Building minimal containers without Docker
- Investigating container escape vulnerabilities
- Tuning cgroups v2 for Kubernetes pods
Workflow
1. Namespaces
```bash
List namespaces for a process
ls -la /proc/self/ns/ readlink /proc/self/ns/pid readlink /proc/1234/ns/net
Enter container namespaces
nsenter -t
(truncated - see the full file via the links below)
Read as markdown · JSON record · Browse the source repository
File tree — 1 file
skills/virtualization/containers-internals/SKILL.md