Skip to main content
← Back to Insights
Infrastructure 9 min read

Container Security Basics: Protecting Your Docker Infrastructure

Learn docker security best practices for protecting your container infrastructure. Covers image scanning, non-root containers, network isolation, secrets management, and a container security checklist.

TI
Tom Isgren

Docker and containers have revolutionized how we deploy and manage applications. Package your app once, run it anywhere—sounds perfect. But here's what many teams discover too late: containers don't automatically mean secure.

The convenience that makes containers attractive can also create security blind spots. Let's walk through the essential security practices every team should implement.

Understanding Docker Security Fundamentals

Containers share the host operating system's kernel. Unlike virtual machines, they don't provide complete isolation. This architectural choice is what makes them lightweight and fast—but it also means a compromised container can potentially affect others on the same host.

The Shared Kernel Reality

Think of containers as apartments in a building. They have separate spaces (namespaces) and resource limits (cgroups), but they share the building's foundation and utilities. A problem with the foundation affects everyone.

This doesn't mean containers are insecure—it means you need to understand what you're protecting and from whom.

Image Security: Start Clean

Your container is only as secure as the image it's built from. This is where most security issues originate.

1

Use Official Base Images

Start with official images from Docker Hub or your platform's registry. Images like python:3.12-slim or node:20-alpine are maintained by the community and receive regular security updates.

2

Prefer Minimal Images

Alpine-based and slim images contain fewer packages, which means fewer potential vulnerabilities. A smaller attack surface is easier to defend. Choose alpine or distroless variants when possible.

3

Scan Images Regularly

Use tools like Trivy, Grype, or Docker Scout to scan images for known vulnerabilities. Integrate scanning into your CI/CD pipeline so issues are caught before deployment. Don't just scan once—vulnerabilities are discovered continuously.

4

Pin Specific Versions

Never use :latest in production. Pin to specific image digests or version tags. This ensures reproducible builds and prevents unexpected changes from breaking your security posture.

Runtime Security: Principle of Least Privilege

How you run containers matters as much as what's in them. Apply the principle of least privilege at every level.

Don't Run as Root

Create a non-root user in your Dockerfile and use the USER directive. If an attacker gains access, they won't have root privileges on your container.

Drop Capabilities

Linux capabilities let you grant specific powers without full root. Drop all capabilities with --cap-drop=ALL and add back only what you need.

Read-Only Filesystem

Use --read-only flag to make the container filesystem immutable. Mount specific writable volumes only where needed for logs or temp files.

Resource Limits

Set CPU and memory limits to prevent a single container from consuming all host resources. This mitigates denial-of-service risks from runaway processes.

Example: Secure Docker Run

docker run -d \
  --name myapp \
  --user 1000:1000 \
  --read-only \
  --cap-drop=ALL \
  --security-opt=no-new-privileges \
  --memory=512m \
  --cpus=0.5 \
  -v /app/data:/data:rw \
  myapp:1.2.3

Network Security: Isolate and Control

By default, Docker creates a bridge network where all containers can communicate. In production, you want explicit control over what can talk to what.

Create Isolated Networks

Create separate Docker networks for different application tiers. Your database container shouldn't be on the same network as your public-facing web server unless necessary. 

docker network create --driver bridge frontend
docker network create --driver bridge backend
docker network create --driver bridge database

Don't Expose Unnecessary Ports

Only expose ports that need external access. Internal services should communicate through Docker networks, not published ports. Use expose for documentation, -p only when needed.

Use a Reverse Proxy

Place a reverse proxy like Traefik or nginx in front of your containers. It handles TLS termination, provides a single entry point, and lets you control routing centrally. This also keeps your application containers from binding to host ports directly.

Secrets Management: Never Hardcode

Credentials in Dockerfiles or environment variables are one of the most common container security mistakes.

What NOT to Do

  • ✕ Hardcoding secrets in Dockerfile: ENV DB_PASSWORD=secret123
  • ✕ Passing secrets via command line: docker run -e API_KEY=xxx
  • ✕ Committing .env files to version control
  • ✕ Storing secrets in image layers (they persist even if deleted)

Better Approaches

  • ✓ Docker Secrets: Built-in for Swarm mode, mounts secrets as files in /run/secrets/
  • ✓ External secret managers: HashiCorp Vault, AWS Secrets Manager, or Bitwarden Secrets Manager
  • ✓ Environment files at runtime: Load from encrypted storage, not version control
  • ✓ Multi-stage builds: Build in one stage, copy only artifacts to final image (no build secrets)

Host Security: The Foundation

Your containers are only as secure as the host they run on. Don't neglect the underlying infrastructure.

→ Keep the host OS and Docker engine updated
→ Use a minimal host OS (Alpine, Flatcar, Bottlerocket)
→ Run Docker in rootless mode when possible
→ Enable audit logging for Docker daemon
→ Restrict access to Docker socket (it's root-equivalent)
→ Use AppArmor or SELinux profiles for additional isolation

Monitoring and Response

Security isn't set-and-forget. You need visibility into what's happening inside your containers.

Key Monitoring Practices

  • → Centralized logging: Ship container logs to a central system. Stdout/stderr should capture enough for debugging and security analysis.
  • → Runtime security tools: Tools like Falco can detect unexpected behavior—processes spawning shells, unexpected network connections, file modifications.
  • → Resource monitoring: Unusual CPU or memory spikes can indicate cryptomining or other compromise.
  • → Registry scanning: Continuously scan your image registry, not just during builds. New CVEs are discovered daily.

Container Security Checklist

☐ Using official, minimal base images
☐ Scanning images for vulnerabilities
☐ Running containers as non-root
☐ Dropping unnecessary capabilities
☐ Using read-only filesystems
☐ Setting resource limits
☐ Isolating networks appropriately
☐ Managing secrets securely
☐ Keeping host and Docker updated
☐ Monitoring container activity

Getting Started

Container security isn't about implementing everything at once. Start with the highest-impact items: scan your images, run as non-root, and manage secrets properly. Then layer in additional controls as your infrastructure matures.

The goal isn't perfect security—it's defense in depth. Multiple layers of protection mean that when (not if) one control fails, others are there to catch the threat.

Need help securing your container infrastructure? We specialize in building secure, self-hosted Docker environments with proper isolation, monitoring, and compliance controls. Get in touch →