Container runtime security is the practice of hardening the container while it’s running: read-only filesystems, dropped Linux capabilities, seccomp profiles, and runtime detection for anomalous behavior. The right setup balances security with operational sanity.
Table of contents
- The threat model
- The hardening checklist
- A hardened Dockerfile
- A hardened Kubernetes pod
- Runtime detection
- The defense-in-depth model
- The Kubernetes-specific guidance
- FAQ
The threat model
What can go wrong in a running container:
- A process inside the container escapes. Uses a kernel exploit to break out of the container’s namespace and access the host.
- A process inside the container does something unexpected. Reads a file it shouldn’t, opens a network connection to an unexpected host, executes a binary it shouldn’t.
- A supply chain attack. The image contains a malicious package; the malicious code runs inside the container.
Container runtime security addresses all three.
The hardening checklist
The seven things to harden in a running container:
- Read-only root filesystem. The container cannot write to its own filesystem. Use tmpfs for ephemeral storage.
- Drop all Linux capabilities, add only what’s needed. The default Docker capability set is broader than most apps need.
- Apply a seccomp profile. Restrict which syscalls the container can make. The default seccomp profile is broad; a custom profile is narrower.
- Run as a non-root user. The container’s main process should not run as root.
- No privileged mode. Never run with
--privileged; it disables most of the isolation. - Resource limits. Set memory and CPU limits so a runaway process doesn’t take down the host.
- Network policies. In Kubernetes, restrict the container’s network access with NetworkPolicies.
A hardened Dockerfile
The right shape for a production Dockerfile:
FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
USER node
EXPOSE 3000
CMD ["node", "server.js"]Key choices: node:20-alpine (small, fewer packages to attack), USER node (not root), npm ci --only=production (no dev dependencies in the image).
A hardened Kubernetes pod
The right shape for a Kubernetes pod:
apiVersion: v1
kind: Pod
spec:
containers:
- name: app
image: myapp:1.0
securityContext:
readOnlyRootFilesystem: true
runAsNonRoot: true
runAsUser: 1000
capabilities:
drop:
- ALL
resources:
limits:
memory: 256Mi
cpu: 500m
volumeMounts:
- name: tmp
mountPath: /tmp
volumes:
- name: tmp
emptyDir: {}Read-only root filesystem, non-root user, all capabilities dropped, memory and CPU limits, tmpfs for /tmp.
Runtime detection
The right tools for detecting runtime anomalies:
- Falco. Open-source runtime detection. Watches syscalls and flags anomalies.
- Tracee. Aqua Security’s eBPF-based runtime detection.
- Tetragon. Cilium’s eBPF-based runtime detection.
- Sysdig Secure. Commercial runtime detection.
The team that runs Falco in the cluster has visibility into what containers are actually doing at the syscall level. The team that doesn’t has logs that show network connections but not what’s inside them.
The defense-in-depth model
The right way to think about container security is defense in depth. Multiple layers, each catching a different class of issue:
Layer 1: Image. Trusted base images, signed images, minimal packages. Catches supply chain attacks at the source.
Layer 2: Build. Reproducible builds, SBOM generation, vulnerability scanning. Catches CVEs at build time.
Layer 3: Registry. Signed images only, vulnerability scanning on push, access control. Catches untrusted images.
Layer 4: Deploy. Admission control, policy enforcement, signed image verification. Catches policy violations at deploy time.
Layer 5: Runtime. Anomaly detection, network policies, seccomp profiles. Catches unexpected behavior at run time.
The team that has all five layers has comprehensive container security. The team that has only one layer has a single point of failure.
The Kubernetes-specific guidance
For Kubernetes deployments:
Pod Security Standards. The right baseline. restricted is the most secure; use it by default. baseline is for apps that can’t meet restricted. privileged should never be used in production.
Network Policies. Default deny, allow by exception. Every namespace should have a default-deny policy.
RBAC. Least-privilege roles. Service accounts with minimal permissions. No cluster-admin for application service accounts.
Resource Quotas. Prevent a single namespace from consuming all cluster resources.
OPA / Kyverno. Policy as code. Define policies once, enforce everywhere.
The team that implements Pod Security Standards + Network Policies + RBAC has the Kubernetes security baseline. The team that adds OPA / Kyverno on top has policy enforcement as code.
FAQ
What is container runtime security?
The practice of hardening a running container: read-only filesystem, dropped capabilities, seccomp profiles, non-root user, resource limits. Plus runtime detection for anomalies.
Should I run containers as root?
No. Always set USER in the Dockerfile or runAsUser in the Kubernetes manifest to a non-root user. The team that runs as root has a larger attack surface.
What’s a seccomp profile?
A list of allowed syscalls. The default Docker seccomp profile allows ~300 syscalls; a custom profile can allow fewer. The team that uses a custom profile reduces the kernel attack surface.
What runtime detection tool should I use?
Falco for the open-source path. Sysdig Secure or Aqua for the commercial path. The team that picks Falco and configures it well has the same detection capability as the commercial tools, with more operational overhead.
What’s the best base image for security?
Distroless images (Google’s distroless/*) are the smallest and have the fewest packages. Alpine is small but has more packages. Debian-slim is the standard. The team that uses distroless for production has the smallest attack surface.
Do I need a service mesh for security?
No. A service mesh (Istio, Linkerd) adds mTLS and policy enforcement, but it’s a heavy dependency. The team that doesn’t need service mesh capabilities (a small app, simple services) uses Network Policies instead.
Can I run untrusted workloads in Kubernetes?
Yes, with the right isolation. Use a separate cluster, gVisor or Kata Containers for sandboxing, strict Network Policies, and resource quotas. The team that runs untrusted workloads has the right isolation.
If you are sizing the infrastructure for the kind of project this post covers, the RunxBuild hosting calculator is the right place to model the line items. The compute, the memory, the storage, the bandwidth, the database - each one is a separate number, and the team’s mental model for the platform is the sum of those numbers. The RunxBuild dashboard is where the team sees the actual usage in one place.
Useful related references: