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 enters a learning phase where it observes your application's normal behavior and establishes a baseline. During this phase:

• The /readyz endpoint returns 503
• Detection occurs but no enforcement (even in enforce mode)
• Duration is configurable (default: 10 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 current drift scores
kubectl exec <pod> -c pando-sidecar -- wget -qO- http://localhost:9090/metrics | grep pando_drift

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 thresholds: Your workload may have legitimate behavioral variance that requires higher thresholds
4. Trigger re-learning: If your application behavior has legitimately changed

See Emergency Procedures for detailed steps.

How do I tune the detection sensitivity?

Adjust these environment variables:

Start with monitor mode, observe detection events, then tune thresholds before enabling enforcement.

Detection

What does PandoCore detect?

PandoCore monitors multiple dimensions of workload behavior and detects significant deviations from established baselines:

• Memory anomalies: Unusual heap growth, allocation patterns
• Process anomalies: Thread count changes, file descriptor anomalies, unexpected child processes
• Timing anomalies: Unusual execution patterns
• System anomalies: CPU and I/O pattern deviations

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 through adaptive learning. The learning phase establishes a baseline specific to your workload's normal behavior. However, legitimate behavioral changes (new deployments, load spikes, batch jobs) may 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
• Tune thresholds 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 10 minutes. During this time, the sidecar is in monitor-only mode. If you need to shorten this for testing, you can reduce the learning duration (not recommended for production).

Drift scores are high but no termination

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 threshold settings
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.