Package: endura-sensor
Architecture: amd64
Version: 1.0.106-1
Priority: optional
Section: Development
Maintainer: Infrared Security, LLC.
Installed-Size: 30365
Depends:
Filename: ./endura-sensor_1.0.106-1_amd64.deb
Size: 4458280
MD5sum: 6a45bb20ebbcad3dcc01e9033e415630
SHA1: 062f070297e939de92c17453f3bd9097f4488b82
SHA256: cffdd5b7a2f5083e0ac192621501673882bbe8e25f1554d6d7a2b4c4292eb297
SHA512: 6c0b5374367fb0136161b45df4963ea6a72475d8cc412e5b94848b4a48e2ef8c2627a0bff4267c59c26c2a798daf77bec35216021b40abb3e3c25ad79ba6193f
Description: endura sensor
 # Endura Runtime Sensor
 .
 The Endura Runtime Sensor provides kernel-level runtime monitoring and policy
 enforcement for Linux workloads. It observes security-relevant operations with
 eBPF, evaluates Endura policies before operations complete, and reports
 activity
 and violations to Endura Team Server when centralized management is configured.
 .
 ## Capabilities
 .
 | Area | 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, kernel modules, IOCTL, executable memory |
 | Containers | Image execution and container-runtime socket access |
 .
 ## Documentation
 .
 The [official Runtime Sensor
 documentation](https://docs.endurasecurity.com/runtime-sensor/)
 is the source of truth for installation, deployment, configuration, operation,
 updates, and troubleshooting.
 .
 ### Deployment Options
 .
 | Method | Use it for |
 |--------|------------|
 | [Native package](https://docs.endurasecurity.com/runtime-sensor/deployment/)
 | Persistent Linux hosts and CI/CD runners |
 | [Docker](https://docs.endurasecurity.com/runtime-sensor/deployment/docker/) |
 Hosts managed with Docker |
 | [Podman](https://docs.endurasecurity.com/runtime-sensor/deployment/podman/) |
 Hosts managed with Podman |
 |
 [Kubernetes](https://docs.endurasecurity.com/runtime-sensor/deployment/kubernetes/)
 | One Runtime Sensor per cluster node through a DaemonSet |
 .
 ## Repository Validation
 .
 The repository's automated validation includes Rust tests, host-level system
 tests, Kubernetes tests, eBPF compatibility checks, and build-tooling tests.
 Contributors use these `mise` task entry points:
 .
 - `mise run check` for formatting and static analysis
 - `mise run test` for the Rust test suite
 - `mise run test:tooling` for isolated build-tooling regressions
 - `mise run test:system [suite]` for host-level runtime behavior
 - `mise run test:k8s [suite]` for Kubernetes deployment behavior
 - `mise run test:ebpf` for eBPF compatibility
 .
 Runtime test suites require a supported Linux environment, elevated privileges,
 and authorized Endura test credentials.
 .
 ## Support
 .
 - Review the [Runtime Sensor
 documentation](https://docs.endurasecurity.com/runtime-sensor/)
   for product guidance.
 - Visit [Endura Security](https://endurasecurity.com) for product information.
 - Use the [Endura contact page](https://endurasecurity.com/contact) for
   onboarding and support requests.
 .
 ## License
 .
 Copyright Endura Security. All rights reserved.

Package: endura-sensor
Architecture: amd64
Version: 1.0.107-1
Priority: optional
Section: Development
Maintainer: Infrared Security, LLC.
Installed-Size: 30409
Depends:
Filename: ./endura-sensor_1.0.107-1_amd64.deb
Size: 4461616
MD5sum: ad6a27ae48c720cfb8e3b36e8b70de0e
SHA1: c037fca99c36914e98b948705bafc7d0fbf2d866
SHA256: bafbc6230ff31ea6f18f22f768d2f339798060bcd36536ce93d23b26919964e7
SHA512: 8458264a6c58888a96c2b9fbda709bed335790a479602228c4e7610b31cc3a9ac345e73e3dd58485f1cb34ff2f89f15dc93aa3a70695598c2b284fdc94ce980f
Description: endura sensor
 # Endura Runtime Sensor
 .
 The Endura Runtime Sensor provides kernel-level runtime monitoring and policy
 enforcement for Linux workloads. It observes security-relevant operations with
 eBPF, evaluates Endura policies before operations complete, and reports
 activity
 and violations to Endura Team Server when centralized management is configured.
 .
 ## Capabilities
 .
 | Area | 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, kernel modules, IOCTL, executable memory |
 | Containers | Image execution and container-runtime socket access |
 .
 ## Documentation
 .
 The [official Runtime Sensor
 documentation](https://docs.endurasecurity.com/runtime-sensor/)
 is the source of truth for installation, deployment, configuration, operation,
 updates, and troubleshooting.
 .
 ### Deployment Options
 .
 | Method | Use it for |
 |--------|------------|
 | [Native package](https://docs.endurasecurity.com/runtime-sensor/deployment/)
 | Persistent Linux hosts and CI/CD runners |
 | [Docker](https://docs.endurasecurity.com/runtime-sensor/deployment/docker/) |
 Hosts managed with Docker |
 | [Podman](https://docs.endurasecurity.com/runtime-sensor/deployment/podman/) |
 Hosts managed with Podman |
 |
 [Kubernetes](https://docs.endurasecurity.com/runtime-sensor/deployment/kubernetes/)
 | One Runtime Sensor per cluster node through a DaemonSet |
 .
 ## Repository Validation
 .
 The repository's automated validation includes Rust tests, host-level system
 tests, Kubernetes tests, eBPF compatibility checks, and build-tooling tests.
 Contributors use these `mise` task entry points:
 .
 - `mise run check` for formatting and static analysis
 - `mise run test` for the Rust test suite
 - `mise run test:tooling` for isolated build-tooling regressions
 - `mise run test:system [suite]` for host-level runtime behavior
 - `mise run test:k8s [suite]` for Kubernetes deployment behavior
 - `mise run test:ebpf` for eBPF compatibility
 .
 Runtime test suites require a supported Linux environment, elevated privileges,
 and authorized Endura test credentials.
 .
 ## Support
 .
 - Review the [Runtime Sensor
 documentation](https://docs.endurasecurity.com/runtime-sensor/)
   for product guidance.
 - Visit [Endura Security](https://endurasecurity.com) for product information.
 - Use the [Endura contact page](https://endurasecurity.com/contact) for
   onboarding and support requests.
 .
 ## License
 .
 Copyright Endura Security. All rights reserved.

Package: endura-sensor
Architecture: amd64
Version: 1.0.95-1
Priority: optional
Section: Development
Maintainer: Infrared Security, LLC.
Installed-Size: 31283
Depends:
Filename: ./endura-sensor_1.0.95-1_amd64.deb
Size: 4680016
MD5sum: 77dcdf1dcf21bd9928706c0c573ace66
SHA1: c3dfdd97f636fe637188d05cc521e86534d65239
SHA256: 7c70e22596ab7122843bf51c4bb2ca35573bc6b0e5d5814bd9689080775d3343
SHA512: 25da6f6fc22880579231661c9fa01f5ae435ef2f4b5c86b9637a1783d9032ab9c778885cdeca672ef9706226f2f9329056695951c804dfdf8ffa0f42a53c5381
Description: endura sensor
 # Endura Runtime Sensor
 .
 The Endura Runtime Sensor provides kernel-level runtime monitoring and policy
 enforcement for Linux workloads. It observes security-relevant operations with
 eBPF, evaluates Endura policies before operations complete, and reports
 activity
 and violations to Endura Team Server when centralized management is configured.
 .
 ## Capabilities
 .
 | Area | 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, kernel modules, IOCTL, executable memory |
 | Containers | Image execution and container-runtime socket access |
 .
 The Runtime Sensor supports three policy modes:
 .
 | Mode | Behavior |
 |------|----------|
 | `derive` | Observe activity and build a policy. This is the default. |
 | `observe` | Report violations without blocking operations. |
 | `enforce` | Block prohibited operations through supported kernel hooks. |
 .
 An empty `enforce` policy denies every covered operation. Derive and review a
 policy before enabling enforcement.
 .
 ## Kubernetes with Helm
 .
 The Helm chart deploys the Runtime Sensor as a privileged DaemonSet. One
 Runtime
 Sensor Pod runs on each eligible Linux node. Build Pods use the Runtime Sensor
 on their node through `/run/endura`; they do not start another Sensor.
 .
 For complete chart guidance, including build Pod instrumentation, resource
 sizing, scheduling, updates, and troubleshooting, see the
 [Runtime Sensor Helm chart guide](helm/README.md).
 .
 ### Prerequisites
 .
 - Kubernetes 1.25 or later with x86-64 (AMD64) Linux nodes
 - Helm 3.12 or later and `kubectl` configured for the target cluster
 - Pod Security settings that allow privileged host access
 - BTF data at `/sys/kernel/btf/vmlinux` on every target node
 - At least 1 GB of allocatable memory per Runtime Sensor Pod
 - An Endura license key
 - A Team Server URL and Runtime Sensor token for centralized management
 - `curl` and `jq` for the release-version command below
 .
 ### Choose a Release
 .
 Use `testing` for evaluation and automation. Use `stable` for production after
 validating it in your environment. Kubernetes installations must pin an
 explicit semantic chart version.
 .
 ```bash
 CHANNEL=testing
 CHART_VERSION=$(curl -sSf
 "https://repo.endurasecurity.com/${CHANNEL}/release.json" \
   | jq -r '.products.sensor.chart.version')
 printf 'Installing Runtime Sensor chart %s from %s\n' "$CHART_VERSION"
 "$CHANNEL"
 ```
 .
 The chart deploys the matching immutable Runtime Sensor image. Do not override
 `image.tag` with a mutable channel tag.
 .
 ### Create the Namespace and Secret
 .
 Create protected local files containing the license key and Runtime Sensor
 token. Each file must contain only its value, without a trailing newline:
 .
 ```bash
 kubectl create namespace endura
 kubectl create secret generic endura-sensor-secrets \
   --namespace endura \
   --from-file=ENDURA_LICENSE_KEY=/secure/path/endura-license-key \
   --from-file=ENDURA_SENSOR_TOKEN=/secure/path/endura-sensor-token
 ```
 .
 Omit `ENDURA_SENSOR_TOKEN` in standalone mode. The chart reads this Secret but
 does not create, update, or delete it.
 .
 ### Configure Values
 .
 Create `values.yaml` for Team Server mode:
 .
 ```yaml
 sensor:
   env:
     ENDURA_TEAM_SERVER: "https://team-server.example.com"
     ENDURA_LOG_LEVEL: "info"
 .
 resources:
   limits:
     memory: 2Gi
   requests:
     cpu: 250m
     memory: 1Gi
 ```
 .
 For standalone mode, omit `ENDURA_TEAM_SERVER` and create a values file only if
 you need to override other chart settings.
 .
 ### Install
 .
 Team Server mode:
 .
 ```bash
 helm install endura-sensor \
   "oci://ghcr.io/endurasecurity/helm/${CHANNEL}/endura-sensor" \
   --version "$CHART_VERSION" \
   --namespace endura \
   --values values.yaml
 ```
 .
 Standalone mode without custom values:
 .
 ```bash
 helm install endura-sensor \
   "oci://ghcr.io/endurasecurity/helm/${CHANNEL}/endura-sensor" \
   --version "$CHART_VERSION" \
   --namespace endura
 ```
 .
 ### Verify
 .
 Wait until Runtime Sensor Pods exist, then wait for them to become ready:
 .
 ```bash
 until kubectl get pods --namespace endura \
   --selector app.kubernetes.io/name=endura-sensor \
   --output name | grep -q .; do sleep 1; done
 .
 kubectl wait --for=condition=Ready pod \
   --selector app.kubernetes.io/name=endura-sensor \
   --namespace endura \
   --timeout=300s
 .
 kubectl get pods --namespace endura --output wide
 ```
 .
 Do not rely only on `helm install --wait` or `kubectl rollout status` for this
 DaemonSet. A new DaemonSet can initially report zero desired Pods and allow
 those commands to return before a Runtime Sensor Pod exists.
 .
 When centrally managed, confirm that each Runtime Sensor and node deployment
 also appears in Team Server.
 .
 ## Protect Workloads
 .
 Each protected build or workload starts an Endura job before running
 project-controlled commands and stops it during unconditional cleanup:
 .
 1. Mount the node's `/run/endura` into the workload container at
    `/run/endura`.
 2. Install the `endura` CLI in the workload container.
 3. Run `endura sensor wait` before starting protected work.
 4. Run `endura job start --workspace <path>` and retain the printed job ID.
 5. Run `endura job stop <path>` during cleanup after success, failure, or
 normal
    cancellation.
 .
 The workspace must exist and, for a non-root container, must be owned by the
 container user. Provider-specific CI/CD integration should use the provider's
 unconditional cleanup mechanism.
 .
 ## Operate the Runtime Sensor
 .
 Follow logs from every Runtime Sensor Pod:
 .
 ```bash
 kubectl logs --namespace endura \
   --selector app.kubernetes.io/name=endura-sensor \
   --follow --prefix
 ```
 .
 Run status and hook checks in one Pod:
 .
 ```bash
 SENSOR_POD=$(kubectl get pods --namespace endura \
   --selector app.kubernetes.io/name=endura-sensor \
   --output jsonpath='{.items[0].metadata.name}')
 .
 kubectl exec --namespace endura "$SENSOR_POD" -- /endura sensor status
 kubectl exec --namespace endura "$SENSOR_POD" -- /endura sensor hooks
 ```
 .
 `sensor status` reports Team Server connectivity. It does not report
 kernel-hook
 coverage. Review `sensor hooks` on each node after installation and after
 Runtime Sensor or node-kernel updates.
 .
 The Runtime Sensor and Team Server are compatible when their major versions
 match. Minor and patch versions can be updated independently. A major-version
 mismatch pauses submission to Team Server while local policy evaluation
 continues.
 .
 ## Common Chart Settings
 .
 | Parameter | Description | Default |
 |-----------|-------------|---------|
 | `image.repository` | Runtime Sensor image repository |
 `ghcr.io/endurasecurity/container/endura-sensor` |
 | `image.tag` | Image tag; an empty value uses the chart's immutable
 `appVersion` | `""` |
 | `secrets.name` | Existing Secret containing Runtime Sensor credentials |
 `endura-sensor-secrets` |
 | `sensor.env` | Nonsecret `ENDURA_*` environment variables | Log settings |
 | `resources.limits.memory` | Memory limit | `2Gi` |
 | `resources.requests.cpu` | CPU request | `250m` |
 | `resources.requests.memory` | Memory request | `1Gi` |
 | `priorityClassName` | Existing PriorityClass for Runtime Sensor Pods | `""` |
 | `nodeSelector` | Eligible node labels | `{kubernetes.io/os: linux}` |
 | `tolerations` | Tolerations for tainted nodes | `[]` |
 | `affinity` | Pod affinity and anti-affinity rules | `{}` |
 .
 The chart configures the privileged security context, host namespaces, and host
 mounts required for eBPF monitoring. Review the
 [complete chart guide](helm/README.md#required-host-access) before changing
 those settings.
 .
 ## Update
 .
 Resolve the new version from the selected channel, then upgrade the release:
 .
 ```bash
 CHART_VERSION=$(curl -sSf
 "https://repo.endurasecurity.com/${CHANNEL}/release.json" \
   | jq -r '.products.sensor.chart.version')
 .
 helm upgrade endura-sensor \
   "oci://ghcr.io/endurasecurity/helm/${CHANNEL}/endura-sensor" \
   --version "$CHART_VERSION" \
   --namespace endura \
   --values values.yaml
 ```
 .
 Omit `--values values.yaml` when the release does not use a values file. Wait
 for Runtime Sensor Pods to become ready and recheck hook coverage after the
 update.
 .
 ## Uninstall
 .
 ```bash
 helm uninstall endura-sensor --namespace endura
 ```
 .
 The chart does not delete its credential Secret or host files. Remove them only
 after confirming they are no longer required.
 .
 ## Support
 .
 - Review the [Runtime Sensor Helm chart guide](helm/README.md) for detailed
   installation and troubleshooting procedures.
 - Visit [Endura Security](https://endurasecurity.com) for product information.
 - Use the [Endura contact page](https://endurasecurity.com/contact) for
   onboarding and support requests.
 .
 ## License
 .
 Copyright Endura Security. All rights reserved.