eBPF Daemonset Installation¶
The CloudTaser eBPF agent is a DaemonSet deployed on every node in the cluster. It provides runtime enforcement and secret leak detection by monitoring syscalls via eBPF kprobes and tracepoints. The agent blocks exfiltration vectors such as /proc/pid/environ reads, /proc/pid/mem access, and ptrace attach attempts on CloudTaser-protected processes.
Purpose¶
Without the eBPF agent, CloudTaser protects secrets at the infrastructure level -- secrets bypass etcd and Kubernetes Secrets entirely. The eBPF agent adds runtime protection on the node itself:
- Blocks
/procaccess -- Prevents reading/proc/<pid>/environand/proc/<pid>/memof protected processes, even by root - Blocks
ptrace-- Prevents debugger attach and memory inspection of protected processes - Exfiltration detection -- Monitors for suspicious syscall patterns that indicate secret extraction attempts
- Reactive kill -- Optionally terminates processes that attempt to read protected memory regions
Defense in depth
The eBPF agent is a defense-in-depth layer. Even without it, secrets never touch etcd or disk. The agent protects against a compromised node or container escape scenario where an attacker has root access on the host.
Kernel Requirements¶
The eBPF agent requires a Linux kernel with BPF support. The following table summarizes compatibility.
| Kernel Version | Support Level | Notes |
|---|---|---|
| < 5.8 | Not supported | Missing required BPF features |
| 5.8 -- 5.13 | Basic | Core enforcement works, some features limited |
| 5.14+ | Full (recommended) | Full feature set including memfd_secret integration |
| 6.1+ | Full | Long-term support kernel, ideal for production |
Check your node kernel version
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.nodeInfo.kernelVersion}{"\n"}{end}'
All nodes must run Linux 5.8 or later. Nodes running 5.14+ get the full protection set.
Managed Kubernetes Kernel Versions¶
| Node Image | Kernel | Supported |
|---|---|---|
| Container-Optimized OS (COS) | 5.15+ | Yes |
| Ubuntu | 5.15+ | Yes |
GKE Standard clusters with COS or Ubuntu node images meet kernel requirements out of the box.
| AMI | Kernel | Supported |
|---|---|---|
| Amazon Linux 2023 | 6.1+ | Yes |
| Amazon Linux 2 | 5.10+ | Yes (basic) |
| Ubuntu 22.04 | 5.15+ | Yes |
Amazon Linux 2023 is recommended for EKS deployments.
| Node Image | Kernel | Supported |
|---|---|---|
| Ubuntu 22.04 | 5.15+ | Yes |
| Azure Linux (Mariner) | 5.15+ | Yes |
AKS with Ubuntu node images meets kernel requirements by default.
Managed Kubernetes Compatibility¶
Serverless/Autopilot environments are not supported
The eBPF agent requires hostPID: true and privileged container access, which are not available on serverless Kubernetes platforms.
| Platform | Supported | Reason |
|---|---|---|
| GKE Standard | Yes | Full host access available |
| GKE Autopilot | No | Cannot run privileged DaemonSets |
| EKS (managed nodes) | Yes | Full host access available |
| EKS (self-managed nodes) | Yes | Full host access available |
| AWS Fargate | No | No host access, no DaemonSet support |
| AKS (regular node pools) | Yes | Full host access available |
| AKS (Virtual Nodes) | No | Backed by Azure Container Instances, no host access |
Installation¶
The eBPF agent is part of the unified CloudTaser Helm chart and is enabled by default. If you already installed CloudTaser following the operator installation guide, the eBPF DaemonSet is already running.
Verify Default Installation¶
Expected output:
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
cloudtaser-ebpf 3 3 3 3 3 <none> 2m
Enable or Disable via Helm Values¶
To explicitly control the eBPF agent during installation:
helm install cloudtaser oci://ghcr.io/skipopsltd/cloudtaser-helm/cloudtaser \
--namespace cloudtaser-system \
--create-namespace \
--set operator.vaultAddress=https://vault.eu.example.com \
--set ebpf.enabled=false
Warning
Disabling the eBPF agent removes runtime enforcement. Secrets are still protected at the infrastructure level (memory-only, no etcd), but node-level exfiltration attacks are not blocked. The protection score for workloads will be reduced.
Helm Values¶
ebpf:
enabled: true
image:
repository: ghcr.io/skipopsltd/cloudtaser-ebpf
tag: "v0.1.12-amd64"
pullPolicy: IfNotPresent
# Block exfiltration attempts (vs. log-only)
enforceMode: true
# Log all syscall events (verbose, for debugging only)
logAll: false
# Terminate processes that attempt to read protected memory
reactiveKill: true
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 500m
memory: 512Mi
| Value | Default | Description |
|---|---|---|
ebpf.enabled |
true |
Deploy the eBPF DaemonSet |
ebpf.enforceMode |
true |
Block exfiltration attempts. Set to false for audit-only mode |
ebpf.logAll |
false |
Log all monitored syscalls. Enable only for debugging |
ebpf.reactiveKill |
true |
Kill processes that attempt to read protected process memory |
Verify Installation¶
Check DaemonSet Status¶
Ensure the DaemonSet is running on all schedulable nodes:
The DESIRED, CURRENT, and READY counts should all match and equal the number of nodes in your cluster.
Check Node Coverage¶
Verify every node has a running eBPF agent pod:
Each node should have exactly one eBPF agent pod in Running state.
Check Agent Logs¶
Look for log lines confirming BPF programs have been loaded and the agent is monitoring protected PIDs.
Check Health Endpoints¶
The eBPF agent exposes HTTP health endpoints:
# Liveness
kubectl exec -n cloudtaser-system daemonset/cloudtaser-ebpf -- wget -qO- http://localhost:9090/healthz
# Readiness
kubectl exec -n cloudtaser-system daemonset/cloudtaser-ebpf -- wget -qO- http://localhost:9090/readyz
Validate with CLI¶
If you have the CloudTaser CLI installed:
The output includes eBPF enforcement coverage -- the percentage of nodes with a healthy eBPF agent.
Required Capabilities¶
The eBPF agent runs as a privileged DaemonSet with the following security context:
Required Linux capabilities:
| Capability | Purpose |
|---|---|
SYS_ADMIN |
Load and attach BPF programs |
SYS_PTRACE |
Access process information for PID monitoring |
NET_ADMIN |
Attach network-related BPF programs |
SYS_RESOURCE |
Increase locked memory limits for BPF maps |
The agent uses priorityClassName: system-node-critical to ensure scheduling even under resource pressure.
Troubleshooting¶
| Symptom | Cause | Fix |
|---|---|---|
DaemonSet pods in CrashLoopBackOff |
Kernel too old or BPF not enabled | Check kernel version is 5.8+; verify /sys/fs/bpf is mounted |
DESIRED != READY |
Agent failing on specific nodes | Check logs on the failing node's pod; likely a kernel compatibility issue |
| Agent running but no enforcement | enforceMode: false |
Set ebpf.enforceMode=true in Helm values and upgrade |
| Low protection score despite agent running | Agent not receiving PID registrations from operator | Check connectivity between eBPF agent and operator on port 8199 |
For more details, see Troubleshooting and Kernel Compatibility.
Next Steps¶
- Configure the S3 encryption proxy for client-side encryption of stored data
- Production deployment guide for HA, monitoring, and network policies
- eBPF enforcement details for the full list of monitored syscalls and enforcement actions