Kubernetes DaemonSet Security Management

Kubernetes DaemonSet Security Management is the practice of minimizing and controlling the privileges granted to DaemonSet Pods, given that daemon workloads frequently require elevated access — to the host filesystem, the host network namespace, or specific Linux capabilities — precisely because their function depends on visibility into or control over the node itself. Because a compromised DaemonSet Pod runs with whatever privileges it was granted on every single node it covers, security lapses in daemon configuration have a uniquely wide blast radius compared to a similarly misconfigured application Deployment, whose compromise would typically be contained to a smaller number of replicas.

Security management for DaemonSets is fundamentally about reconciling this tension: many legitimate daemon functions genuinely require broad access, but that same breadth of access, if granted more liberally than necessary, converts every covered node into a potential target through a single compromised container image or vulnerability.

Principle of Least Privilege

Scoping Linux Capabilities Precisely

Rather than defaulting to privileged: true, which grants effectively unrestricted access to the host, daemon templates should identify and grant only the specific Linux capabilities the workload actually needs (NET_ADMIN for network configuration, SYS_PTRACE for process inspection) via securityContext.capabilities.add, while explicitly dropping all others.

securityContext:
  capabilities:
    drop: ["ALL"]
    add: ["NET_ADMIN"]
  allowPrivilegeEscalation: false

Read-Only Root Filesystem Where Possible

Setting securityContext.readOnlyRootFilesystem: true on daemon containers that do not need to write to their own container filesystem (writing instead only to specific mounted volumes) reduces the impact of a container-level compromise by preventing an attacker from persisting changes to the container's own filesystem.

Host Access Controls

hostNetwork and hostPID Scrutiny

hostNetwork: true and hostPID: true are among the highest-privilege settings a Pod can request, since they place the container directly into the node's own network and process namespaces rather than an isolated one. These settings should be reserved for daemons whose function genuinely requires them (a CNI plugin needing direct network namespace access) and should be flagged for specific review in any policy enforcement, since they represent a meaningfully larger security surface than an ordinarily namespaced Pod.

hostPath Volume Restrictions

hostPath volumes granting write access to sensitive host directories (/etc, the container runtime's socket, /var/lib/kubelet) should be scoped as narrowly and as read-only as the daemon's actual need allows — a log collector reading /var/log read-only carries far less risk than one mounted with write access to broader system paths it does not actually need to modify.

volumes:
  - name: varlog
    hostPath:
      path: /var/log
      type: Directory
volumeMounts:
  - name: varlog
    mountPath: /var/log
    readOnly: true

RBAC for Daemon Service Accounts

Dedicated, Narrowly Scoped Service Accounts

Each DaemonSet interacting with the Kubernetes API should use its own dedicated ServiceAccount rather than sharing one broadly across multiple daemons, paired with a Role/ClusterRole granting only the specific API verbs and resources that daemon actually needs (for example, get/list/watch on nodes and pods, but not broad write access unless genuinely required).

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: codartium-log-agent
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "watch"]

Admission-Time Policy Enforcement

Pod Security Standards

Cluster-wide Pod Security Admission labels (restricted, baseline, privileged) applied at the namespace level interact directly with DaemonSet security posture — daemons genuinely requiring privileged access are typically isolated into a dedicated namespace labeled privileged, keeping the more restrictive standard enforced everywhere else, rather than loosening the policy cluster-wide to accommodate a small number of privileged daemons.

Policy-as-Code Checks

Automated policy tools (OPA Gatekeeper, Kyverno) commonly include specific rules targeting DaemonSets — flagging privileged: true without an accompanying justification annotation, or requiring explicit tolerations rather than a blanket operator: Exists toleration that was not deliberately intended — catching security regressions in daemon manifests during CI rather than after deployment.

Auditing Daemon Privilege Levels

kubectl get daemonsets -A -o json | \
  jq -r '.items[] | select(.spec.template.spec.hostNetwork==true or .spec.template.spec.containers[].securityContext.privileged==true) | .metadata.name'

Periodically auditing every DaemonSet in the cluster for elevated privilege flags is a practical way to maintain an inventory of exactly which daemons carry the highest-risk configurations, which is typically the first list consulted during a security review or incident investigation touching node-level infrastructure.

Example

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: codartium-security-example
spec:
  selector:
    matchLabels:
      app: codartium-log-agent
  template:
    metadata:
      labels:
        app: codartium-log-agent
    spec:
      serviceAccountName: codartium-log-agent
      containers:
        - name: log-agent
          image: codartium/log-agent:latest
          securityContext:
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            capabilities:
              drop: ["ALL"]
          volumeMounts:
            - name: varlog
              mountPath: /var/log
              readOnly: true
      volumes:
        - name: varlog
          hostPath:
            path: /var/log
            type: Directory