Container Runtime Protection vs Host EDR: Deciding Whether Node EDR Is Enough for Kubernetes

Many organisations already run an EDR agent on every Linux server and assume that installing it on Kubernetes nodes covers their containers, then find that alerts name a process and a host but not the pod, image, namespace or service account the SOC needs to act. Container runtime protection and host EDR both watch processes, files and network connections on the same kernel, so the overlap is real and so is the budget question. The difference lies in context, in how each handles workloads that live for minutes, in what each can see of Kubernetes itself and in what a safe response looks like when one node runs fifty unrelated services. It is for security architects, platform owners and SOC leads deciding whether node EDR is enough or a container-aware layer is needed. How runtime sensors and rules work is covered in the Container Runtime Security Guide, and EDR fundamentals in the EDR Guide.

Key takeaways

• Same kernel, different questions. Host EDR asks "is this host compromised?"; container runtime protection asks "is this workload behaving unlike its image and its Kubernetes role?".
• Context decides triage speed. An alert without pod, namespace, image digest and service account sends analysts to the cluster to reconstruct it, often after the pod is gone.
• Escapes land on the node. A container escape (ATT&CK T1611) ends in host territory, where host EDR's persistence, memory and tamper coverage matters most, so container-only tooling is not a full answer either.
• Some platforms take the choice away. On serverless container platforms and some managed node types you cannot install your own host agent, so the provider's runtime service or a sidecar sensor is the only option.
• Response must fit the blast radius. Isolating a node stops every workload on it; killing a pod or scaling a deployment to zero contains one. Choose tools that can do the narrow action.

The short answer

Node EDR alone is enough for a narrow set of estates: a small number of long-lived clusters running internally built, low-sensitivity workloads, where the EDR product enriches its events with Kubernetes metadata and the SOC is comfortable pivoting to the cluster for the rest. For most production Kubernetes estates it is not enough on its own, because the questions that matter after an alert (which deployment, which image, which identity, is this drift from the image) are workload questions. NIST SP 800-190, the Application Container Security Guide, recommends container-aware runtime defence in its executive summary for this reason. The reverse is also true: container runtime protection that ignores the node leaves the kubelet, the container runtime, SSH access and host persistence uncovered. The usual end state is both, with deliberate division of labour, or one product that genuinely does both jobs.

Side by side

Threat model: what each sees

Attacker moves start from code execution in one pod (ATT&CK v20 Enterprise).

The TeamTNT worm illustrates why both views matter. It started containers through exposed Docker APIs, installed a miner and a rootkit, cleaned logs and copied AWS credential files from the host. The container-level steps tell you which workload and image were abused; the host-level steps (rootkit, log cleaning, credential files) are classic EDR territory. See the TeamTNT Worm 2020 analysis.

Container runtime protection in depth

Architecture in words

A sensor runs on each node, usually as a privileged DaemonSet, and collects kernel events (process execution, file access, network connections) through eBPF or a kernel module. A user-space component maps each event's cgroup or container ID to the container runtime and the Kubernetes API, attaching pod, namespace, labels, image and service account. Rules or models then compare behaviour with what the image and workload should do. Open source examples, listed alphabetically, are Falco, a rule engine whose modern eBPF probe is the default driver, and Tetragon, which runs policy as eBPF programs in the kernel and understands namespaces and pods so detection can be tied to individual workloads.

Cloud provider runtime services

The three major cloud providers each offer a managed container runtime service. Platforms are listed alphabetically; the order is not a ranking.

• Amazon GuardDuty Runtime Monitoring: a GuardDuty security agent observes process execution and command line arguments, file access and network connections on Amazon EKS, Amazon ECS on AWS Fargate and Amazon EC2. On EKS it is deployed as the aws-guardduty-agent add-on, and with automated configuration GuardDuty manages the agent on new clusters too; the GuardDutyManaged tag controls inclusion. Availability: AWS documents support for EKS clusters on EC2 instances and EKS Auto Mode; for EKS on Fargate and EKS Hybrid Nodes, check the current support list.
• Google Security Command Center Container Threat Detection: kernel-level instrumentation on GKE nodes, with a user-mode watcher DaemonSet forwarding events and container identifiers to a detector service. Detectors include Added Binary Executed and Added Library Loaded (both off by default), Container Escape and Malicious Python Executed; Bash and Python scripts are analysed for malicious code. Google notes that container information is best effort and that other security detection tools in the cluster can interfere with the service. Availability: Container-Optimized OS node images, Security Command Center Premium or Enterprise tier.
• Microsoft Defender for Containers: runtime threat protection at cluster, node and workload level, combining sensor-based coverage through the Defender sensor with agentless analysis of Kubernetes audit logs. Alerts are mapped to MITRE ATT&CK and can be investigated in Microsoft Defender XDR; examples include exposed dashboards and services, creation of high-privileged roles and sensitive mounts. The sensor's components include low-level and pod collectors, an anti-malware collector and an admission controller. Availability: alerts cover activity after the plan is enabled; see Microsoft's support matrix for runtime coverage by cloud and cluster type.

Failure modes

• Metadata gaps: enrichment is best effort; a pod that starts and dies quickly may produce events with a container ID and no pod name. Check how often your tool's alerts arrive without Kubernetes context.
• Node blind spots: tools that focus on containers may not alert on SSH logins to the node, host cron jobs or kubelet tampering.
• Drift detectors switched off: high-value detectors such as added binary execution are sometimes off by default or disabled because noisy build workloads trip them.
• Privileged sensor risk: the DaemonSet runs with high privileges on every node, so its image, service account and update path are part of your attack surface. See Securing the container runtime security and CWPP itself.

Host EDR on Kubernetes nodes in depth

Architecture in words

The EDR agent is installed into the node image or by configuration management and runs as a host service, collecting process, file, network and often memory telemetry for the whole operating system. Detections draw on fleet behaviour and threat intelligence; responses include host isolation and file quarantine. Container processes are ordinary Linux processes in their own namespaces and cgroups, so the agent sees them; whether it labels them with container and Kubernetes context depends on the product and its configuration.

Strengths that container tools often lack

• Whole-host coverage: kubelet, containerd or CRI-O, SSH sessions, systemd units, cron, kernel module loading and node credential files.
• Mature SOC workflow: the same console, playbooks and analysts as the rest of the server estate, and tamper protection designed for hostile hosts.
• Post-escape depth: once an attacker reaches the node, persistence and credential theft look like any compromised Linux server.
• Windows nodes: clusters with Windows node pools need Windows endpoint coverage that many container-focused sensors do not target.

Failure modes

• Host-level response on a shared node: network isolation of a node takes down every pod on it and may trigger cascading reschedules; analysts hesitate to use it, so containment is slow.
• Alerts without workload identity: analysts receive a process path and a container ID and must query the cluster to learn which deployment, team and service account are involved, sometimes after the pod has been replaced.
• Exclusions that blind containers: to reduce noise or performance impact, teams exclude container runtime paths or overlay filesystems, which removes exactly the activity attackers use. See the EDR Tuning and Exclusions Management Guide.
• Node images without the agent: autoscaled or managed node pools created from a base image that lacks the agent leave nodes uncovered for their whole, sometimes short, life.
• Sensor conflicts: two kernel-level sensors on one node can compete; at least one provider service warns that other detection tools can interfere, so test combinations before production.

Ephemeral workloads change the evidence problem

A pod that lives ten minutes takes its writable layer, its process tree and often its logs with it. Host EDR keeps process telemetry after the fact, but grouped by node, so reconstruction means joining EDR events with Kubernetes audit records and pod history. Container runtime tools key evidence to the workload, so the question "has this deployment ever spawned a shell?" can be answered across every pod that has run it. Either way, stream events to the SIEM in real time, retain Kubernetes audit logs beyond your detection delay, and prefer pausing or snapshotting a suspicious pod to deleting it. The Container and Kubernetes Forensics Guide covers acquisition.

Where identity fits

Most cluster compromises end in credential theft: the mounted service account token, cloud credentials from the instance metadata service or a workload identity, or secrets in environment variables. A useful runtime alert names the workload identity involved, so responders can revoke or rotate exactly what the workload could reach. Whichever tool you choose, test that its alerts carry the Kubernetes service account and, where the cloud provider maps it, the cloud role. See the Kubernetes Service Account Token Guide and the Cloud Workload Identity Guide.

Decision criteria

• Node EDR alone may be enough when: clusters are few and long-lived, workloads are internal and low sensitivity, the EDR product enriches events with pod and namespace, and Kubernetes audit logs already reach the SIEM with detections on exec and privileged pod creation.
• Add container runtime protection when: workloads are internet facing or multi-tenant, pods churn quickly, the SOC needs image and identity context to triage, or you want drift detection against image contents.
• Container runtime protection is the only option when: you run serverless containers or managed nodes where you cannot install a host agent. Use the provider's runtime service or a supported sidecar sensor.
• Keep host EDR as well when: nodes are accessible over SSH, you run self-managed node images, Windows node pools exist, or regulation requires endpoint protection on every server.
• Consider one product for both when: it demonstrably provides host coverage and Kubernetes context in the same alert. Validate with tests, not data sheets.
• Small organisations: start with the cloud provider's runtime service plus Kubernetes audit log detections, keep EDR on any self-managed nodes, and avoid running two kernel sensors you cannot tune.

Worked scenario: one estate, two answers

A company runs two Kubernetes estates. The first is three self-managed clusters on virtual machines running internal reporting jobs, with SSH access for the operations team. The second is a managed cluster service running a customer-facing API with autoscaled node pools and pods that live about fifteen minutes on average.

1. Internal clusters: host EDR is already on the VMs. The team confirms its events carry container ID and pod name, adds Kubernetes audit log detections for pods/exec, privileged pods and new ClusterRoleBindings, and decides node EDR is enough for now. It removes a broad exclusion on the container overlay filesystem that had been added for performance.
2. Customer-facing cluster: node pools are replaced weekly and pods churn constantly. The team enables the provider's runtime threat detection, turns on the added-binary detector for production namespaces (leaving CI namespaces out), and routes alerts with pod, image and service account to the SOC.
3. Node coverage: the managed node image allows a host agent, and the endpoint team keeps EDR on it for SSH and host persistence. Both sensors are tested together in a staging pool for overhead and conflicts before rollout.
4. Response: the playbook prefers pod-level actions (delete the pod, scale the deployment to zero, apply a quarantine network policy) and reserves node isolation for confirmed escapes, with cordon and drain first.
5. Test: a red team exercise runs a shell in a pod, downloads a binary and reads the service account token. The SOC times how long it takes to name the deployment, image and identity from each tool's alert.

How to implement

1. Measure the gap: trigger safe test events (an interactive shell in a test pod, a new binary in /tmp, a read of the token file) and record what each existing tool reports and with what context.
2. Decide division of labour: write down which tool owns container behaviour, which owns host behaviour and which owns the Kubernetes audit log, so alerts are not duplicated or orphaned.
3. Deploy in detect-only mode: roll out the container sensor to a staging node pool, then low-risk production namespaces, measuring CPU, memory and dropped events.
4. Tune per workload class: build and CI workloads, data jobs and long-lived services need different rules; suppress by workload, never by disabling a detector cluster-wide.
5. Enable response gradually: start with alerts, then automated pod deletion for high-confidence detections such as cryptominers, with an allow list of critical workloads that need human approval.
6. Roll back: keep sensor deployment in GitOps so removal is a revert, and keep host EDR running throughout so coverage never drops to zero.

The Container runtime security and CWPP rollout playbook covers procurement and rollout in more detail.

Detection and measurement

Feed both tools and the Kubernetes audit log into one place and correlate on container ID, pod and node. Watch for sensor heartbeat loss, DaemonSet changes in the sensor namespace, new privileged pods and hostPath mounts, and exec into production pods.

• Context completeness: percentage of runtime alerts that carry pod, namespace, image digest and service account (target above 95 percent).
• Node coverage: percentage of nodes running each required sensor, measured from the node inventory rather than the tool's own list.
• Time to workload: median minutes from alert to identifying the owning deployment and team.
• Containment scope: share of incidents contained with pod-level actions rather than node isolation.

Framework mapping

Common failure patterns

• Assuming the server agent covers containers: nobody checks whether alerts carry Kubernetes context until the first incident.
• Agent missing from autoscaled nodes: new node pools come from an image without the EDR agent, so coverage shrinks as the cluster scales.
• Overlay exclusions: EDR exclusions on container storage paths, added for performance, hide every container process write.
• Node isolation as the only lever: responders delay containment because isolating a node would take down production.
• Two sensors, no owner: duplicate alerts go to different teams and each assumes the other is handling them.
• Ignoring the audit log: neither tool ingests Kubernetes audit events, so exec, privileged pod creation and RBAC changes go unseen. See the Kubernetes Audit Log Detection Guide.

Practitioner checklist

• Run safe test events and record what context each tool's alert carries.
• Confirm every node pool image and managed node type has the sensors you rely on.
• Remove EDR exclusions on container runtime and overlay paths, or replace them with narrow ones.
• Send Kubernetes audit logs to the SIEM with detections for exec, privileged pods and RBAC changes.
• Turn on drift detection for production namespaces and tune it per workload class.
• Write a response playbook that prefers pod-level containment and reserves node isolation for escapes.
• Make sure alerts name the service account and cloud role so credentials can be revoked quickly.
• Protect the sensor DaemonSet: its namespace, service account, image source and update path.

Standards and references

• NIST: SP 800-190 Application Container Security Guide
• Amazon Web Services: GuardDuty Runtime Monitoring
• Amazon Web Services: How Runtime Monitoring works with Amazon EKS
• Google Cloud: Container Threat Detection overview
• Microsoft Learn: Overview of Defender for Containers
• Falco: Kernel events and drivers
• Tetragon: Overview

Related NHI Mgmt Group resources: Container Runtime Security Guide, EDR Guide, CWPP vs CSPM, CNAPP Guide, Kubernetes Cluster Compromise Playbook.