Runtime Sensor
Deployment

Deployment

Endura Runtime Sensor is a lightweight runtime security agent that provides real-time protection and policy enforcement across diverse Linux environments. This overview covers the installation methods, distribution channels, and technical considerations for deploying the Sensor across your infrastructure.

Supported Platforms

Endura Runtime Sensor supports installation on all major Linux distributions:

RPM-Based Distributions:

  • RedHat Enterprise Linux 8/9/10
  • AlmaLinux 8/9/10
  • Rocky Linux 8/9/10
  • CentOS Stream 8/9
  • Fedora 43
  • Oracle Linux 8/9/10
  • SUSE Linux Enterprise Server (SLES) 15/16
  • OpenSUSE Leap 15/16

DEB-Based Distributions:

  • Debian 11/12/13
  • Ubuntu (all supported LTS and current releases)

Other Distributions:

  • Alpine Linux 3
  • Amazon Linux 2023
  • Arch Linux

Installation Methods

Native Package Installation

The Sensor is distributed as native packages optimized for each platform:

RPM Packages - For RedHat, CentOS, Fedora, SUSE, Oracle Linux, AlmaLinux, and Rocky Linux distributions. These packages integrate with the system package manager (dnf/yum/zypper) and include systemd service files.

DEB Packages - For Debian and Ubuntu distributions, providing seamless integration with apt package management and systemd.

Tarball (TGZ) - For distributions without native package format support (Alpine, Arch, Amazon Linux), we provide pre-compiled tarballs with installation scripts.

Official Package Repositories

For distributions supporting RPM and DEB packages, we maintain official package repositories:

  • RPM Repository: Provides signed packages for all RPM-based distributions with automatic dependency resolution
  • DEB Repository: Offers signed packages for Debian-based systems with apt integration

Repository installation includes GPG key verification to ensure package authenticity and integrity.

Container Distribution

The Sensor is also packaged and distributed as a container image:

Registry: ghcr.io/endurasecurity/container/endura-sensor

The containerized Sensor provides:

  • Consistent deployment across container orchestration platforms
  • Simplified updates and rollbacks
  • Isolation from host package management
  • Support for Kubernetes, Docker, Podman, and other container runtimes

Versioning and Release Channels

Semantic Versioning

Endura Runtime Sensor follows semantic versioning (semver) principles:

  • Major.Minor.Patch format (e.g., 1.2.3)
  • Major versions for breaking changes
  • Minor versions for new features
  • Patch versions for bug fixes and security updates

Release Channels

Three release channels provide different stability and testing levels:

Latest Channel

  • Most recent builds that passed Sensor-specific automated testing
  • Equivalent to CI/CD builds
  • Recommended for development and testing environments
  • Fastest access to new features and fixes

Testing Channel

  • Builds that passed both Sensor testing and full integration/end-to-end testing with Team Server
  • Rolling release model with regular updates
  • Suitable for staging environments and early adoption
  • Balance between stability and feature access

Stable Channel

  • Thoroughly tested releases promoted from the testing channel
  • Undergoes extensive manual testing and validation
  • Traditional release model with slower, more predictable updates
  • Recommended for production environments requiring maximum stability

Each channel represents tagged versions of the same builds, allowing easy promotion between channels as testing confidence increases.

Security Enforcement Technology

eBPF LSM Integration

Endura Runtime Sensor leverages Extended Berkeley Packet Filter (eBPF) Linux Security Module (LSM) hooks for optimal security policy enforcement:

Primary Mode - eBPF LSM Hooks:

  • Intercepts security-relevant operations at the kernel level
  • Enables real-time policy decisions before operations complete
  • Can reject unauthorized operations before they execute
  • Provides the strongest security posture with minimal performance impact

Fallback Mode - eBPF fentry Hooks:

  • Used when eBPF LSM hooks are unavailable
  • Monitors operations but cannot prevent their execution
  • Limited to terminating offending processes via SIGKILL after detection
  • Still provides security value through rapid threat response

LSM Hook Availability

Distributions with eBPF LSM Support (out-of-the-box):

  • RedHat Enterprise Linux 8/9/10
  • AlmaLinux 8/9/10
  • Rocky Linux 8/9/10
  • CentOS Stream 8/9
  • Fedora 43
  • Debian 11/12/13
  • SUSE Linux Enterprise Server 15/16
  • OpenSUSE Leap 15/16
  • Arch Linux
  • Amazon Linux 2023

Distributions requiring manual eBPF LSM configuration:

  • Alpine Linux 3 (all variants)
  • Ubuntu (all versions)
  • Oracle Linux with Unbreakable Enterprise Kernel (UEK)

For distributions without default eBPF LSM support, refer to your distribution’s documentation for kernel configuration guidance to enable these security features.

Process Termination Behavior

By default, the Sensor attempts to terminate processes that violate security policies regardless of the enforcement mode:

  • eBPF LSM mode: Reject operation + optionally terminate process
  • eBPF fentry mode: Monitor operation + terminate process
  • Process termination can be disabled via configuration for audit-only deployments

System Requirements

Hardware Requirements

  • Memory: Minimum 512MB RAM, 1GB recommended for production workloads
  • Disk Space: 1GB available space for installation and logs
  • CPU: Any x86_64 or ARM64 architecture supported by the target distribution

Software Requirements

  • Kernel Version: Linux kernel 4.18+ (5.8+ recommended for optimal eBPF LSM support)
  • systemd: Required for service management on all distributions
  • Network Access: HTTPS connectivity for package repositories and Team Server communication

Team Server Integration

The Runtime Sensor can operate in two modes:

Standalone Mode: Local policy enforcement without centralized management

  • Policies configured locally via configuration files
  • Logs stored locally or forwarded to external systems
  • Suitable for isolated environments or air-gapped deployments

Team Server Mode: Centralized management and policy distribution

  • Policies managed centrally through Team Server web interface
  • Real-time telemetry and alert aggregation
  • Centralized logging and compliance reporting
  • Sensor token authentication for secure communication

Performance Considerations

  • CPU Overhead: Typically <2% CPU utilization under normal workloads
  • Memory Footprint: Base memory usage of ~100-200MB depending on policy complexity
  • Network Traffic: Minimal bandwidth usage for telemetry (configurable batching)
  • Kernel Integration: eBPF programs provide near-zero latency security enforcement

Network Requirements

Outbound Connectivity (Team Server Mode):

  • HTTPS (443/tcp) to Team Server for policy updates and telemetry
  • DNS resolution for Team Server hostname

Package Installation:

  • HTTPS (443/tcp) to package repositories (repo.endurasecurity.com)
  • HTTPS (443/tcp) to container registry (ghcr.io) for container deployments

Next Steps

Choose your platform-specific installation guide:

Each guide provides detailed installation instructions, configuration options, and troubleshooting information specific to your distribution.