A DaemonSet is a Kubernetes controller that runs one pod per node. When it is privileged and can mount the host filesystem, it becomes a node-level execution vehicle rather than a normal workload, which makes it attractive to attackers seeking cluster-wide control.
Expanded Definition
A privileged DaemonSet is not just a Kubernetes deployment pattern. It is a workload that runs on every node and, when granted elevated permissions such as hostPath mounts or privileged container access, can interact with the node operating system itself. In NHI security, that combination matters because the pod is no longer confined to application logic. It becomes an execution surface with the potential to read credentials, tamper with runtime components, or pivot into cluster-wide control paths.
Definitions vary across vendors on how much host access is enough to make a DaemonSet dangerous, but the practical boundary is clear: once a pod can inspect node state, mount sensitive paths, or act with broad Kubernetes API permissions, it behaves like infrastructure control code. That is why the OWASP Non-Human Identity Top 10 treats identity and privilege on workloads as security-critical rather than purely operational. NHI Mgmt Group’s Ultimate Guide to NHIs — Key Challenges and Risks shows how excessive privileges and poor visibility create systemic exposure across service accounts and other machine identities.
The most common misapplication is treating a privileged DaemonSet as a standard observability or security agent, which occurs when node-level access is approved without reviewing host filesystem mounts, RBAC scope, and secret exposure paths.
Examples and Use Cases
Implementing privileged DaemonSets rigorously often introduces operational friction, because node-level access can simplify diagnostics and enforcement while increasing blast radius and review burden.
- A logging agent mounts
/var/logand/var/libto collect telemetry, but it must be constrained so it cannot read kubelet credentials or workload secrets on the node. - A security scanner runs on every node to inspect kernel and runtime posture, yet its service account should be limited to read-only cluster permissions and tightly scoped host mounts.
- A storage or CNI component needs privileged access for low-level node functions, but the deployment must be validated against OWASP Non-Human Identity Top 10 expectations for workload identity and secret handling.
- After a control-plane incident, investigators may find that a privileged DaemonSet was used to persist access on every node, matching patterns discussed in the Microsoft SAS Key Breach analysis.
- Platform teams may use a DaemonSet for node hardening or compliance checks, but the container image, admission policy, and runtime permissions must all be reviewed together rather than separately.
Why It Matters in NHI Security
Privileged DaemonSets matter because they concentrate trust at the node layer, where one misconfigured workload can inherit the effective power of many. In Kubernetes environments, that makes them especially relevant to NHI governance: the pod often uses a service account, accesses secrets, and may operate with rights that outlive its immediate business purpose. NHI Mgmt Group notes that 97% of NHIs carry excessive privileges, which helps explain why node-level agents are frequently over-permissioned when teams prioritise functionality over containment.
This term also ties directly to zero trust thinking. A privileged DaemonSet should be treated as a high-risk machine identity, not a trusted background task. Controls such as least privilege, workload isolation, secret minimisation, and continuous review become essential when the workload can reach the host. The NHI Mgmt Group guidance on identity risk and visibility gaps is directly relevant here, because node-level agents are often the least visible and most difficult to rotate or offboard cleanly.
Organisations typically encounter the true impact of a privileged DaemonSet only after a node compromise or credential theft, at which point the workload’s reach becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, CSA MAESTRO and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Privileged DaemonSets are workload identities with excessive access and host reach. |
| NIST CSF 2.0 | PR.AA | Access authority for machine workloads must be defined and enforced. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero trust requires treating node-level workloads as untrusted by default. |
| CSA MAESTRO | IAC-04 | Agentic and autonomous workloads require constrained infrastructure access. |
| OWASP Agentic AI Top 10 | A1 | Autonomous workloads with tool or host access can become high-impact execution paths. |
Reduce node-level privilege, scope mounts tightly, and review workload identity permissions continuously.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
