Frequently Asked Questions

General

What is PandoCore?

PandoCore is a runtime execution-integrity security system for Kubernetes. It monitors containerized workloads for signs of anomalous behavior and responds instantly when detected, providing runtime protection that complements your existing security stack.

How does PandoCore differ from other security tools?

Does PandoCore replace my firewall/WAF/scanner?

No. PandoCore complements your existing security infrastructure. It focuses specifically on runtime execution integrity, detecting issues that occur while code runs. Use PandoCore alongside your existing preventive security measures (firewalls, WAFs, vulnerability scanners, etc.).

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.

What are the resource requirements?

Does PandoCore require code changes?

No. PandoCore deploys as a sidecar container alongside your existing application. You add the sidecar to your deployment manifest. No changes to your application code are required.

How long does deployment take?

Initial deployment (Helm install + adding sidecar to first deployment) typically takes under 5 minutes. See our Getting Started guide.

Operations

What is the "learning phase"?

When a pod starts with PandoCore, the sidecar spends a short window building a per-workload operational profile before it begins detection. During this phase:

• The /readyz endpoint returns 503
• No enforcement occurs, even in enforce mode
• Duration is configurable via PANDO_LEARNING_DURATION_SECONDS (default: 30 minutes)

After learning completes, /readyz returns 200 and full monitoring begins.

How do I know if PandoCore is working?

Check these indicators:

# Sidecar is running
kubectl get pods -l app=your-app -o wide

# Sidecar is healthy
kubectl exec <pod> -c pando-sidecar -- wget -qO- http://localhost:9090/healthz

# Learning complete (returns 200)
kubectl exec <pod> -c pando-sidecar -- wget -qO- http://localhost:9090/readyz

# View detection metrics
kubectl exec <pod> -c pando-sidecar -- wget -qO- http://localhost:9090/metrics | grep pando_

What happens if the sidecar crashes?

If the PandoCore sidecar crashes, your application container continues running unprotected. Kubernetes will automatically restart the sidecar container based on its restartPolicy. The new sidecar instance will re-establish a baseline through the learning phase.

Configure liveness probes to ensure Kubernetes restarts unhealthy sidecars promptly:

livenessProbe:
  httpGet:
    path: /healthz
    port: 9090
  initialDelaySeconds: 5
  periodSeconds: 10

What if PandoCore keeps terminating my pods?

If you're experiencing unexpected pod terminations:

1. Switch to monitor mode immediately:

   kubectl set env deployment/NAME -c pando-sidecar PANDO_MODE=monitor

2. Review the evidence: Check logs to understand what triggered the detection
3. Adjust sensitivity: Your workload may have legitimate behavioral variance that requires a more permissive setting
4. Trigger re-learning: If your application behavior has legitimately changed

See Emergency Procedures for detailed steps.

How do I tune the detection sensitivity?

Use PANDO_SENSITIVITY (default 2.0, or 3.0 for JIT and database runtimes the webhook auto-detects). Raise it for noisy workloads, lower it to catch subtler anomalies. Start in monitor mode before enabling enforcement.

Detection

What does PandoCore detect?

PandoCore detects runtime behavioral anomalies indicative of compromise: deviations from a workload's learned operational profile that signature-based tools typically miss. It complements, rather than replaces, your existing prevention stack.

What doesn't PandoCore detect?

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

• Pre-execution issues: Supply chain compromises, malicious images, vulnerabilities in dependencies (use image scanning)
• Application logic bugs: SQL injection, authentication bypass, business logic flaws (use application security testing)
• Network attacks: Man-in-the-middle, DDoS, DNS spoofing (use network security tools)

Can PandoCore cause false positives?

PandoCore is designed to minimize false positives by profiling each workload individually. Legitimate behavioral changes (new deployments, load spikes, batch jobs) may still trigger detections.

Best practices to avoid false positives:

• Run in monitor mode for at least one week before enabling enforcement
• Trigger re-learning after deployments that significantly change behavior
• Adjust sensitivity based on your workload's characteristics

Security

What permissions does the sidecar need?

The PandoCore sidecar requires minimal Kubernetes RBAC permissions:

• get on pods in its namespace (to read pod info)
• delete on pods in its namespace (to terminate compromised pods in enforce mode)

These permissions are namespace-scoped. The sidecar cannot access resources in other namespaces.

Can an attacker disable PandoCore?

The sidecar runs in a separate container within the same pod. An attacker would need container escape capabilities to reach the sidecar. If they can escape the application container, PandoCore may detect the anomalous behavior (process/memory changes) before the attacker can disable protection.

If an attacker has root access on the node, they could potentially kill the sidecar process. This is a limitation of software-based monitoring.

Where is evidence stored?

Evidence is emitted to multiple channels:

• stdout: Captured by your log aggregator (Fluentd, Filebeat, etc.)
• Kubernetes Events: Stored in the Kubernetes API (survives pod deletion)
• Prometheus metrics: Time-series data in your metrics stack

Evidence is externalized before pod termination to ensure it's preserved.

Troubleshooting

Sidecar logs show "learning" for a long time

The default learning phase is 30 minutes. During this time, the sidecar is in monitor-only mode. For slow-warmup workloads you can extend the window with PANDO_LEARNING_DURATION_SECONDS and PANDO_LEARNING_MIN_SAMPLES.

Detections happening but pods not terminating

Check the operating mode:

kubectl get pod <pod> -o jsonpath='{.spec.containers[?(@.name=="pando-sidecar")].env}' | jq .

If PANDO_MODE=monitor or alert, PandoCore detects but does not enforce. Change to enforce for active protection.

Grafana shows no PandoCore data

1. Verify Prometheus is scraping the sidecar: Check Prometheus targets UI
2. Verify the sidecar metrics port is exposed: Should be port 9090
3. Check that Grafana's data source is correctly configured

How do I get support?

For pilot customers, contact PandoCore support directly with:

1. Evidence JSON from the detection event
2. What your workload was doing at the time
3. Your current sensitivity setting
4. Sidecar logs from around the time of the issue

Still Have Questions?

If your question isn't answered here, contact us and we'll be happy to help.