Runtime Sensor
Runtime Sensor
The Runtime Sensor observes security-relevant Linux operations and enforces Endura policies at the kernel boundary. It can protect CI/CD builds and long-running workloads.
How It Works
The Sensor loads eBPF programs and evaluates operations before they complete. Depending on policy mode, it derives rules, records violations, or blocks unauthorized behavior.
| Capability | Examples |
|---|---|
| File access | Execution, reads, writes, creation, deletion, mounts |
| Networking | IP, Unix, packet, raw, netlink, and vsock operations |
| Process control | Signals, scheduling, resource limits, tracing |
| Kernel and memory | eBPF, modules, IOCTL, W+X, memory mapping |
| Containers | Image execution and runtime socket access |
Deployment Options
| Method | Use it for |
|---|---|
| Native package | Persistent Linux hosts and CI/CD runners |
| Docker | Hosts managed with Docker |
| Podman | Hosts managed with Podman |
| Kubernetes | One Sensor per cluster node through a DaemonSet |
Operating Modes
Standalone
Set ENDURA_LICENSE_KEY and run the Sensor without ENDURA_TEAM_SERVER. Policies and results remain local.
Team Server
Set ENDURA_TEAM_SERVER and ENDURA_SENSOR_TOKEN in addition to the license key. Team Server then distributes policies and receives status, logs, and violations.
Requirements
- A supported Linux kernel and eBPF capabilities
- Root access to start and stop the Sensor
- An Endura license key
- HTTPS connectivity to Team Server when using centralized management
- Enough memory for eBPF maps and event buffers; start with at least 1 GB available
See Deployment for supported platforms and kernel requirements.
Policy Workflow
- Start the Sensor.
- Start an Endura job for the workspace.
- Run the protected workload.
- Stop the job to emit results and any derived policy.
- Refine and assign the policy before enabling enforcement.
See the command reference and security policy guide.