PodWarden
Guides

System Apps

Kubernetes operators that extend PodWarden's capabilities — what they are, how PodWarden detects them, and how to install them

Overview

System Apps are Kubernetes operators that run inside your cluster and extend what PodWarden can do. They are separate from PodWarden itself — you install only the ones you need. PodWarden detects installed operators automatically and enables the corresponding features in the UI.

Without the relevant operator installed, the associated features (e.g. backup scheduling, Helm chart deployment) will not function even if policies are configured.

How PodWarden Detects System Apps

When PodWarden connects to a cluster, it looks for a ConfigMap in each namespace with the label:

podwarden.com/system-app=true

This ConfigMap declares the operator name, version, and capabilities. PodWarden reads it and reflects the status in Settings → System Apps. No polling agent is required — detection happens on each cluster sync.

Available System Apps

Backup Operator

Manages the full backup lifecycle for PodWarden workloads.

What it does:

  • Watches BackupPolicy CRDs created by PodWarden
  • Schedules and executes BackupRun resources on the defined cron schedule
  • Runs Restic inside the cluster to copy volume data to your storage target
  • Applies retention rules and manages RestoreRun resources for data recovery

Required for: the Backups feature. Without this operator, backup policies remain in Pending state and backup runs will fail with "BackupPolicy CRD not found" errors.

Install:

kubectl apply -f https://www.podwarden.com/operators/backup-operator/install.yaml

The Install button in the PodWarden UI for the Backup Operator is not yet functional — clicking it returns an error indicating automated installation is not supported. Use the kubectl apply command above to install the operator directly.

See the Backups guide for full usage documentation.

Admission Webhook

Intercepts direct kubectl operations on PodWarden-managed namespaces and either blocks them or records them as warnings, depending on per-namespace policy.

What it does:

  • Validates CREATE, UPDATE, and DELETE operations against managed namespaces (label podwarden.com/managed=true)
  • Returns a guidance message pointing at the correct PodWarden API endpoint, MCP tool, and UI path
  • Logs every block and every warn to System Messages with full context (resource, operation, user)
  • Supports a time-boxed cluster-wide bypass (max 300 s) for break-glass operations

Required for: keeping cluster state in sync with PodWarden's database when humans or AI agents have raw kubectl access.

Install: Automatically installed on cluster registration. No manual step needed.

See the Admission Webhook guide for the full picture — what gets intercepted, the three supported bypass mechanisms, the deny-message format, and verification commands.

Helm Operator

Manages Helm chart deployments as first-class PodWarden workloads.

What it does:

  • Watches HelmRelease CRDs created by PodWarden
  • Installs, upgrades, and rolls back Helm charts in the cluster
  • Reports release status and history back to PodWarden

Required for: deploying workloads from Helm charts via the PodWarden UI.

Install:

kubectl apply -f https://www.podwarden.com/operators/helm-operator/install.yaml

Or find it in the Hub catalog under System Apps.

Installing via Hub Catalog

  1. Go to Hub in the PodWarden sidebar
  2. Filter by category System Apps
  3. Select the operator you want to install
  4. Choose the target cluster
  5. Click Deploy

PodWarden applies the operator manifest to the cluster and the detection label is registered automatically.

Verifying Installation

After installing, confirm the operator is running:

kubectl -n podwarden-system get pods

Check the ConfigMap that signals detection:

kubectl get configmaps -A -l podwarden.com/system-app=true

In the PodWarden UI, go to Settings → System to see detected system apps and their versions.