Frequently Asked Questions

Common questions about PandoCore runtime protection.

General

What is PandoCore?

PandoCore is a runtime execution-integrity security system for Kubernetes. It watches containerized workloads as they run, detects behaviour that diverges from what each workload established as normal, and can respond, complementing your existing security stack rather than replacing it.

How does PandoCore differ from other security tools?

Does PandoCore replace my firewall, WAF or scanner?

No. PandoCore focuses specifically on runtime execution integrity, which means issues that appear while code is running. Use it alongside your existing preventive measures.

Deployment

What Kubernetes versions are supported?

PandoCore supports Kubernetes 1.25 and later. It has been tested on:

• GKE (Google Kubernetes Engine)
• kind (local development)
• minikube (local development)

EKS and AKS support is expected but not yet validated.

Will it run on GKE Autopilot or EKS Fargate?

No. The sensor runs as a hostPID DaemonSet with a host path mount, and neither is permitted on those platforms, so there is no install path on either. This is a change from the deprecated sidecar, which ran unprivileged. See Production Hardening for what the sensor runs as.

What are the resource requirements?

Per node, not per workload. One sensor pod runs on each node whatever that node is running, so the figure does not grow with your deployment count.

Measured warm and enforcing on the shipping build, across two runs: a 130.4 mCPU p95 with a 106.9 MiB working set over a 24-hour warm window, and 127.3 mCPU with 110.6 MiB over a 34-hour run. The working-set slope was flat in both, at -0.015 and +0.008 MiB per hour, so there is no leak to grow into the limit. There was no CFS throttling, no OOMKill, and no sensor restart in 77 hours. The request is sized for the 70-pod cap rather than for the engine counts these runs carried. The controller is separate and smaller.

Does PandoCore require code changes?

No, and it requires no changes to your pod specifications either. The sensor runs beside your workloads rather than inside them, so there is nothing to add to a deployment manifest and nothing to label.

How long does deployment take?

Two Helm installs, controller first. Detection does not begin at install time: see the learning phase question below for the warm-up, and the Getting Started guide for the steps.

Operations

What is the "learning phase"?

When the sensor starts watching a workload, it spends a short window building an operational profile for it before detection begins. During that window:

• /readyz returns 503
• Nothing can fire, whatever the mode
• The window is 30 minutes and at least 900 samples, whichever is later

After it completes, /readyz returns 200 and the deterministic checks are armed. Two behavioural scales keep warming past that point:

• The short scale needs roughly 100 minutes from a cold start
• The long scale needs roughly 10 hours

A scale that is not yet warm does not contribute, so the fuller detection envelope is in place around 10 hours after a workload is first watched, not at install time. Longer-period scales keep warming for days beyond that.

How do I know if PandoCore is working?

# One sensor per node, all Ready
kubectl get pods -n pando-system -l app.kubernetes.io/name=pando-node-sensor -o wide

# Armed and watching (200 once learning completes)
kubectl exec -n pando-system <sensor-pod> -- wget -qO- http://localhost:9090/readyz

# Engine count, license ceiling, node clamp
kubectl exec -n pando-system <sensor-pod> -- wget -qO- http://localhost:9090/status

# Detection metrics
kubectl exec -n pando-system <sensor-pod> -- wget -qO- http://localhost:9090/metrics | grep pando_

Select on app.kubernetes.io/name=pando-node-sensor rather than on the protect label: the sensor's own pod carries pandocore.io/protect: "false", so a selector written against protect=true matches nothing and reports a clean scrape of nothing.

Is every pod on a node watched?

Not necessarily, and the exceptions are worth knowing. Each sensor runs at most 70 monitored pods per node by default. Pods beyond that cap get no engine and are shed in a stable order, so the same pods stay unwatched across restarts rather than rotating. The gauge pando_node_sensor_pods_unmonitored{reason="cap"} reports them and the chart ships an alerting rule for it.

Four classes are also excluded whatever the configuration says: the sensor's own pod, hostPID pods, hostNetwork pods, and any pod labelled pandocore.io/protect: "false". Eleven namespaces are excluded by default.

What happens if a sensor crashes?

The workloads on that node keep running, unwatched, and Kubernetes restarts the sensor pod. The new sensor re-profiles the workloads on its node. Your application containers are unaffected either way, because nothing of PandoCore's runs inside them.

Note that a sensor refusing to monitor is not the same as crashing: it parks instead of exiting, and /healthz deliberately keeps returning 200 so the kubelet does not crash-loop the refusal logs away. /readyz is what reports it, so alert on readiness rather than on pod phase.

What if PandoCore keeps isolating my pods?

1. Release the pod now by deleting the NetworkPolicy, which is an ordinary Kubernetes object:

   kubectl delete networkpolicy -n <ns> -l pandocore.io/isolation=<pod>

2. Stop it acting on that workload while keeping it watched:

   kubectl annotate deployment <name> pandocore.io/mode=monitor --overwrite
   kubectl rollout restart deployment/<name>

3. Review the evidence in the portal to understand what triggered it
4. Loosen sensitivity for that namespace in a PandoCorePolicy if it recurs

See Emergency Procedures for the full set of levers.

How do I tune the detection sensitivity?

Per namespace, in a PandoCorePolicy: sensitivity: low | medium | high, where a higher preset is a tighter gate, plus thresholds for finer numeric control. Thresholds can only tighten what learning derived, never loosen it; use sensitivity to loosen. PANDO_SENSITIVITY still exists but belongs to the DaemonSet on the node sensor, so it applies node-wide rather than to one workload. See CRD Policy.

Detection

What does PandoCore detect?

Runtime behavioural divergence from a workload's learned operational profile, which is the class of problem signature-based tools tend to miss. It complements your prevention stack rather than replacing it.

What doesn't PandoCore detect?

PandoCore focuses on runtime execution integrity. It does not detect:

• Pre-execution issues: supply chain compromise, malicious images, dependency vulnerabilities (use image scanning)
• Application logic flaws: SQL injection, authentication bypass, business logic bugs (use application security testing)
• Network attacks: man-in-the-middle, denial of service, DNS spoofing (use network security tools)

Can PandoCore cause false positives?

Yes, and profiling each workload individually is how it keeps them low rather than how it eliminates them. Legitimate behavioural change, such as a new release, a load spike or a batch job, can trigger a detection.

What helps:

• Spend time on a free license first, where the ceiling is alert and nothing is contained, and read what it reports before raising it
• Expect a workload to re-profile after a deployment that genuinely changes its behaviour
• Set sensitivity per namespace to match the workload

Security

What permissions does the sensor need?

The sensor holds one ClusterRole. It contains exactly:

• get, list, watch on pods
• create on events
• create, delete, get on networkpolicies
• get on replicasets, statefulsets and daemonsets
• list on pandocorepolicies
• list on services
• get on namespaces, restricted to kube-system

Three grants are withheld by name, each with its reason recorded in the chart: pods: patch, pods: delete and endpoints: get. The sensor cannot delete a pod, and that is a property of the grant and of the code, not a configuration choice.

The cluster-wide secrets get that per-namespace policy integrations need does not sit on the sensor at all. The destinations mirror is a separate unprivileged Deployment so that grant is not held by a hostPID pod running as uid 0 on every node.

Does the sensor run privileged?

It runs as a hostPID DaemonSet, as uid 0, with CAP_SYS_PTRACE, mounting the node's /proc read-only and a host path for its own state. That is a real increase in node surface compared with the deprecated sidecar, which ran unprivileged, and it is stated plainly rather than buried: see the trust center.

On uid 0 specifically, it is load-bearing rather than inherited. CAP_SYS_PTRACE becomes effective through the uid-0 path, and the alternative is a file capability raised in-process with privilege escalation enabled, which is more escalation surface than root with escalation switched off. Of the two postures that work, this is the narrower one.

Can an attacker disable PandoCore?

The sensor runs outside the pods it watches, on the node, so an attacker who compromises an application container is not in the same container, the same pod, or the same process namespace as the thing watching them. Escaping the container does not by itself reach the sensor, and the behaviour involved in trying is the kind of divergence the sensor exists to notice.

An attacker with root on the node can stop the sensor process. That is a genuine limit of software monitoring on a compromised host, and it is why the chart ships an absence alerting rule: a sensor that has gone quiet is the one condition no self-report can distinguish from healthy, so it is alerted on from outside.

Where is evidence stored?

• The controller: records are delivered to it over mTLS and written to a durable spool before it acknowledges them, so evidence does not die with the pod that produced it
• Your destinations: the controller owns delivery onward to SIEM, Slack, syslog or your own webhook
• Kubernetes events: stored in the API and surviving pod deletion
• stdout: picked up by your log aggregator
• Prometheus: metrics in your own metrics stack

Each record is signed with Ed25519 over a digest of its canonical form, and records are linked by previous_hash into a chain, which makes later tampering detectable rather than preventing it. See Evidence Format.

Troubleshooting

A workload has shown "learning" for a long time

The window is 30 minutes and at least 900 samples, whichever is later, so a workload that is sampled slowly takes longer than 30 minutes. For slow-warmup workloads the window can be extended with PANDO_LEARNING_DURATION_SECONDS and PANDO_LEARNING_MIN_SAMPLES on the DaemonSet, which applies node-wide.

Detections are happening but nothing is being contained

Check the ceiling before the mode, because the ceiling is the more common answer:

kubectl exec -n pando-system <sensor-pod> -- wget -qO- http://localhost:9090/status

A free license is held to alert and contains nothing, which is the tier working as intended rather than a misconfiguration. If the ceiling permits isolation, check the workload's mode annotation, and remember it is read when the sensor starts watching a pod, so a recent change may not have reached pods already running. A clamped node is held to monitor by a portal-side verdict and does not alert either.

Grafana shows no PandoCore data

1. Check your Prometheus job selects app.kubernetes.io/name=pando-node-sensor. A job written against the protect label matches nothing and looks healthy
2. Confirm the metrics port is 9090
3. Confirm Grafana's data source

How do I get support?

Contact support with:

1. The evidence record from the detection
2. What the workload was doing at the time
3. Your sensitivity setting, and the policy it came from
4. Sensor logs and /status output from around the time

Still Have Questions?

If your question is not answered here, contact us and we will be happy to help.