Container Security Fundamental Technology Concepts That Protect Containerized Applications Second Edition (First Early… (Liz Rice)（Z-Library）

【One-Line Pitch】 A hands-on, systems-level guide to the Linux primitives—system calls, capabilities, cgroups, and namespaces—that make container isolation possible, written for developers, ops, and security folks who want to reason about container risk from first principles rather than memorizing checklists. 【Book Arc】 - **Opening (~0%–3%)**: The book opens with a threat-modeling frame and a table of contents that maps the full journey—from Linux fundamentals to image vulnerabilities, network security, secrets, and runtime protection. The early-release note clarifies that this edition is a work in progress, with several chapters still unavailable. - **Early (~3%–23%)**: Chapter 1 dives into Linux system calls, file permissions, setuid/setgid bits, and capabilities. The core lesson: containers are just Linux processes, so host-level permission mechanics apply directly inside them. The chapter closes with privilege-escalation scenarios, including the default-root problem in containers. - **Early (~23%–32%)**: Chapter 2 covers control groups (cgroups)—the resource-limiting half of container isolation. You learn how to create cgroups, set memory and CPU limits, and understand the systemd driver hierarchy that Docker and Kubernetes use. The fork bomb example shows why limits matter for resilience. - **Middle (~39%–48%)**: Chapter 3 (labeled as Chapter 4 in the final book) is the heart of the matter: container isolation via namespaces. It walks through the seven namespace types, shows how to build a container from scratch using shell commands, and demonstrates the pitfalls of PID namespaces—like why `ps` still shows host processes without the right setup. - **Late (~48% onward, partially covered)**: The remaining chapters (virtual machines, images, vulnerabilities, network security, TLS, secrets, runtime protection, OWASP Top 10) are listed but not yet available in this early release. The book promises to contrast containers with VMs and then move into practical hardening and attack scenarios. 【Key Takeaways】 - **Containers are Linux processes, not magic** (Early): A containerized process uses system calls, permissions, and capabilities exactly like any other process on the host. This means host-level Linux security mechanics are the foundation for understanding container risk. - **The setuid bit is a privilege-escalation vector** (Early): Executables with setuid run with the file owner's user ID, which can grant unintended root-level access. The `ping` example shows how capabilities have largely replaced setuid for fine-grained privilege control. - **Capabilities are granular root permissions** (Early): Over 30 capabilities exist in the Linux kernel, each controlling a specific action (e.g., `CAP_NET_BIND_SERVICE` for low ports, `CAP_SYS_MODULE` for kernel modules). Processes can deliberately drop capabilities after use—like `ping` discarding `CAP_NET_RAW`—to reduce attack surface. - **Default root in containers is a systemic risk** (Early): By default, containers run as root. An attacker who escapes a container is already root on the host, eliminating the need for further privilege escalation. Non-root containers still face risks from setuid binaries and extra capabilities. - **Cgroups are the resource-limitation half of isolation** (Early): Control groups limit memory, CPU, and process counts. Setting `memory.max` or `pids.max` prevents resource exhaustion attacks and memory leaks from starving other processes on the host. - **Namespaces are the visibility-isolation half** (Middle): Each process belongs to exactly one namespace of each type (PID, mount, network, UTS, IPC, user, cgroup, time). Creating a new namespace makes processes see only their own view of the world—but the host kernel is still shared. - **Building a container from scratch clarifies the boundary** (Middle): Using `unshare` and shell commands, you can create a container-like environment step by step. The PID namespace example shows that without `--fork`, the shell can't even run child commands—and that `ps` still shows host processes unless you mount a new `/proc`. 【Reading Tips】 - **Skim the setuid/setgid details if you're already comfortable with Linux permissions** (Early): The `ping` and `sudo` examples are illustrative but not essential; focus on the capability drop pattern, which is the modern approach. - **Deep-read the cgroups chapter if you manage Kubernetes or Docker** (Early): The systemd driver hierarchy and `cgroup.subtree_control` mechanics are directly relevant to resource limits in production clusters. - **Hands-on is mandatory for the namespaces chapter** (Middle): The examples require a Linux VM with Docker (not Docker for Mac/Windows, which runs in a VM). Follow along with `unshare` and `lsns` to internalize how namespaces actually behave. - **Expect rough edges in this early release** (Throughout): The table of contents is not final, chapter numbers shift (Chapter 3 is labeled as Chapter 4), and several chapters are unavailable. Don't treat this as a complete reference yet. - **Take away the mental model, not the commands** (Overall): The book's real value is teaching you to reason about container security from the kernel up—so you can evaluate new vulnerabilities and mitigations on your own. 【Coverage Limits】 This guide covers the available early-release chapters (Linux fundamentals, cgroups, and namespaces). The book's later chapters on images, network security, TLS, secrets, runtime protection, and OWASP Top 10 are listed but not yet available in the source material.