Posts

Showing posts with the label Containers

Container Image Scanning: Finding Vulnerabilities Before They Ship

A container image is an operating system distribution, a language runtime, a set of libraries, and your application, all frozen into one artifact. Scanning it means answering a question that spans every one of those layers: what known vulnerabilities are inside this thing we are about to run in production, and which of them actually matter. Two different inventories in one artifact Image scanners have to handle two package worlds at once. The operating system layer is enumerated from the distribution's package database — the same metadata the package manager uses. Matching those against distribution security advisories is reliable, provided the scanner understands backported patches. Distribution maintainers routinely fix a vulnerability without changing the upstream version number, so a naive version comparison reports flaws that were patched weeks ago. The application layer is enumerated from language-specific manifests and lock files. This is ordinary software compositio...

The Sidecar Pattern: Inspecting Container Traffic Without Changing the App

A sidecar is a second container running alongside the application container in the same pod, sharing its network namespace and often its storage. Because they share the network stack, the sidecar sees every packet the application sends and receives — without the application knowing it exists or a single line of its code changing. Why the pattern exists Containerized workloads still need logging, metrics, encryption in transit, authentication between services, retries, and traffic policy. Building all of that into every application means implementing it repeatedly in every language the organization uses, updating it everywhere when it changes, and depending on every team getting it right. The sidecar moves those concerns out of the application and into infrastructure. One implementation, injected automatically, applied uniformly. That separation is the argument, and it is the same reasoning that moved TLS termination to load balancers a generation earlier. What a sidecar typi...

Containers Explained: Images, Layers, and How They Differ From VMs

A container packages an application with its dependencies and runs it as an isolated process on a shared kernel. That last part — shared kernel — is the single most important fact about containers, because everything about their speed, their density and their security limits follows from it. What provides the isolation Containers are not a virtualization technology. They are ordinary processes with kernel features applied to restrict what they can see and use. Namespaces control visibility. A process in its own PID namespace sees only its own processes and believes it is process 1. A network namespace gives it its own interfaces and routing table. Mount, user, UTS and IPC namespaces do the equivalent for filesystems, user identity, hostname and interprocess communication. The process is not hidden from the host — the host sees it as a normal process — it simply cannot see out. Control groups limit consumption: CPU, memory, disk and network bandwidth. With...