reveal // what a container is

a container is not a tiny virtual machine

people say "container" and their brain autocorrects to "lightweight vm." that mental model gets a lot of people in trouble. a vm has its own kernel, its own hardware emulation, its own everything. a container is just a process on your host, wrapped in some linux namespaces and cgroups so it thinks it's alone. same kernel as the host. that difference is the whole security story, so let's actually look at it.

the command

docker run -d --name web nginx

docker run tells docker to create and start a container. -d means detached, it runs in the background instead of tying up your terminal. --name web gives the container a human readable name instead of some random string you'll never remember. nginx is the image, docker pulls it from docker hub if you don't already have it locally, then boots a process from it.

that's it. no virtual disk, no virtual nic, no bios. it's a process. run ps aux on your host while that container is up and you'll see the nginx process sitting right there next to your other processes, just isolated from seeing them and they from seeing it.

why "shared kernel" matters for defense

a vm hypervisor is a hard boundary. escaping a vm to touch the host kernel is rare and expensive for an attacker. a container has no hypervisor. it's isolated by namespaces (pid, network, mount, etc) and restricted by cgroups (cpu, memory limits), but it's talking to the exact same kernel your host runs. if there's a kernel exploit, or the container is run with too many privileges, that isolation can be walked right through.

this is why "it's just a container, it's sandboxed" is not a security plan. it's a convenience feature that happens to add some isolation, not a security boundary designed from the ground up like a vm's.

check what you're actually running

most container compromises come from configuration, not some exotic kernel zero day. check these on your own boxes:

docker inspect web | grep -i privileged

if a container is running with --privileged, it basically has root level access to the host's devices and kernel features. that flag should almost never appear in production. audit for it.

docker ps --format "table {{.Names}}\t{{.Ports}}"

this shows you what ports are actually exposed to the world. a shocking number of people run containers with ports mapped to 0.0.0.0 without realizing it's reachable from outside their machine, not just localhost. check your port bindings.

docker inspect web --format '{{.HostConfig.CapAdd}} {{.HostConfig.CapDrop}}'

containers get a default set of linux capabilities. if you've added capabilities like CAP_SYS_ADMIN without a real reason, you've widened the blast radius if that container gets popped.

the image itself is an attack surface

pulling nginx off docker hub is convenient, but you're trusting whoever built that image, plus every dependency baked into it. run this to see what's actually in there:

docker scan web

or use trivy, grype, or whatever scanner you like, the point is to actually check your images for known cves instead of assuming "official image" means "safe image." official just means somebody at docker hub verified the publisher, not that the image is vulnerability free.

practical hardening you can do today

run containers as a non root user whenever the image supports it, using --user or a USER line in the dockerfile. drop capabilities you don't need with --cap-drop=ALL and add back only what's required. use --read-only for containers that don't need to write to their own filesystem. set resource limits with --memory and --cpus so one compromised container can't starve everything else on the host. and keep your host kernel patched, since that shared kernel is your actual security boundary, not the container wall.

the takeaway

a container gives you process isolation, not vm level isolation, and treating it like a vm is how misconfigurations turn into full host compromises. know what's running privileged, know what ports are actually exposed, scan your images, and drop the capabilities you don't need. the tech is great, the mental model people bring to it is usually the weak point.