Listen to this Post
Introduction:
Containers have revolutionized modern IT infrastructure, but their operation is often misunderstood as a form of lightweight virtualization. In reality, containers are simply standard Linux processes that leverage two critical kernel features—Namespaces and Cgroups—for isolation and resource control. Understanding these fundamentals is essential for cybersecurity professionals and DevOps engineers to debug issues, harden environments, and prevent resource-based attacks.
Learning Objectives:
- Understand the distinct roles of Linux Namespaces and Cgroups in containerization.
- Learn to inspect and verify namespace isolation on a live system.
- Master the use of cgroup limits to control container resource usage and prevent DoS.
- Apply debugging techniques for common Kubernetes issues like OOMKilled and CPU throttling.
You Should Know:
1. Inspecting Namespace Isolation in Running Containers
Namespaces create separate views of the system for a process, ensuring that a containerized application cannot see or interfere with processes on the host or in other containers. To see this in action, start a container and inspect its namespaces.
Step‑by‑step guide explaining what this does and how to use it.
First, run a simple container in detached mode:
`docker run -d –name test-container nginx sleep 3000`
Now, get the Process ID (PID) of the container’s main process on the host:
`docker inspect –format ‘{{.State.Pid}}’ test-container`
With the PID (e.g., 1234), you can explore the namespaces this process belongs to. List the namespace files:
`ls -l /proc/1234/ns/`
You will see symbolic links like pid:[bash]. Each number represents a unique namespace. To verify that the container has its own PID namespace, compare the PIDs it sees. Exec into the container:
`docker exec -it test-container ps aux`
This will show only a few processes (e.g., nginx and sleep). Now, check the host’s process list with ps aux | grep sleep. You will see the same sleep process but with a different PID on the host. This proves PID namespace isolation: the process has a different PID inside the container than it does on the host.
- Controlling Resources with Cgroups to Prevent Noisy Neighbors
Cgroups (Control Groups) are the mechanism that enforces resource limits, preventing a single container from consuming all host memory or CPU. This is critical for security, as it mitigates denial-of-service attacks from compromised or buggy applications.
Step‑by‑step guide explaining what this does and how to use it.
Run a container with a strict memory limit:
`docker run -d –name memory-test –memory=”256m” –memory-swap=”256m” alpine sleep 3600`
This command limits the container to 256 MB of RAM and disables swap. To verify the cgroup configuration on the host, find the container’s PID again:
`docker inspect –format ‘{{.State.Pid}}’ memory-test`
Then, check the memory cgroup for that PID:
`cat /proc/1235/status | grep -i cgroup`
You can also navigate the cgroup virtual filesystem directly (the path varies by system). For systems using cgroup v2:
`cat /sys/fs/cgroup/system.slice/docker-/memory.max`
To demonstrate the limit in action, attempt to consume more memory than allowed:
`docker run –memory=”100m” alpine sh -c “dd if=/dev/zero of=/dev/null bs=1M count=200″`
The kernel’s out-of-memory (OOM) killer will terminate the process. This is the exact same mechanism that causes Kubernetes pods to show an `OOMKilled` status.
3. Simulating and Debugging OOMKilled and CPU Throttling
Understanding cgroups is vital for debugging orchestrated environments. When a Kubernetes pod is killed for exceeding memory, it’s not a Docker error—it’s the Linux kernel enforcing a cgroup.
Step‑by‑step guide explaining what this does and how to use it.
First, simulate a memory spike. Install `stress` in a container:
`docker run -it –memory=”200m” ubuntu bash`
`apt-get update && apt-get install -y stress`
`stress –vm 1 –vm-bytes 250m –vm-keep`
This will almost immediately kill the container. On the host, you can monitor these OOM events:
`dmesg | tail -20 | grep -i oom`
You will see logs indicating the cgroup’s OOM killer was invoked.
For CPU throttling, run a container with a CPU limit:
`docker run -d –name cpu-test –cpus=”0.5″ alpine md5sum /dev/zero`
This container will attempt to use 100% of a core but will be throttled to 50%. You can inspect the CPU statistics using:
`docker stats cpu-test`
To see the underlying cgroup data:
`cat /sys/fs/cgroup/system.slice/docker-/cpu.max`
This file shows the quota and period (e.g., “50000 100000”), meaning the process gets 50ms of CPU time per 100ms period.
- Creating Isolated Environments Without Docker Using Raw Linux Tools
You can create a makeshift container manually using Linux commands, which clarifies how tools like Docker are just wrappers around these kernel features.
Step‑by‑step guide explaining what this does and how to use it.
Use `unshare` to run a process in new namespaces:
`sudo unshare –fork –pid –mount-proc bash`
This command creates a new PID and mount namespace. Running `ps aux` inside this new shell will show only the current shell and its child processes, not the full host.
Next, apply a cgroup limit to this process. First, create a new cgroup (on cgroup v2 systems):
`sudo mkdir /sys/fs/cgroup/example-cgroup`
`echo “+memory” > /sys/fs/cgroup/example-cgroup/cgroup.subtree_control`
Set a memory limit:
`echo “100000000” > /sys/fs/cgroup/example-cgroup/memory.max`
Find the PID of the bash session (from another terminal) and add it to the cgroup:
`echo > /sys/fs/cgroup/example-cgroup/cgroup.procs`
Now, any process forked from that bash session is subject to the 100MB memory limit, demonstrating that a container is just a set of processes grouped together with namespace isolation and cgroup restrictions.
5. Examining Cgroup and Namespace Configuration in Kubernetes
In Kubernetes, these concepts are abstracted but still accessible. To diagnose a pod, you must often look at the underlying node.
Step‑by‑step guide explaining what this does and how to use it.
First, `exec` into a pod:
`kubectl exec -it — sh`
Inside the pod, you cannot see cgroups directly, but you can feel their effect. To inspect the cgroup from the node level, you need to find the container runtime and its PID. On the Kubernetes node (requires SSH access), list running containers:
`docker ps | grep `
Get the PID as shown in previous steps. Then, inspect the cgroup configuration:
`cat /proc//mountinfo | grep cgroup`
This shows where the cgroup filesystem is mounted for that process. You can then navigate to that path and read the `memory.limit_in_bytes` file to see the pod’s memory limit. This is how tools like `kubectl top` and `kubectl describe` gather their data, and understanding this helps you move beyond surface-level debugging to true root-cause analysis.
What Undercode Say:
- Isolation is not Virtualization: Namespaces create a filtered view, not a separate kernel, meaning a kernel exploit in a container can compromise the entire host. This is a critical security distinction.
- Resource Limits are a Security Control: Cgroups are your first line of defense against resource-exhaustion attacks. Always set appropriate memory and CPU limits in production.
- Observability Requires Host-Level Access: Troubleshooting container issues often requires dropping down to the node level to inspect `/proc` and cgroup files, as container runtimes abstract these details away.
- Mastering the fundamentals of Linux process isolation transforms container troubleshooting from guesswork into a precise science, allowing engineers to predict behavior rather than react to failures.
Prediction:
As eBPF and service mesh technologies evolve, we will see a shift towards more granular and dynamic security policies enforced directly at the namespace and cgroup level. Future exploits will likely target misconfigurations in these kernel primitives rather than the container runtime itself, making deep kernel knowledge a mandatory skill for infrastructure defenders. The convergence of AI-driven workload optimization will also rely heavily on real-time cgroup tuning, automating resource allocation to prevent both performance degradation and security breaches.
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Adityajaiswal7 Devops – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
