Runtime Crypto-Mining Alert on Shared EKS Nodes

I would not terminate immediately. Termination destroys memory, process trees, and local evidence, and the attacker may have persisted elsewhere. The first step is network isolation: apply a quarantine security group that denies ingress and egress except forensic access, and cordon the nodes so new pods are not scheduled. For the live event, I would fail over the streaming workload to a clean node pool rather than leave it on compromised hosts.

Next, preserve evidence: capture pod specs, the hostPath mount, container images, running processes, and EBS snapshots. Revoke the node instance profile credentials or attach an explicit deny, because the role can read the content bucket. Rotate any secrets reachable from those pods. Identify all 20 pods using the same image tag and check whether other nodes pulled it. Block the image digest at the registry or admission layer.

Only after evidence capture and workload migration would I terminate and rebuild the nodes from a trusted image. The decision is risk-based: active data theft would shorten the preservation window, but immediate termination without scoping often turns one incident into an incomplete investigation.

I would treat them as a known coverage gap, not as equivalent to protected hosts. First, rank them by data sensitivity, internet exposure, and business criticality. Hosts that can reach content or customer data should be isolated, restricted to required egress, and placed behind stricter network controls. Agentless snapshots help with disk-based malware and vulnerability evidence, but they do not give runtime process visibility, so I would not claim full detection coverage.

The remediation plan should include kernel upgrades, replacement instances, or migration to supported AMIs, with dates. Until then, use compensating controls: no public IPs, security-group least privilege, host firewall, centralized authentication, and vulnerability management. If a host cannot be upgraded, document a time-bound risk exception approved by the application owner.

For incident response, I would add a playbook that uses network flow, authentication logs, and disk snapshots for these hosts. The goal is to make the residual risk explicit, not to hide it behind an agentless scan.

The docker.sock mount is the critical enabler. I would add an admission controller that blocks hostPath mounts to the container runtime socket, privileged containers, hostNetwork where unnecessary, and unsigned images. Image provenance should be enforced with signing and a policy that allows only approved registries, not arbitrary public tags. Pod Security Standards can provide a baseline, but the socket mount needs an explicit policy.

Identity controls matter too. Workloads should use IRSA or Pod Identity with scoped S3 permissions, and the node role should not read content buckets. Network policies should limit pod egress, and runtime detection should remain in place as a backstop. For the CI pipeline, scan images and generate SBOMs; for the cluster, log Kubernetes audit events and alert on privileged pod creation.

I would roll out policies in audit mode first, measure violations, then enforce. A preventive control that breaks the live streaming service without warning creates a new outage, so staged enforcement and exception handling are part of the security design.