Configuration Reference

PandoCore can be configured via Helm values during installation or environment variables at runtime. This reference covers all available options.

Webhook Configuration

The admission webhook (pando-webhook Helm chart) controls automatic sidecar injection cluster-wide:

Per-pod overrides are available via annotations. See Admission Webhook for details.

Portal Integration

Detection events are automatically streamed from sidecars to your PandoCore Portal dashboard. This is enabled by default.

When enabled, the webhook sets PANDO_EVIDENCE_WEBHOOK_URL on each sidecar, authenticated via the license key. Events appear in your portal dashboard.

Alert Integration

PandoCore can send real-time Slack alerts when detections occur. Alerts fire in both alert and enforce modes.

To set up Slack alerts:

1. Create a Slack incoming webhook for your channel
2. Set slackWebhookURL in your Helm values
3. Set defaultMode to alert or enforce

# values.yaml
slackWebhookURL: "https://hooks.slack.com/services/T.../B.../xxx"
defaultMode: alert

In-Cluster Dashboard Configuration

The optional in-cluster dashboard provides real-time debugging visibility. See Dashboard for full documentation.

Sidecar Helm Values

These values are set during helm install or in a values.yaml file:

Required Values

Image Settings

Operating Mode

Detection Thresholds

Sampling

Logging

Resources

Environment Variables

These can be set directly on the sidecar container to override Helm values:

Core Settings

Alert Settings

Graduated Response

By default, drift detections follow a graduated response chain: alert → isolate → terminate. Network isolation denies all egress except DNS (port 53), preventing data exfiltration while keeping the pod reachable for health checks. If drift persists past the escalation timeout, the pod is terminated. If drift subsides, isolation is automatically removed.

Default chains by detection type:

• Drift threshold exceeded: alert → isolate → terminate
• ML anomaly: alert → isolate → terminate
• Integrity violation: alert → terminate (immediate, no isolation)
• Deadman timeout: alert → terminate
• Internal error: alert only

Detection Thresholds

Sliding Window (Adaptive Baseline)

Learning Phase (Threshold Calibration)

Integrity Checks

ML Anomaly Detection

Logging Settings

Configuration Examples

Production Deployment

Recommended settings for production workloads:

# values-production.yaml
licenseKey: "your-license-key"
imagePullSecret: "your-pull-secret"

mode: enforce

thresholds:
  incremental: 0.15
  cumulative: 0.45

logging:
  level: info
  json: true

resources:
  limits:
    cpu: 100m
    memory: 50Mi
  requests:
    cpu: 50m
    memory: 25Mi

Initial Evaluation

Settings for initial deployment and tuning:

# values-evaluation.yaml
licenseKey: "your-license-key"
imagePullSecret: "your-pull-secret"

mode: monitor  # Detect only, don't enforce

thresholds:
  incremental: 0.20  # Less sensitive during evaluation
  cumulative: 0.55

logging:
  level: debug  # More verbose for tuning
  json: true

High-Sensitivity Workloads

For workloads requiring tighter monitoring:

# values-high-sensitivity.yaml
licenseKey: "your-license-key"
imagePullSecret: "your-pull-secret"

mode: enforce

thresholds:
  incremental: 0.10  # More sensitive
  cumulative: 0.35

sampling:
  intervalMs: 50  # Faster sampling

Tuning Thresholds

If you're seeing too many or too few detections, adjust the thresholds:

Runtime Threshold Adjustment

# Adjust thresholds without redeployment
kubectl set env deployment/your-app -c pando-sidecar \
  PANDO_THRESHOLD_INCREMENTAL=0.20 \
  PANDO_THRESHOLD_CUMULATIVE=0.55

Next Steps

• Operating Modes — Understand monitor vs enforce
• Evidence Format — Structure of detection events
• FAQ — Common configuration questions