Skip to content
All posts
Container Security

How to Protect Docker Containers from Runtime Attacks

7 min read

Docker containers are not inherently secure. They share the host kernel, they can consume all available memory, they can restart in infinite loops, and in the worst case, they can escape to the host. Most Docker security advice focuses on image scanning and build-time best practices. That covers half the problem. The other half is runtime.

This guide covers the runtime risks of Docker containers, how to detect anomalies while containers are running, and how to automatically pause compromised containers before they cause damage.

Container runtime risks

  • OOM kills - a container consuming more memory than its limit gets killed by the kernel. If it happens repeatedly, either the container has a memory leak or it is being exploited for resource exhaustion.
  • Rapid restarts - a container that crashes and restarts in a loop can indicate a persistent exploit attempt or a crash-based denial of service.
  • Container escape - the most severe risk. An attacker inside a container exploits a kernel vulnerability or misconfiguration to gain access to the host system.
  • Cryptomining - compromised containers are frequently used to mine cryptocurrency, consuming CPU and driving up cloud costs.
  • Data exfiltration - a container with access to sensitive volumes can exfiltrate data to an external server.

How Inner Warden monitors Docker

Inner Warden's sensor includes a docker collector that connects to the Docker daemon's event stream. It watches for container lifecycle events: start, stop, die, oom, and restart. The docker_anomaly detector (part of the execution_guard) analyzes these events for suspicious patterns.

Data sourceDocker daemon event stream
Events trackedstart, stop, die, oom, restart
Anomaly detectionRapid restarts, OOM frequency, unexpected events
ResponsePause container (TTL-based)
RecoveryAutomatic unpause after TTL

Automatic response: pause and unpause

When a container anomaly is detected, the agent can execute the block-container skill. This pauses the container using docker pause, which freezes all processes inside the container without killing it. The container's state and memory are preserved.

After the configured TTL, the container is automatically unpaused. This gives you time to investigate without permanently disrupting the service. If the container was legitimately misbehaving (memory leak, bug), the unpause lets it resume. If it was compromised, you have time to remediate.

detectContainer "api-server" OOM-killed 4 times in 120 seconds
decideAI confidence 0.85 | rapid OOM pattern suggests resource exhaustion attack
pauseContainer "api-server" paused | TTL 30 minutes
unpauseContainer automatically unpaused after TTL

Pair with Falco for deeper container security

Inner Warden's Docker collector monitors lifecycle events. For deeper visibility into what happens inside the container (syscalls, file access, network connections), pair it with Falco. Falco watches at the kernel level and can detect container escapes, unexpected shells, and sensitive file reads.

Inner Warden integrates with both, combining Docker lifecycle events and Falco syscall alerts into a single pipeline.

Set it up

Docker container monitoring works automatically when Inner Warden detects a running Docker daemon. Install and the sensor starts watching container events:

Install
curl -fsSL https://innerwarden.com/install | sudo bash
Enable container blocking
innerwarden enable block-ip

The Docker collector auto-discovers the Docker socket. Verify it is active:

Verify
innerwarden status

What to do next