EKS Moved To containerd, GuardDuty’s Runtime Alert Stayed Behind. Here’s Why That Matters.

Why this matters especially for startups relying on AWS GuardDuty?

Why I’m Writing This

Amazon EKS has moved to from 1.24 and later. Kubernetes removed dockershim in v1.24. Docker as a runtime is legacy in this context.

However, Amazon GuardDuty runtime monitoring detects deprecated Docker socket (removal of dockershim — 01 JUN 2023) access but does not detect containerd socket mount, which is the actual container runtime used in EKS 1.30+.

Amazon GuardDuty EKS Runtime Monitoring, however, currently documents and ships a dedicated detection for Docker socket access: PrivilegeEscalation:Runtime/DockerSocketAccessed.

This creates a security monitoring blind spot where container escape attacks targeting /run/containerd/containerd.sock go undetected while generating false sense of confidence through Docker socket alerts for GuardDuty which is offering of AWS ( as per 2024 re-invent).

For small team relying on cloud native detection this needs to be explicitly taken care.

This blog sumarises HackerOne report showing that:

• GuardDuty correctly detects docker.sock access.
• GuardDuty does not raise an equivalent runtime finding for containerd.sock access.
• AWS has classified this as a feature request, not a vulnerability.

This blog is about making sure security engineers and teams make informed decision and also focus on robust alerting based on deprecated components

Quick Background: EKS, containerd, and GuardDuty

• Kubernetes removed dockershim in v1.24. Managed services, including EKS, moved to CRI-compliant runtimes such as containerd.
• Modern Amazon EKS control planes and nodes for current Kubernetes versions use containerd as the container runtime.
• GuardDuty EKS Runtime Monitoring uses an agent to observe process, file, and network activity for suspicious patterns in your workloads.
• Among its runtime finding types is a specific check for Docker socket access: PrivilegeEscalation:Runtime/DockerSocketAccessed when a process talks to /var/run/docker.sock.

Affected Versions (Currently supported EKS):

• Amazon EKS: Kubernetes 1.30+ (containerd runtime).
• Amazon GuardDuty runtime monitoring feature.
• All regions where EKS 1.30+ is available.

PoC Summary

Test Setup

• Environment:
• Standard AWS account.
• EKS clusters on Kubernetes 1.28.
• EKS cluster on Kubernetes 1.32.
• GuardDuty EKS Runtime Monitoring enabled via the recommended integration (EKS / GuardDuty console or add-on flow).

• Waited until GuardDuty showed full runtime coverage for the cluster (EKS Runtime Monitoring coverage status: 1/1).

Compare the detection in GuardDuty with dockerd & containerd

Docker Socket Pod (Baseline: Expected Detection)

• Deploy the dockerd & containerd pods

• A test pod simulating Docker socket access:

apiVersion: v1
kind: Pod
metadata:
  name: dockerd-pod
  namespace: gd-test
  labels:
    app: dockerd
spec:
  containers:
  - name: dockerd
    image: docker:latest
    command: ["/bin/sh"]
    args:
      - "-c"
      - |
        echo "Starting Docker socket access simulation..."
        echo "This will trigger GuardDuty PrivilegeEscalation:Runtime/DockerSocketAccessed"
        while true; do
           echo "$(date): Attempting Docker socket access..."
           docker ps || echo "Docker ps attempt logged"
           sleep 45
        done
    volumeMounts:
      - mountPath: "/var/run/docker.sock"
        name: docker-socket
        readOnly: false
  volumes:
    - name: docker-socket
      hostPath:
        path: "/var/run/docker.sock"
  restartPolicy: Always

Observed behavior:

• GuardDuty generated PrivilegeEscalation:Runtime/DockerSocketAccessed findings.
• Confirms that agent deployment is correct.
• Runtime event pipeline is working.
• Docker socket rule behaves as documented.

Verify GuardDuty Docker Socket Detection:

Expected Result:

• Alerts triggered for docker.sock for PrivilegeEscalation:Runtime/DockerSocketAccessed.

Access Containerd Socket (Undetected Gap)

• A second pod targeting containerd.sock:

apiVersion: v1
kind: Pod
metadata:
  name: containerd-pod
  namespace: gd-test
  labels:
    app: containerd
spec:
  volumes:
    - name: host-containerd
      hostPath:
        path: /run/containerd/containerd.sock
  containers:
    - name: containerd
      image: ubuntu:latest
      command: ["/bin/bash"]
      args:
        - "-c"
        - |
          apt-get update && apt-get install -y wget curl ctr
          while true; do
            echo "$(date): Accessing containerd socket..."
            ctr --address /run/containerd/containerd.sock containers list || echo "ctr call failed"
            sleep 30
          done
      volumeMounts:
        - name: host-containerd
          mountPath: /run/containerd/containerd.sock
  restartPolicy: Always

Observed behavior:

• No dedicated GuardDuty runtime findings for:
• containerd socket mount.
• containerd socket access.
• ctr usage against /run/containerd/containerd.sock.

Reproduced consistently on both 1.28 and 1.32 clusters once runtime monitoring was healthy.

Compare Results

• Docker socket: Specific runtime alert for docker.sock.
• Containerd socket: No runtime socket access alerts (only generic alerts may come if manual exec performed or any sensitive mount done).

• Also check that there is a specific alert for docker socker however no alert for containerd.

AWS Response

• Lack of containerd-specific socket detection is not classified as a GuardDuty security vulnerability.
• It is treated as a feature request / unsupported feature.

Why This Matters for Security Teams

If you run EKS 1.24+ (containerd-based) and enable GuardDuty EKS Runtime Monitoring:

• Dockershim centric detections can mislead
• Containerd is the runtime for all latest EKS. Docker socket findings do not reflect your real attack surface.
• Seeing strong Docker coverage may create the impression that “runtime escape via socket is covered” when the active runtime path is different.
• Access to /run/containerd/containerd.sock is as sensitive as /var/run/docker.sock in the Docker era.
• Without explicit findings here, a key privilege-escalation path is less visible by default.

False sense of security for small teams.

• Cloud native managed detections around deprecated technology can unintentionally give stakeholders more confidence than the telemetry justifies for modern setups.

Compliance and audit clarity

• For SOC, PCI, ISO, etc., you must be precise:
• What GuardDuty monitors.
• What it does not.
• What compensating controls you operate for gaps.

What You Should Do Now

Make the Coverage Explicit Internally

• Document this internally so no one is confused:
• State your EKS runtime (containerd).
• List relevant GuardDuty EKS Runtime findings you rely on.
• Note that Docker socket findings do not automatically imply containerd socket coverage.

Example internal note:

“GuardDuty EKS Runtime Monitoring is enabled for all production clusters. Current documented runtime findings include Docker socket access detection. Our clusters use containerd; there is no documented equivalent finding for /run/containerd/containerd.sock at the time of this review. We rely on admission policies and additional runtime tooling to cover this gap.”

Actionable Mitigation Steps:

Since GuardDuty yet to cover this, you must implement complementary controls to detect containerd socket access:

Do not depend only on detection also prevent risky mounts and block them.

• Other Security Tools: Deploy a supplementary Container Runtime Security (CRS) solution (e.g., Falco, Tetragon or commercial tools) that specifically monitors the host’s file system access and process execution events for containerd.sock access attempts or the execution of ctr/crictl within a container.
  - File access to /run/containerd/containerd.sock.
  - Suspicious ctr / crictl executions inside pods.
  - Example Falco-style rule:

- rule: Containerd_Socket_Access
  desc: Detect access to containerd socket from containers
  condition: (fd.name=/run/containerd/containerd.sock) and container
  output: "Containerd socket access (user=%user.name command=%proc.cmdline container=%container.id)"
  priority: WARNING

• Admission Controllers: Use a Kubernetes Admission Controller (like Open Policy Agent Gatekeeper or Kyverno) to strictly block any Pod deployment that attempts to mount the host path /run/containerd/containerd.sock. This is a preventive control that addresses the root cause of the risk.
• Adjust to your policy engine and patterns.
• The goal is simple: no pod should mount Docker or containerd sockets unless you explicitly allow it.
• Example Kyverno (opensource) policy snippet :

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-container-runtime-sockets
spec:
  validationFailureAction: enforce
  rules:
    - name: block-runtime-sockets
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        message: "Mounting container runtime sockets is not allowed."
        pattern:
          spec:
            =(volumes):
              - X(hostPath):
                  X(path): "!*/var/run/docker.sock"
              - X(hostPath):
                  X(path): "!/run/containerd/containerd.sock"

• EKS Audit Logs: Enhance your EKS Audit Log monitoring in CloudWatch/Security Hub to look for suspicious Pod or DaemonSet creation events that include the mounting of the host’s /run/containerd/containerd.sock.

Feed these alerts into the same pipeline as GuardDuty so that SOC sees one coherent story.

Continuously Re-Verify

• Before major audits or architecture reviews:
• Re-check official GuardDuty documentation and release notes.
• Confirm whether containerd-specific findings have been added.
• Update your internal docs and this threat model accordingly.

Conclusion

This case is not about calling GuardDuty “insecure”.

• GuardDuty EKS Runtime Monitoring is still a valuable signal source. No other CSP has such great managed service for quic detections including leaked credentials and bitcoin mining alert, etc.

Use this information to make an informed decision about how much confidence to place in any managed detection service, including GuardDuty, for EKS runtime security.

Contact & Further Discussion

If you want to discuss this GuardDuty + EKS runtime gap, validate it in your own environment, or compare notes on compensating controls, you can reach me here:

• Website: https://peachycloudsecurity.com/
• YouTube (Cloud & Kubernetes Security Labs): https://www.youtube.com/@PeachyCloudSecurity
• OWASP EKS Goat (Hands-on EKS Security Labs): https://github.com/owasp/eks-goat

References:

1. AWS EKS Dockershim Removal: https://docs.aws.amazon.com/eks/latest/userguide/dockershim-deprecation.html
2. Kubernetes Dockershim Deprecation: https://kubernetes.io/blog/2020/12/02/dockershim-faq/
3. GuardDuty Runtime Monitoring: https://docs.aws.amazon.com/guardduty/latest/ug/runtime-monitoring.html
4. EKS Containerd Migration: https://aws.amazon.com/blogs/containers/all-you-need-to-know-about-moving-to-containerd-on-amazon-eks/
5. https://hackerone.com/bugs?subject=user&report_id=31XXXX7