A Container Is a Linux Process, Not a Virtual Machine
Most people who come to containers from a VM background carry over the wrong mental model, and that mistake is where most container breaches start. There is no small operating system running inside a container. Run docker run and the daemon turns your image into an ordinary Linux process on the host, applies a handful of kernel isolation features to it, and lets it run. That's the whole trick — namespaces, cgroups, capabilities, and a layered filesystem, nothing more exotic than that. The container shares the host kernel with every other workload on that machine, and a shared kernel means a misconfigured container can reach further than its owner ever intended.
This is no longer a niche concern for platform teams. Most enterprises now run containerised workloads in production, and cloud-native operators consistently report that misconfiguration, not exotic zero-days, is the leading cause of container and Kubernetes incidents. In banking, telecom, and critical-national-infrastructure environments — sectors where Aydahwa Enterprise has delivered security architecture work — a single over-privileged container can quietly undermine an otherwise sound control environment and put ISO 27001, PCI-DSS, or NIST CSF alignment at risk during an audit.
What follows covers what actually happens when a container starts, why each isolation mechanism is a security control whether you treat it as one or not, and how to harden the full lifecycle — image, build, registry, runtime, and host — using named tools and the CIS Docker Benchmark.
Four Kernel Primitives Do All the Work
A container is a normal process the kernel has been told to treat as isolated. Everything about container security traces back to how well four Linux primitives are configured.
Namespaces give each process its own view of the system
The PID namespace makes the container believe it is running as process 1, with no visibility into anything else on the host. The network namespace hands it its own interfaces and routing table. The mount namespace gives it its own filesystem tree. UTS, IPC, and user namespaces isolate hostname, inter-process communication, and user IDs. The gap most teams miss is the user namespace — by default it's usually not enabled, which means UID 0 inside the container is UID 0 on the host. Escape the process boundary without user-namespace remapping in place, and you're already root on the node. Enabling remapping so container root maps to an unprivileged host user is one of the higher-value hardening steps available, and one of the more frequently skipped.
Cgroups keep one bad container from taking the whole host down
Control groups cap how much CPU, memory, and I/O a container can consume. Leave that unbounded and a single compromised or simply buggy container can starve every other workload on the same host — a self-inflicted denial-of-service condition that has nothing to do with an attacker. Resource limits are an availability control, full stop, and availability is a third of the confidentiality-integrity-availability triad every ISO 27001 or NIST CSF programme is built around.
Capabilities split root into roughly forty separate privileges
Traditional Linux root is all-or-nothing. Capabilities break that power into discrete rights — binding low ports, changing file ownership, loading kernel modules, altering network configuration, and so on. Docker hands every container a default set, and most applications need almost none of it. Drop everything and add back only what the workload genuinely requires, and the blast radius of a compromise shrinks considerably. A web service that only needs to bind a port has no business holding the capability to touch the host firewall.
The image is a stack of layers, and nothing in a layer ever really disappears
A container image is read-only layers with a thin writable layer on top. It's an efficient design, but it has one consequence people learn the hard way: secrets, credentials, or private keys baked into any layer during the build stay recoverable from the image forever, even after a later layer appears to delete them. Image hygiene isn't cosmetic — it's a data-leakage control, and one worth checking before you assume a "cleanup" step actually cleaned anything up.
Where the Attack Surface Actually Lives
A container passes through enough stages between a developer's laptop and a production node that treating it as a single perimeter misses most of the real risk. Think of it as a pipeline, with a control required at each stage:
- The base image and dependencies — vulnerable libraries, outdated OS packages, untrusted upstream images pulled from public registries.
- The build process — secrets leaked into layers, malicious build steps, no real provenance for what went into the artefact.
- The registry — unsigned images, tag mutability (where latest quietly changes underneath you), weak access control.
- Runtime configuration — privileged mode, host mounts, exposed Docker sockets, excessive capabilities.
- The host and kernel — shared kernel, shared risk: a kernel vulnerability affects every container on the node.
- The orchestration layer — Kubernetes RBAC, network policies, and admission control that decide what's allowed to run at all.
You Cannot Harden an Image You Haven't Scanned
The most common container weakness is also the easiest to prevent: shipping an image loaded with known-vulnerable packages. Three practices cover most of it.
Start minimal. Every binary you don't ship is a vulnerability you don't have to patch. Distroless images, Alpine, or a scratch base for compiled languages strip out the shells, package managers, and utilities attackers rely on once they get a foothold. A container with no shell is a much harder container to pivot from.
Scan continuously, not just once. Image scanning belongs in the CI pipeline on every build, and again continuously in the registry, because new CVEs get disclosed against images that haven't changed at all. Trivy, Grype, and Clair — along with the commercial platforms — catch known vulnerabilities in OS packages and application dependencies. Set the gate to fail the build on critical and high findings; a scanner that only reports is a scanner nobody reads.
Know what's actually inside. A Software Bill of Materials, generated with Syft or Trivy in SPDX or CycloneDX format, records every component in the image. When the next widely-disclosed library vulnerability lands — and it will — an SBOM turns what used to be a week of frantic grep-ing through repos into a database query.
Proving the Image You Scanned Is the Image You Deployed
A clean scan is worth nothing if you can't prove the image that passed it is the same one running in production. Image signing with Cosign and Sigstore cryptographically binds an image to its producer, and admission controllers can then refuse to run anything unsigned. SLSA (Supply-chain Levels for Software Artifacts) and NIST SP 800-190, the Application Container Security Guide, formalise what this should look like in practice. Build secrets — registry credentials, cloud keys, signing material — belong in build-time secret mounts. They should never be copied into a layer, and never passed as build arguments, which persist in image metadata long after anyone remembers they're there.
Runtime Configuration Is Where Most Real Escapes Happen
Even a perfectly scanned image can still be run insecurely, and runtime misconfiguration is where most real-world container escapes originate. The fixes are well understood, cheap, and directly testable — there's no excuse for skipping them. The table below orders the controls that matter most by impact.
ControlInsecure default / riskHardened 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 this requires a commercial product. Every row is expressible in a Dockerfile, a Compose file, or a Kubernetes SecurityContext — which means it belongs in code review and admission policy, not in a wiki page nobody checks before deploying.
The CIS Docker Benchmark Turns This Into a Checklist
The Center for Internet Security publishes the CIS Docker Benchmark, a consensus configuration standard that converts everything above into line items you can actually audit against. We use CIS Benchmarks as a baseline across engagements because they translate directly into evidence an auditor will accept. The benchmark covers host, daemon, image, and runtime sections; a representative slice looks like this.
CIS areaExample recommendationWhy 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
Docker Bench for Security automates a first pass against the benchmark, and its output becomes a concrete remediation backlog rather than a theoretical one. In a regulated environment, that same output doubles as compliance evidence mapping to ISO 27001 Annex A secure-configuration controls and PCI-DSS system-hardening requirements.
Assume Something Gets Through Anyway
Hardening lowers the odds of compromise. It doesn't remove them. A container platform worth trusting also watches running containers for behaviour that should never happen — a shell spawning inside a production web container, an unexpected outbound connection, a write to a sensitive path, an attempt to load a kernel module. Falco, a CNCF runtime-security project, uses kernel-level instrumentation to catch exactly this and raise alerts. Route those alerts into the same SIEM and Security Operations Centre handling the rest of the estate. Container telemetry sitting in its own silo, disconnected from identity, network, and endpoint signals, doesn't help anyone during an actual incident — and it's the single most common gap we see when reviewing a client's detection coverage.
Where This Fits Into Compliance
For banking, telecom, and critical-national-infrastructure organisations, container controls aren't an engineering nicety layered on top of compliance — they're the substance behind several regulatory requirements. Non-root execution, capability restriction, and read-only filesystems evidence the secure-configuration and least-privilege expectations baked into 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. Daemon logging and runtime alerts support both PCI-DSS monitoring requirements and the Detect function of the NIST Cybersecurity Framework. Build the control set once, as code, and the same work satisfies multiple frameworks at the same time instead of three separate documentation exercises.
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's shared by every container on the node.
How Aydahwa Enterprise Can Help
Container security isn't a product you buy once — it's an architecture decision that runs through your pipeline, your platform, and your day-to-day operations. Aydahwa Enterprise designs and hardens containerised environments end to end, grounded in ISO 27001, PCI-DSS, SOC 2, NIST CSF, and CIS Benchmarks, with hands-on delivery for banking, telecom, and critical-national-infrastructure clients. Our credentials include the Microsoft Cybersecurity Architect Expert certification, and we turn the controls in this article into enforceable pipeline gates, admission policies, and audit-ready evidence rather than a document that sits unread on a shared drive.
If you're running containers in production, the useful first step is knowing where you actually stand. Our cybersecurity services cover container and cloud-native hardening, threat detection, and SOC integration, and our cloud security and migration services secure the platforms those workloads run on. Benchmark your current maturity with our free cyber security self-assessment or work through our cybersecurity readiness checklist. For ongoing platform operations and patching discipline, our managed IT support keeps the underlying hosts current. When you're ready to design or review a container platform against ISO 27001, PCI-DSS, and CIS Benchmarks, contact our team to scope an assessment.
