Kubesentry Product

Mid-size SaaS teams running Kubernetes face a security gap that CSPM tools and cloud-native logs cannot close. Configuration scanning tells you what your cluster looks like at rest. It does not tell you what is happening inside your containers right now. When a container exec spawns an unexpected shell, when a service account token is read and immediately used to call the Kubernetes API from a new network path, when a cron job inside a pod starts scanning internal subnets — none of those events appear in configuration audit logs. They appear in runtime telemetry. Kubesentry is purpose-built to collect, baseline, and alert on exactly that layer for teams without a dedicated SIEM or a full-time threat analyst.

Runtime Security Capabilities

Six core detection engines give your team full-spectrum runtime visibility inside every Kubernetes pod — from syscall collection to MITRE ATT&CK classification — without sidecars, image changes, or manual rule tuning.

eBPF Runtime Telemetry

Collect kernel-level system-call streams from every container without sidecars or image changes

Our eBPF sensor attaches to the kernel at the system-call boundary and streams every process exec, file open, network connect, and socket operation from every container on the node. No image changes, no DaemonSet sidecars per workload, no application instrumentation. The sensor runs as a single privileged DaemonSet pod and is operationally invisible to the workloads it monitors.

eBPF Runtime Telemetry

Behavioral Baseline per Workload

Learn each deployment's normal system-call profile to catch anomalies at runtime

After a configurable learning window of seven to fourteen days, Kubesentry builds a per-deployment behavioral fingerprint: which binaries each container is allowed to exec, which network destinations it connects to, which file paths it reads from. Deviations from that baseline generate alerts with full syscall context, not raw log lines.

Behavioral Baseline per Workload

MITRE ATT&CK Tactic Classification

Map every runtime event to a MITRE ATT&CK for Containers tactic in real time

Every alert carries a MITRE ATT&CK for Containers tactic and technique label — Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Exfiltration, or Impact. Your on-call engineer sees not just what happened but what stage of an attack chain it represents, so triage takes minutes instead of hours.

MITRE ATT&CK Tactic Classification

Service Account Abuse Detection

Detect service account token misuse that deviates from declared RBAC scope

Kubesentry correlates service account token reads with outbound API calls in real time. When a pod reads its mounted token and then immediately makes a Kubernetes API call to a namespace or resource outside its declared RBAC scope, the event pair is flagged as a service account abuse candidate with the specific role binding mismatch highlighted.

Service Account Abuse Detection

Cryptomining and Exec Anomaly Detection

Flag unexpected exec patterns and outbound network connections consistent with cryptomining

Cryptomining workloads exhibit distinctive syscall and network patterns: unexpected process exec chains, sustained high-CPU syscall bursts, and outbound connections to mining pool IP ranges. Kubesentry detects these patterns using a combination of behavioral deviation scoring and a curated block list of known mining infrastructure, without requiring signature updates.

Cryptomining and Exec Anomaly Detection

Wiz and CrowdStrike Context Enrichment

Merge runtime threat events with cloud vulnerability and endpoint posture context

When Kubesentry detects a runtime threat event, it automatically queries the Wiz Security Graph API and the CrowdStrike Falcon API to pull the vulnerability posture and endpoint risk score for the affected workload. Your alert arrives pre-enriched with CVE context and endpoint posture, so you know whether the compromised container was already a high-risk asset before the incident started.

Wiz and CrowdStrike Context Enrichment

From Helm Install to Live Detection in Four Hours

Kubesentry deploys in a single afternoon. No professional services engagement, no multi-week proof-of-concept, no changes to your application images or CI pipeline. The entire deployment is managed through a Helm chart with sensible defaults for mid-size Kubernetes clusters.

01

Install the Helm Chart

Run helm install kubesentry kubesentry/kubesentry -n kubesentry-system --create-namespace to deploy the eBPF sensor DaemonSet and the detection engine pod to your cluster. The chart configures kernel version detection automatically and selects the right eBPF probe for your node OS.

02

Connect Your Alert Destination

Configure your Slack channel, PagerDuty service key, or webhook endpoint in the Kubesentry dashboard. Alerts route immediately. You can filter by severity, namespace, or MITRE tactic from the alert routing settings panel before baselining is complete.

03

Let the Baseline Build

Over seven to fourteen days the detection engine learns the normal syscall and network profile for each Deployment and DaemonSet in your cluster. You can watch baseline coverage grow per-namespace in the dashboard. No manual rule writing is required during this period.

04

Start Receiving Actionable Alerts

Once baselining completes, every deviation from learned workload behavior generates a structured alert with MITRE tactic context, the specific syscall sequence that triggered it, the affected pod and namespace, and the Wiz and CrowdStrike enrichment data for that workload. No tuning required out of the box.