I85PREP
⌘ K
CCAS study materials
CCAS study resources

Cryptomining in an EKS Cluster with Weak Guardrails

CCAS · Put your knowledge to work in context.

All case studies

Cryptomining in an EKS Cluster with Weak Guardrails

A media company runs 200 microservices on Amazon EKS. Images are built by 12 teams and pushed to a shared Amazon ECR repository. Some teams pull public images directly from Docker Hub at deploy time. Kubernetes manifests allow containers to run as root by default; no NetworkPolicies exist. Secrets are injected as environment variables from Kubernetes Secrets. Last week a cryptomining workload ran for 9 hours after an attacker exploited a known vulnerability in a public NGINX image that had been deployed without a pinned digest. The attacker used the pod's service account token to list secrets in the namespace. The platform team has 5 engineers and wants guardrails that do not require reviewing every manifest.

1. Outline immediate containment and evidence preservation steps for the cryptomining incident.

Read the worked answer

Containment and evidence:

  1. Isolate, do not delete. Cordon the node and apply a quarantine NetworkPolicy or security group that blocks egress except to the forensic collector. Preserve the pod, node, and container filesystem; take EBS snapshots of the node volume before draining.
  2. Capture volatile evidence: pod spec, image digest, container logs, kubectl get events, service account token, mounted secrets, process list, and network connections. Export EKS audit logs and VPC Flow Logs for the incident window.
  3. Revoke credentials: delete the pod's service account token, rotate any secrets mounted in the namespace, and disable the IRSA role if used. Check CloudTrail for STS and Secrets Manager calls from the pod's identity.
  4. Scope lateral movement: review Kubernetes API audit logs for list secrets, get pods, and role bindings; check other pods on the node and other namespaces using the same image.
  5. Block the source: add the malicious image digest and any C2 domains or IPs to the registry deny list and egress blocklist.
  6. Communicate: open an incident, preserve a timeline, and avoid rebuilding the node until snapshots are verified.

Reasoning: deleting the workload destroys the evidence needed to determine whether the service account token was used elsewhere.

2. Design admission and supply-chain controls that enforce secure defaults without per-manifest review.

Read the worked answer

Guardrails without per-manifest review:

  1. Admission policies: use OPA Gatekeeper or Kyverno in enforce mode to require runAsNonRoot: true, allowPrivilegeEscalation: false, readOnlyRootFilesystem: true, drop all capabilities, no hostPath, no hostNetwork, and resource limits. Apply Pod Security Standards restricted to application namespaces.
  2. Image provenance: disallow images from Docker Hub; allow only the approved ECR registry, require a digest instead of latest, and verify a cosign signature at admission with Sigstore policy-controller. Build pipelines sign images after scanning.
  3. Scanning and SBOM: ECR enhanced scanning or Trivy on every build; fail on critical CVEs with a fix; generate an SBOM and store it with the image.
  4. Default-deny networking: a default-deny NetworkPolicy in each namespace with explicit allows; block egress to the internet except through an approved proxy.
  5. Secrets: disable automount of service account tokens where possible; use External Secrets Operator or a CSI driver instead of Kubernetes Secrets in environment variables.
  6. Namespace ownership: the platform team owns the policies; teams get a namespace template that already complies, so they do not write raw manifests from scratch.

Reasoning: admission control catches drift at deploy time; signing and digest pinning stop the public-image attack path.

3. How would you detect and limit the blast radius of a compromised pod using the service account token?

Read the worked answer

Detect and limit blast radius:

  • Prevent token mounting: set automountServiceAccountToken: false on pods that do not call the Kubernetes API; for those that do, use dedicated service accounts with RBAC limited to the namespace and no list secrets permission.
  • Use IRSA or Workload Identity instead of node instance profiles; scope the IAM role to specific resources and actions, and use short-lived tokens with audience restrictions.
  • NetworkPolicy default deny limits the pod's ability to reach the Kubernetes API, cloud metadata, and other namespaces. Block access to the instance metadata service except for approved pods.
  • Runtime detection: deploy Falco or similar to alert on crypto-mining indicators such as high CPU, mining pool domains, unusual exec, a shell inside a container, and unexpected outbound connections.
  • Kubernetes audit alerts: alert on list secrets, get secrets, and create rolebinding from application service accounts; baseline normal API calls.
  • Cloud-side detection: alert on AssumeRoleWithWebIdentity from unexpected pods and on Secrets Manager GetSecretValue spikes.
  • Response: revoke the service account token, delete RBAC bindings, rotate mounted secrets, and isolate the pod.

Reasoning: the attacker used the token to list secrets; removing automount and enforcing least-privilege RBAC makes that step fail, while runtime detection catches the mining workload.