Containers · Learn

What is container security?

Containers share the host kernel, so a weak configuration can let an attacker break out of a container and onto the machine running it. Container security is the practice of stopping that. Here is what it covers and where it goes wrong.

Containers · LearnCloud Penetration Testing
TL;DR

Container security is the practice of keeping containers isolated from each other and from the host they run on. Unlike a virtual machine, a container shares the host kernel, so the boundary is enforced by Linux features (namespaces, cgroups, capabilities, seccomp) rather than a hypervisor. When those are misconfigured, an attacker who lands in one container can escape to the host or the wider cluster. It spans the image, the runtime, and the orchestrator (Kubernetes).

By John Dill, Red Team Lead, SecureLayer7Updated

What container security is

A container packages an application with its dependencies and runs it as an isolated process on a shared host. The isolation is not a separate machine, it is the host kernel enforcing boundaries with namespaces (what the process can see), cgroups (what it can use), capabilities (what privileged actions it can take), and seccomp/AppArmor (which syscalls it can make).

Container security is making sure those boundaries hold, so a compromised container stays contained.

Why it is different from a VM

A virtual machine has its own kernel and is separated by a hypervisor, a hard boundary. A container shares the host kernel with every other container, so the separation is softer and depends entirely on configuration.

That is why a single risky flag (privileged mode, a mounted host path, a shared namespace) can collapse the boundary in a way that has no equivalent on a properly configured VM. See container vs virtual machine.

The three layers attackers target

Container risk lives in three places:

How a pentest tests it

A container and Kubernetes penetration test starts inside a low-privilege pod and tries to break out exactly as an attacker would: escape to the node, read other workloads, reach the cluster control plane, and pivot into the cloud account. The deliverable is the real escape path with reproducible evidence and a fix for each step.

References

  1. [1]MITRE ATT&CK: Containers Matrix(MITRE)
  2. [2]NIST SP 800-190 Application Container Security Guide(NIST)
Related terms

Common questions

Container security, asked often

Want your containers and clusters tested for these paths?

Scope an engagement

Find the container escape paths before an attacker does.

We test your Docker hosts and Kubernetes clusters the way a real intruder would, from a compromised pod to the node and the rest of the cluster, then hand your team reproducible evidence and a fix for every step. Free re-test included.

See cloud penetration testing30-min scoping call, fixed-price proposal in 48 hours.