Skip to main content
Ensuring a secure container runtime on each compute node is vital for any production-grade Kubernetes cluster. While Docker was the historical default, Kubernetes now natively supports containerd and CRI-O—runtimes designed for tighter integration and stronger security.
The image illustrates a cluster of nodes, each containing a Docker container, under the topic "Container Runtime Security."

​
Why Migrate from Docker?

Docker’s early releases suffered from a critical vulnerability that allowed containers to execute with root privileges on the host. Modern container runtimes mitigate this risk by adhering to the Container Runtime Interface (CRI).
The image illustrates a concept of container runtime security, showing a Docker container linked to a computer with a security alert, highlighting that early Docker versions allowed containers to run with root access on the host.

​
Common Container Runtime Vulnerabilities

Several high-profile CVEs have underscored the need for a secure runtime:
VulnerabilityImpact
Dirty COWLinux kernel flaw allowing unauthorized root access
runc container breakoutOverwriting the runc binary to gain host-level privileges
Docker container escapeAccessing sensitive host files from within a container
containerd denial of serviceForcing a host DoS via containerd resource exhaustion
CRI-O container escapesBreaking out of CRI-O sandbox to the host
The image is a table listing various container vulnerabilities, including their names, CVE IDs, affected systems, descriptions, and links for more information.
For a complete list of CVEs and mitigation steps, refer to your runtime’s security advisories.

​
1. Regular Updates and Patching

Keeping containerd, CRI-O or Docker packages up to date is a straightforward way to close known security gaps.
The image is a slide emphasizing the importance of regularly updating and patching container runtimes, specifically mentioning "containerd."
sudo apt-get update
sudo apt-get install containerd
Always consult the official Kubernetes container runtimes guide for platform-specific instructions.

​
2. Least-Privilege Execution

Avoid running containers as root. Assign non-root UIDs/GIDs to limit blast radius: 
apiVersion: v1
kind: Pod
metadata:
  name: least-privilege-pod
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
  containers:
    - name: app
      image: my-app-image
Failing to specify runAsUser can expose your host to privilege escalation if a container is compromised.

​
3. Enforce a Read-Only Filesystem

Prevent on-disk tampering by mounting the root filesystem as read-only: 
apiVersion: v1
kind: Pod
metadata:
  name: readonly-pod
spec:
  containers:
    - name: app
      image: my-app-image
      securityContext:
        readOnlyRootFilesystem: true

​
4. Resource Limits

Define CPU and memory limits to protect the node from denial-of-service attacks: 
apiVersion: v1
kind: Pod
metadata:
  name: resource-limits-pod
spec:
  containers:
    - name: app
      image: my-app-image
      resources:
        limits:
          memory: "512Mi"
          cpu: "1"

​
5. Mandatory Access Control (SELinux & AppArmor)

​
SELinux

apiVersion: v1
kind: Pod
metadata:
  name: selinux-demo
spec:
  containers:
    - name: nginx
      image: nginx
      securityContext:
        seLinuxOptions:
          user: "system_u"
          role: "system_r"
          type: "spc_t"
          level: "s0:c123,c456"

​
AppArmor

apiVersion: v1
kind: Pod
metadata:
  name: apparmor-demo
  annotations:
    container.apparmor.security.beta.Kubernetes.io/app: localhost/my-apparmor-profile
spec:
  containers:
    - name: app
      image: my-app-image

​
6. Transition to containerd or CRI-O

Docker support is deprecated in newer Kubernetes releases. Migrate to containerd or CRI-O for enhanced security, performance, and forward compatibility.
The image is about transitioning to supported container runtimes, featuring logos for "containerd" and "cri-o" with a whale graphic.
Update your node bootstrapping scripts or configuration management to use the CRI socket (/run/containerd/containerd.sock or /var/run/crio/crio.sock).

​
7. Monitoring, Logging & Auditing

Centralize logs and metrics to detect runtime anomalies:
  • Fluentd, Logstash, Elasticsearch for log aggregation
  • Prometheus & Grafana for metrics
  • Kubernetes Audit Logs for API event tracking
The image is a summary slide with two points: transitioning to supported runtimes like containerd or CRI-O, and implementing monitoring and logging for runtime behavior detection.

​
References

Watch Video