Episode 45 · Module 10 · Infrastructure

Docker Security and Container Hardening

19 May 2026 · 8:57 · Security for Legal SaaS

8:57 8:57

Welcome to Module 10. For the next several episodes, we shift from application-level security to the infrastructure your application runs on — the containers, pipelines, dependencies, configuration, and cloud services that make up the deployment environment. A perfectly secure application deployed on poorly configured infrastructure is still vulnerable. We start with containers. --- A container is a lightweight, portable package that bundles your application with everything it needs to run — the code, the runtime, the libraries, the configuration files.

Today’s Lesson

Security for Legal SaaS — Episode 45: Docker Security and Container Hardening

Module 10 — Infrastructure and Deployment

What Is a Container, and Why Should You Care?

A container is a lightweight, portable package that bundles your application with everything it needs to run — the code, the runtime, the libraries, the configuration files. Think of it as a sealed shipping container for software: everything required is packed inside, isolated from whatever else is running on the same server. Docker is the most widely used container platform, though the underlying technology is built on Linux kernel features — namespaces for isolation and cgroups for resource limits.

Containers solve a real problem for legal SaaS teams. "It works on my machine" becomes irrelevant when the container is identical everywhere — development, testing, production. Your contract review tool runs the same way on a developer's laptop and on your production servers.

But containers are not virtual machines. They share the host operating system's kernel. This means a vulnerability in the kernel can affect every container on the host. NIST SP 800-190, the Application Container Security Guide ¹, identifies this shared kernel as the fundamental security consideration: "Containers provide less isolation than virtual machines since they share the host OS kernel."

Critical mindset: A container is not a security boundary. But a well-configured container is a useful speed bump — it limits what an attacker can do if they compromise your application. The goal is defence in depth (layering multiple independent controls, as we covered in Episode 4), not relying on any single layer.

Base Image Selection — Your Foundation Matters

Every container starts from a base image — a starting template that includes the operating system and core libraries. The most common mistake is using `ubuntu:latest` or `node:latest` as your base.

The problems:

`latest` is a moving target. Today's `latest` is different from last month's. Your build is not reproducible.
Full OS images include hundreds of packages you don't need. Each package is an additional attack surface — software that could contain vulnerabilities.
Unpinned images cannot be audited. You cannot prove what was in the image at deployment time.

The CIS Docker Benchmark ² — a set of security configuration guidelines published by the Center for Internet Security — recommends:

Practice	Why
Use minimal base images (`alpine`, `distroless`, `chainguard`)	Fewer packages = smaller attack surface
Pin images by digest, not tag	`node:20-alpine@sha256:abc123...` is immutable; `node:20-alpine` can change
Rebuild regularly	Even pinned images accumulate vulnerabilities over time
Scan before deployment	Catch known CVEs (Common Vulnerabilities and Exposures — standardised vulnerability identifiers) before they reach production

For a legal SaaS platform, the difference is stark. A full `node:20` image contains over 900 packages. A `node:20-alpine` image contains around 30. Every eliminated package is one fewer thing that can go wrong.

Running as Non-Root — The Single Most Important Change

By default, processes inside a Docker container run as root — the most privileged user on a Linux system. If an attacker exploits a vulnerability in your application and escapes the container, they inherit root privileges on the host. Game over.

Docker security hardening guides ³ consistently rank running as non-root as the single most impactful security improvement:

dockerfile

# In your Dockerfile
RUN addgroup --system appgroup && adduser --system appuser --ingroup appgroup
USER appuser

The `USER` instruction switches the container's runtime user to a non-privileged account. If an attacker escapes the container, they land as an unprivileged user — still bad, but dramatically less catastrophic than root.

NIST SP 800-190 ¹ explicitly recommends: "Organizations should prohibit containers from running as root whenever possible."

Read-Only Filesystems, Dropped Capabilities, and Seccomp

Beyond running as non-root, three additional hardening layers significantly reduce what a compromised container can do:

Read-Only Filesystem

Mount the container's filesystem as read-only. If an attacker gains code execution inside the container, they cannot write malicious files, modify binaries, or plant persistence mechanisms.

bash

docker run --read-only --tmpfs /tmp myapp

The `--tmpfs /tmp` flag provides a writable temporary directory in memory for applications that need it, while keeping the rest of the filesystem immutable.

Dropped Capabilities

Linux capabilities are fine-grained permissions that break root's all-or-nothing power into individual privileges. By default, Docker grants containers a set of capabilities that most applications never need. The CIS Docker Benchmark ² recommends dropping all capabilities and adding back only what your application requires:

bash

docker run --cap-drop=ALL --cap-add=NET_BIND_SERVICE myapp

This container can bind to privileged ports (below 1024) but cannot do anything else that requires elevated privileges — no raw network access, no kernel module loading, no changing file ownership.

Seccomp Profiles

Seccomp (Secure Computing Mode) restricts which system calls — low-level requests to the operating system kernel — a container can make. Docker's default seccomp profile ⁴ blocks approximately 44 of the 300+ available system calls, including dangerous ones like `reboot`, `mount`, and `clock_settime`. For higher security, create a custom profile that allows only the specific system calls your application uses.

Layered defence: Non-root user + read-only filesystem + dropped capabilities + seccomp profile = four independent barriers. An attacker who breaches one still faces three more. This is defence in depth applied to container configuration.

Secrets in Containers — Never Bake, Always Inject

Secrets — API keys, database passwords, encryption keys — must never be baked into container images. An image is a static artifact. Anyone with access to the image (your container registry, your CI/CD pipeline logs, your developer's laptop) can extract every secret embedded in it.

GitGuardian's research ⁵ found that container images and CI/CD configuration files are among the primary vectors for secret exposure, with millions of secrets discovered in public repositories annually.

The correct approach:

Method	How It Works	Security Level
Environment variables	Injected at runtime via orchestrator (Kubernetes Secrets, Docker Compose)	Baseline — visible in process listings
Mounted secrets	Files mounted into the container at runtime from a secrets manager	Better — not visible in process listings
Vault integration	Application fetches secrets from HashiCorp Vault (introduced in Episode 15) at startup	Best — secrets are short-lived, rotated, audited

For legal SaaS platforms handling privileged client data, Vault integration is the recommended approach. Secrets are never stored on disk, are automatically rotated, and every access is logged.

Container Scanning — Catching Vulnerabilities Before Deployment

Container images accumulate vulnerabilities. A base image that was clean last month may have three new critical CVEs today. Scanning tools analyse your images against vulnerability databases and report known issues before they reach production.

Docker's own security scanning ⁶ and third-party tools like Trivy, Grype, and Snyk Container check every layer of your image against the National Vulnerability Database and other sources. The CIS Docker Benchmark ² recommends scanning images both in your CI/CD pipeline (before they're published to a registry) and continuously in your registry (because new vulnerabilities are discovered after deployment).

A practical scanning policy for legal SaaS:

Block critical and high CVEs — no image with a known critical vulnerability reaches production
Set fix deadlines for medium CVEs — 30 days to patch or document an exception
Rebuild base images weekly — pick up security patches automatically
Scan running containers — detect vulnerabilities discovered after deployment

Aqua Security's CIS Docker Benchmark guide ⁷ notes that many organizations scan images during build but forget to rescan running containers — leaving a window where newly discovered vulnerabilities go undetected.

Docker Bench for Security — Auditing Your Configuration

Docker Bench for Security ⁸ is an open-source script that audits your Docker installation against the CIS Docker Benchmark. It checks over 100 configuration items including:

Host configuration (kernel parameters, audit rules)
Docker daemon configuration (TLS, logging, user namespaces)
Container runtime settings (capabilities, read-only root, seccomp)
Image and build file best practices

Run it regularly. Treat failures as security bugs. For a legal SaaS platform where data protection obligations apply — ABA Model Rule 1.6(c), GDPR Article 32's requirement for "appropriate technical measures," SOC 2 infrastructure controls — a clean Docker Bench report is evidence of due diligence.

Key takeaway: Containers are not inherently secure. They are as secure as you configure them. Minimal base images, non-root users, read-only filesystems, dropped capabilities, seccomp profiles, runtime secret injection, and continuous scanning — together, these transform a container from a convenient packaging format into a meaningful security layer. Skip any one of them, and you've left a door open.

What's Next

Next episode, we turn to the pipeline that builds and deploys those containers — CI/CD pipeline security. Your CI/CD system has production credentials and runs arbitrary code. It is the most powerful system you own. We'll talk about how to treat it that way.

Sources & references

Alice: Welcome back to Security for Legal SaaS. I'm Alice.

Dan: And I'm Dan. Episode 45 — Docker security and container hardening. We're starting a new module today — Module 10, Infrastructure and Deployment. Alice, containers are everywhere in modern software. But I suspect most of our audience hasn't thought much about what they actually are.

Alice: Let's fix that. A container is like a sealed shipping container for your software. You pack everything your application needs to run inside it — the code, the libraries, the configuration — and it runs the same way everywhere. On a developer's laptop, on a test server, in production. That consistency is why containers won through Docker. Your legal SaaS platform — whether it's a contract review tool or a case management system — gets packaged into one or more containers, and those containers get deployed to your servers.

Dan: Right. And that sounds great from a reliability perspective. What's the security concern?

Alice: The concern is that containers are not virtual machines. A virtual machine has its own entire operating system — fully isolated from the host. A container shares the host's operating system kernel. That means a vulnerability in the kernel can affect every container running on that host. NIST's container security guide — SP 800-190 — puts it directly: containers provide less isolation than virtual machines. A container is not a security boundary.

Dan: Mm. So what is it, then?

Alice: A useful speed bump. A well-configured container limits what an attacker can do if they compromise your application. It's not the wall — it's one layer in your defence in depth strategy, which we covered in Episode 4. The key word is "well-configured." An out-of-the-box Docker container with default settings is convenience-optimised, not security-optimised. You have to actively harden it.

Dan: Okay. Where do you start?

Alice: Base images. Every container starts from a base image — a template that includes the operating system and core libraries. The most common mistake is using a full operating system image like the standard Node.js image. It contains over 900 packages. Nine hundred pieces of software, most of which your application never uses. Every one of those is something that could contain a vulnerability. Switch to a minimal image — Alpine Linux-based images have around 30 packages. That's 870 fewer things that can go wrong.

Dan: Yeah, that's a dramatic difference. What about the version? I see a lot of tutorials using things like "node colon latest."

Alice: <sigh> The "latest" tag is a moving target. Today's "latest" is different from last month's. Your build is not reproducible — you cannot prove what was in that image when you deployed it. The fix is to pin by digest. That's a cryptographic hash of the image contents — like the SHA-256 fingerprints we've talked about before. A digest never changes. If you deploy with a pinned digest, you know exactly what's in that container, and you can prove it to an auditor six months later.

Dan: Mm-hmm. Okay, base image sorted. What's next?

Alice: Running as non-root. This is the single most impactful security change you can make. By default, processes inside a Docker container run as root — the most powerful user on a Linux system. If an attacker exploits a vulnerability in your application and manages to escape the container, they inherit root privileges on the host. They own the server. The fix is two lines in your Dockerfile — create an unprivileged user and switch to it. Now if the attacker escapes, they land as a nobody user. Still bad, but dramatically less catastrophic.

Dan: Right. That's the principle of least privilege from Episode 8 — give the process only the permissions it actually needs.

Alice: Exactly. And you can go further with three more hardening layers. First — read-only filesystems. Mount the container's filesystem so nothing can be written to it. An attacker who gains code execution can't plant malicious files, can't modify binaries, can't install tools. You provide a small writable temporary directory in memory for logs and temp files, but everything else is locked.

Dan: Mm. What's the second layer?

Alice: Dropped capabilities. Linux breaks root's all-or-nothing power into individual capabilities — like binding to low-numbered ports, or loading kernel modules, or changing file ownership. Docker gives containers a default set, but most applications need almost none of them. The CIS Docker Benchmark — that's the industry-standard security configuration guide from the Center for Internet Security — recommends dropping all capabilities and adding back only the specific ones your application requires. Most web applications need zero special capabilities.

Dan: And the third?

Alice: Seccomp profiles. Seccomp — Secure Computing Mode — restricts which system calls a container can make. System calls are low-level requests to the operating system — "open this file," "create a network connection," "allocate memory." Docker's default profile blocks about 44 dangerous system calls out of 300-plus available, things like reboot and mount. For higher security, you create a custom profile that allows only the specific calls your application uses. Everything else is denied.

Dan: Hmm. So you're stacking these — non-root, read-only filesystem, dropped capabilities, seccomp. Each one independent.

Alice: Four independent barriers. An attacker who gets past one still faces three more. That's defence in depth applied to container configuration.

Dan: Makes sense. Let me ask about secrets — database passwords, API keys. Where do those live in a containerised world?

Alice: Never in the image. This is a hard rule. A container image is a static file. Anyone who gets access to it — through your container registry, your CI/CD logs, a developer's laptop — can extract every secret embedded in it. Secrets must be injected at runtime. The simplest approach is environment variables — your orchestrator passes them in when the container starts. Better is mounting secrets as files from a secrets manager. Best is having the application fetch secrets from a tool like HashiCorp Vault — which we covered in Episode 15 — at startup. With Vault, secrets are short-lived, automatically rotated, and every access is logged.

Dan: Mm. And scanning — how do you know if your container image has vulnerabilities?

Alice: You scan it. Tools like Trivy, Grype, and Snyk Container analyse every layer of your image against vulnerability databases. The important thing is when you scan. Most teams scan during the build process — which is good. But they forget to rescan running containers. A base image that was clean last month might have three new critical vulnerabilities today. You need continuous scanning. Block critical vulnerabilities from reaching production, set deadlines for fixing medium ones, and rebuild your base images at least weekly to pick up security patches.

Dan: Right. And there's an automated audit tool for all of this?

Alice: Docker Bench for Security. It's an open-source script that checks your Docker installation against the CIS Benchmark — over 100 configuration items. Host settings, daemon configuration, container runtime settings, image best practices. Run it regularly. Treat failures as security bugs. For a legal SaaS platform where you have professional obligations around data protection — ABA rules, SOC 2, potentially GDPR — a clean Docker Bench report is evidence that you're doing your due diligence on infrastructure security.

Dan: Mm-hmm. Good overview. Next episode — CI/CD pipeline security. The system that builds and deploys all of this.

Alice: Your CI/CD pipeline has production credentials and runs arbitrary code. It's the most powerful system you own. Next episode, we'll talk about treating it that way. Until then, I'm Alice.

Dan: And I'm Dan.

Alice: Security for Legal SaaS is a series written with AI assistance. Alice and Dan are AI-generated voices — no professional advice here, just education.

Security for Legal SaaS is a series written with AI assistance. Alice and Dan are AI-generated voices — no professional advice here, just education.