Actionable walkthroughs on containerization, multi-stage builds, microservices orchestration, container networking, and DevOps pipelines.
A Docker image is not a single artifact. It is a stack of layers: a base operating system with its package manager, a language runtime with its dependency tree, and the application code itself. Each layer carries its own inventory of packages, and any one of them can contain a known vulnerability. Scanning exists to…
A container is a process, not a virtual machine. It runs directly on the host kernel, and the kernel does not distinguish between a process running in a container and a process running on the host. The only thing separating them is a set of kernel features: namespaces, cgroups, and capabilities. Capabilities are the most…
Capabilities restrict which operations a process may perform. Seccomp restricts which system calls a process may make. Linux Security Modules go one layer deeper: they restrict which resources a process may touch, even when the operation is permitted and the syscall is allowed. AppArmor does this by matching file paths and network rules. SELinux does…
A container shares the host kernel. Every action the containerized process takes, from opening a file to sending a network packet, is a system call into that kernel. The kernel’s syscall interface is the largest attack surface in the container model: roughly 300 calls, each a potential entry point for a kernel vulnerability. Seccomp (secure…
A container runs as root inside its own namespace by default. Without user namespace remapping, that root is the same root that owns the host. A process that escapes the container, or a kernel vulnerability that lets a process break out of the namespace, lands on the host as root. User namespace remapping (userns-remap) changes…
A container image tag is a mutable label. An attacker who compromises a registry can repoint myapp:latest to a malicious image, and every system that trusts the tag pulls the attacker’s code. Image signing closes this gap by attaching a cryptographic signature to the image digest. The signature proves who published the image and that…
Running Docker as root has always been a security trade-off. The daemon runs with full privileges, and a container escape can escalate to host root. Rootless mode changes that. The daemon and every container it runs execute as an unprivileged user, using user namespaces and subordinate UID mappings to create the illusion of root inside…
Environment variables are the default way to pass configuration to containers, and for non-sensitive values they are fine. For secrets they are a liability. A password passed with -e is visible in docker inspect, inherited by every child process, and often printed in logs when something goes wrong. Docker’s secret management exists to close that…
A container image built on an x86_64 laptop runs on an x86_64 server. It does not run on an Apple Silicon Mac, an AWS Graviton instance, or a Raspberry Pi. The binary inside the image is compiled for one CPU architecture, and the kernel rejects it on any other. Multi-platform builds solve this by producing…
A multi-arch image is not a single binary that runs everywhere. It is a manifest list, an OCI image index that points to separate per-architecture images . When a client pulls a tag, the container runtime reads the list, selects the entry matching the host’s architecture, and pulls only that image. The result is one…