Why Container Security Starts Where the Container Starts: The Kernel
A Docker container feels like a lightweight virtual machine, but that intuition is exactly what gets teams breached. There is no small operating system running inside a container. When you type docker run, the daemon turns your image into an ordinary Linux process on the host, wraps it in a handful of kernel features, and lets it go. The container and every other workload on that host share the same kernel. That single design decision — the thing that makes containers start in milliseconds and pack densely onto a node — is also the reason a misconfigured container can reach far beyond its intended boundary.
Adoption has made this a board-level problem rather than a lab curiosity. The vast majority of enterprises now run containerised workloads in production, and industry surveys of cloud-native operators consistently report that most organisations have experienced a container or Kubernetes security incident, with misconfiguration — not exotic zero-days — cited as the leading root cause. In regulated sectors such as banking, telecom, and critical national infrastructure, where Aydahwa Enterprise has delivered security architecture work, a single over-privileged container can undermine an otherwise sound control environment and put ISO 27001, PCI-DSS, and NIST CSF alignment at risk.
This article walks through what actually happens when a container runs, why each of those mechanisms is a security control in disguise, and how to harden the full lifecycle — image, build, registry, runtime, and host — using named tools and the CIS Docker Benchmark. The goal is not fear; it is a defensible, auditable container platform.
How a Container Becomes a Process — and Why Every Step Is a Control
Understanding the attack surface requires understanding the mechanics. A container is a normal process that the kernel has been told to treat as isolated. Four Linux primitives do the work, and each one maps to a security decision you are making whether you realise it or not.
Namespaces: the illusion of a private machine
Namespaces give a process its own view of the system. The PID namespace makes the container believe it is running as process 1 with no visibility of other processes; the network namespace gives it its own interfaces and routing table; the mount namespace gives it its own filesystem tree; and the UTS, IPC, and user namespaces isolate hostname, inter-process communication, and user IDs respectively. The critical gap most teams miss is the user namespace. By default it is often not enabled, which means UID 0 inside the container is UID 0 on the host. If an attacker escapes the process boundary, they are already root on the node. Enabling user-namespace remapping so that container root maps to an unprivileged host user is one of the highest-value hardening steps available.
Control groups (cgroups): the limits that stop a noisy neighbour becoming a denial of service
Cgroups cap how much CPU, memory, and I/O a container can consume. Left unbounded, a single compromised or buggy container can starve every other workload on the host — a self-inflicted denial-of-service condition. Resource limits are therefore an availability control, and availability is one third of the confidentiality-integrity-availability triad that every ISO 27001 and NIST CSF programme is built to protect.
Capabilities: root is not all-or-nothing
Traditional Linux splits the power of root into roughly forty discrete capabilities — the right to bind low ports, to change file ownership, to load kernel modules, to alter network configuration, and so on. Docker grants a default set to every container, and most applications need almost none of them. Dropping all capabilities and adding back only what the workload genuinely requires shrinks the blast radius of a compromise dramatically. A web service that only needs to bind a port should not carry the capability to manipulate the host firewall.
Union filesystems and the copy-on-write image
A container image is a stack of read-only layers with a thin writable layer on top. This is efficient, but it also means secrets, credentials, or private keys baked into any layer during the build remain recoverable from the image forever, even if a later layer appears to delete them. Image hygiene is not cosmetic; it is a data-leakage control.
The Container Attack Surface, Layer by Layer
Because a container touches so many stages between a developer's laptop and a production node, the attack surface is best understood as a pipeline rather than a single perimeter. Each stage below is a place where a control must exist.
- The base image and dependencies — vulnerable libraries, outdated OS packages, and untrusted upstream images pulled from public registries.
- The build process — secrets leaked into layers, malicious build steps, and a lack of provenance about what actually went into the artefact.
- The registry — unsigned images, tag mutability (where latest silently changes underneath you), and weak access control.
- The runtime configuration — privileged mode, host mounts, exposed Docker sockets, and excessive capabilities.
- The host and kernel — a shared kernel means a kernel vulnerability is a shared risk across every container on the node.
- The orchestration layer — Kubernetes RBAC, network policies, and admission control that govern what containers may run at all.
Securing the Image: You Cannot Harden What You Have Not Scanned
The most common container weakness is also the most preventable: shipping an image full of known-vulnerable packages. Defence here rests on three practices.
Start minimal. Every binary you do not ship is a vulnerability you do not have to patch. Distroless images, Alpine, or a scratch base for compiled languages remove shells, package managers, and utilities that attackers rely on after a foothold. A container with no shell is a container an attacker cannot easily pivot from.
Scan continuously. Image scanning should run in the CI pipeline on every build and again continuously in the registry, because new vulnerabilities are disclosed against images that have not changed. Open-source scanners such as Trivy, Grype, and Clair, alongside commercial platforms, detect known CVEs in OS packages and application dependencies. The gate should fail the build on critical and high findings rather than merely reporting them.
Know what is inside. A Software Bill of Materials (SBOM), generated with tools such as Syft or Trivy in SPDX or CycloneDX format, records every component in the image. When the next widespread library vulnerability lands, an SBOM turns a week of frantic investigation into a database query. This capability is increasingly an explicit expectation in supply-chain security guidance.
Supply Chain and Build Integrity
Knowing an image is clean is worthless if you cannot prove the image you scanned is the image you deployed. Image signing with Cosign and the Sigstore project cryptographically binds an image to its producer, and admission controllers can then refuse to run anything unsigned. Frameworks such as SLSA (Supply-chain Levels for Software Artifacts) and the guidance in NIST SP 800-190, the Application Container Security Guide, formalise these expectations. Build secrets — registry credentials, cloud keys, signing material — must be injected through build-time secret mounts, never copied into a layer, and never passed as build arguments that persist in image metadata.
Runtime Hardening: The Controls That Contain a Compromise
Even a perfectly scanned image can be run insecurely. Runtime configuration is where most real-world container escapes originate, and the fixes are well understood, low-cost, and directly testable. The table below summarises the controls that matter most, ordered by impact.
| Control | Insecure default / risk | Hardened configuration |
|---|---|---|
| Run as non-root | Containers run as UID 0 by default | Set a dedicated non-root user in the image and enforce it at runtime |
| Drop capabilities | A broad default capability set is granted | Drop ALL, add back only what is required (e.g. NET_BIND_SERVICE) |
| Read-only root filesystem | Writable filesystem allows tampering and persistence | Mount the root filesystem read-only; use explicit writable volumes |
| No new privileges | Processes can escalate via setuid binaries | Set the no-new-privileges flag |
| Seccomp profile | Full syscall access widens the kernel attack surface | Apply the default or a tailored seccomp profile to restrict syscalls |
| MAC (AppArmor / SELinux) | No mandatory access control confinement | Attach an AppArmor or SELinux profile per workload |
| Never privileged | --privileged grants near-total host access | Prohibit privileged containers via policy and admission control |
| Protect the Docker socket | Mounting /var/run/docker.sock hands over root-equivalent control | Never mount the socket into a container; broker access instead |
| User-namespace remapping | Container root equals host root | Enable userns-remap so container root maps to an unprivileged host UID |
None of these controls requires a commercial product. Every one is expressible in a Dockerfile, a Compose file, or a Kubernetes SecurityContext, which means they can be enforced through code review and admission policy rather than hope.
Mapping to the CIS Docker Benchmark
The Center for Internet Security publishes the CIS Docker Benchmark, a consensus-driven configuration standard that turns the principles above into checkable line items. Aydahwa Enterprise applies CIS Benchmarks as a baseline across engagements, because they translate directly into audit evidence. The benchmark is organised into host, daemon, image, and runtime sections; a representative subset is shown below.
| CIS area | Example recommendation | Why it matters |
|---|---|---|
| Host configuration | Audit the Docker daemon, files, and directories | Creates a tamper-evident record for incident response |
| Docker daemon | Enable user-namespace remapping; do not enable insecure registries | Reduces the impact of an escape and prevents unverified pulls |
| Daemon files | Restrict ownership and permissions on daemon config and socket | Prevents privilege escalation via daemon control |
| Container images | Create a non-root user; add a HEALTHCHECK; scan for vulnerabilities | Limits blast radius and enables self-healing |
| Container runtime | Restrict capabilities; do not use privileged mode; set read-only root FS | Contains a compromised process to the container |
Tools such as Docker Bench for Security automate a first pass against the benchmark, and the output becomes a concrete remediation backlog. In a regulated environment, that same output is compliance evidence that maps to ISO 27001 Annex A controls for secure configuration and to PCI-DSS requirements for hardening system components.
Runtime Detection: Assume Something Will Get Through
Hardening reduces the probability of compromise; it does not eliminate it. A mature container platform therefore also watches running containers for behaviour that should never occur — a shell spawning inside a production web container, an unexpected outbound connection, a write to a sensitive path, or an attempt to load a kernel module. Falco, a CNCF runtime-security project, uses kernel-level instrumentation to detect exactly these events and generate alerts. Those alerts should flow into the same SIEM and Security Operations Centre that handle the rest of the estate, so that container telemetry is correlated with identity, network, and endpoint signals rather than living in a silo. This is where container security stops being a DevOps concern and becomes part of the organisation's broader detection and response capability.
How Container Security Maps to Compliance
For enterprises in banking, telecom, and critical national infrastructure, container controls are not optional engineering nicety — they are the substance of several regulatory requirements. Non-root execution, capability restriction, and read-only filesystems evidence the secure-configuration and least-privilege expectations in ISO 27001 and NIST CSF. Image scanning and vulnerability management support PCI-DSS requirements to identify and rank vulnerabilities and to protect systems against malware. Logging of daemon activity and runtime alerts supports both the monitoring requirements of PCI-DSS and the Detect function of the NIST Cybersecurity Framework. Building the control set once, as code, means the same work satisfies multiple frameworks simultaneously.
Production Container Security Checklist
- Build from minimal or distroless base images and pin versions by digest, not by mutable tags.
- Scan every image in CI and continuously in the registry; fail builds on critical and high CVEs.
- Generate and retain an SBOM for every artefact.
- Sign images with Cosign and reject unsigned images via admission control.
- Run every container as a dedicated non-root user.
- Drop all Linux capabilities and add back only what the workload needs.
- Mount root filesystems read-only and declare explicit writable volumes.
- Apply seccomp and AppArmor or SELinux profiles to every workload.
- Set no-new-privileges and prohibit privileged containers by policy.
- Enable user-namespace remapping so container root is not host root.
- Never mount the Docker socket into a container.
- Enforce CPU, memory, and I/O limits on every container.
- Benchmark hosts and daemons against the CIS Docker Benchmark and remediate findings.
- Deploy runtime detection (Falco) and route alerts into your SIEM/SOC.
- Patch the host kernel promptly — it is shared by every container on the node.
How Aydahwa Enterprise Can Help
Container security is not a single tool you buy; it is an architecture decision that spans your pipeline, your platform, and your operations. Aydahwa Enterprise designs and hardens containerised environments end to end, grounded in recognised standards — ISO 27001, PCI-DSS, SOC 2, the NIST Cybersecurity Framework, and CIS Benchmarks — and in hands-on delivery for banking, telecom, and critical-national-infrastructure clients. Our team holds credentials including the Microsoft Cybersecurity Architect Expert certification, and we translate the controls in this article into enforceable pipeline gates, admission policies, and audit-ready evidence rather than a document that sits on a shelf.
If you are running containers in production, a good first step is to understand where you stand today. Our cybersecurity services cover container and cloud-native hardening, threat detection, and SOC integration, while our cloud security and migration services secure the platforms those workloads run on. You can benchmark your current maturity with our free cyber security self-assessment and work through our cybersecurity readiness checklist. For day-to-day platform operations and patching discipline, our managed IT support keeps the underlying hosts current. When you are ready to design or review a container platform against ISO 27001, PCI-DSS, and CIS Benchmarks, contact our team to scope an assessment.
Containers changed how quickly software ships. Treating their security as a first-class, code-enforced discipline is what lets you keep that speed without inheriting the risk.
