PandoCore Documentation
Everything you need to deploy, configure, and operate PandoCore runtime protection.
PandoCore is a runtime execution-integrity security system for Kubernetes. It watches your containerized workloads as they run and responds when behaviour diverges from what that workload established as normal, adding a layer of protection that operates during execution rather than before it.
Start Here
Getting Started
Two Helm charts, one sensor pod per node, nothing to label.
Configuration
Reference for the chart values and what each one changes.
Operating Modes
Monitor, alert and isolate, and what sets the ceiling.
Emergency Procedures
How to stop it quickly.
What PandoCore Does
PandoCore installs as a node sensor: one DaemonSet pod per node that watches the workloads already running there, opt-out. Nothing is injected into your pods. When behaviour diverges from a workload's profile, PandoCore can:
- Monitor: detect and record evidence, taking no outward action
- Alert: detect and notify, through destinations configured on the controller
- Isolate: detect, alert, and contain the pod with a NetworkPolicy that denies egress except DNS, released automatically when behaviour recovers and without restarting the workload
- Debug: verbose logging for troubleshooting and tuning
Isolate is the ceiling of the supported install. See Operating Modes for what sets it.
Architecture Overview
Two components, both cluster-wide, installed once:
The sensor runs as a hostPID DaemonSet and reads the node's process namespace, so it observes the workloads on its node without running inside any of them and without any change to your application. That topology is also a real privilege posture: see Production Hardening for what it runs as, and the trust center for what it is not granted.
Key components
| Component | Description |
|---|---|
| Node sensor | A DaemonSet, one pod per node. Watches the workloads on its node and decides responses |
| Controller | A StatefulSet that receives evidence, spools it durably, and owns every outbound destination |
| Destinations mirror | An unprivileged Deployment that resolves per-namespace policy integrations for the controller |
| PandoCorePolicy CRD | Declarative per-namespace configuration for GitOps workflows |
| Metrics endpoint | Prometheus-compatible /metrics, plus shipped PrometheusRules for coverage and liveness |
| Evidence output | Signed, hash-chained JSON records suitable for SIEM integration |
How It Works
- The sensor picks up the pod. No label, patch or restart is involved; a pod opts out with
pandocore.io/protect: "false"rather than opting in - Learning window. PandoCore builds a profile for that workload over 30 minutes and at least 900 samples, whichever is later
- Detection. Deterministic checks arm when learning completes; the behavioural checks that rest on longer baselines keep warming for hours after that. Findings are classified by severity
- Response. According to the workload's mode and the license ceiling: record it (monitor), notify (alert), or contain the pod with a NetworkPolicy (isolate)
Integration With Your Stack
- Observability: Prometheus metrics, with alerting rules shipped in the chart
- Log aggregation: structured JSON evidence for Splunk, Elastic, Datadog and syslog
- Kubernetes events: detections and responses emit events for audit trails
- Alerting: use your existing alerting on PandoCore's metrics
PandoCore needs no modification to your application code, no SDK and no rules to write. It also needs nothing added to your pod specs, since the sensor runs beside your workloads rather than inside them.
The node sensor has been validated across 3,966 engine-hours on GKE, cumulative rather than one unbroken run, against production-representative synthetic workloads, with zero false isolations from sensors that were permitted to isolate, 1,231 engine-hours of them on the exact build we ship. A zero is an upper bound rather than a rate: at most one false isolation in 1,324 engine-hours, at 95 percent confidence. See the full validation results.
Requirements
| Requirement | Version |
|---|---|
| Kubernetes | 1.25+ |
| Helm | 3.0+ (3.14+ recommended, for --reset-then-reuse-values) |
| kubectl | Compatible with your cluster version |
| Nodes | Nodes you control. hostPID is required, so GKE Autopilot and EKS Fargate have no install path |
Next Steps
Start with the Getting Started guide.