Forensic Container Checkpointing
Forensic container checkpointing captures the full runtime state (memory and filesystem) of a container when malware is detected. The checkpoint archive is encrypted with AES-256-GCM and stored for later forensic analysis, preserving evidence that would otherwise be lost when the container is terminated or restarted.
This feature uses the Kubernetes Container Checkpoint API (KEP-2008), which is beta since Kubernetes 1.30.
Requirements
| Requirement | Details |
|---|---|
| Kubernetes version | 1.30+ with ContainerCheckpoint feature gate enabled |
| Subscription tier | Team or Enterprise |
| Container runtime | containerd 1.6+ or CRI-O 3.25+ (must support checkpoint/restore) |
| Detection actions | Must be enabled (detectionActionsEnabled: true) |
How It Works
- The scanner detects malware in a running container via ClamAV or the obfuscation scanner.
- If the
CheckpointContainerdetection action is enabled, the scanner calls the kubelet checkpoint API via the Kubernetes API server proxy. - The kubelet creates a tar archive of the container's memory pages and filesystem state.
- The scanner encrypts the archive with AES-256-GCM using a per-customer encryption key.
- The encrypted archive and a metadata JSON file are stored for later retrieval.
Malware detected
→ Scanner calls kubelet checkpoint API
→ Kubelet captures container state (CRIU)
→ Scanner encrypts archive (AES-256-GCM)
→ Archive stored (GCS or local emptyDir)
Tier Availability
| Tier | Forensic Checkpointing | Retention |
|---|---|---|
| Trial | Not available | — |
| Individual | Not available | — |
| Startup | Not available | — |
| Team | Available | 90 days |
| Enterprise | Available | 180 days |
SaaS Configuration
For SaaS customers, forensic checkpointing is configured through the web console:
- Navigate to Scan Configuration in the web console.
- Enable Detection Actions (requires Team or Enterprise tier).
- Enable the Forensic Checkpoint action.
- Optionally enable Dry Run mode to verify behavior before live execution.
SaaS Storage
- Checkpoint archives are uploaded to a per-customer GCS bucket via signed URLs.
- Encryption keys are managed in GCP Secret Manager and delivered to the scanner via the backend API.
- Metadata is stored in Firestore for querying from the web console.
No Helm configuration is required for SaaS checkpointing beyond enabling detection actions in the operator:
scanner:
scanner:
detectionActionsEnabled: true
The backend API handles feature gating and key delivery through the remote config system.
On-Premise Configuration
On-premise deployments store checkpoint archives locally on each node in an emptyDir volume. The operator manages encryption key generation and DaemonSet configuration automatically.
Helm Values
scanner:
scanner:
detectionActionsEnabled: true
forensicCheckpointEnabled: true
checkpointStorageSizeLimit: "10Gi" # Max disk per node (default: 10Gi)
checkpointRetentionDays: 90 # Days before auto-cleanup (default: 90)
| Value | Default | Description |
|---|---|---|
scanner.scanner.forensicCheckpointEnabled | false | Enable forensic checkpointing infrastructure |
scanner.scanner.checkpointStorageSizeLimit | 10Gi | Maximum storage per node for checkpoint archives |
scanner.scanner.checkpointRetentionDays | 90 | Days to retain archives before automatic deletion |
What the Operator Does
When forensicCheckpointEnabled: true, the operator automatically:
-
Generates an encryption key — Creates a Kubernetes Secret (
{scanner-name}-checkpoint-key) containing a cryptographically random 32-byte AES-256 key. The Secret is owned by the GuardimeshScanner CR and garbage-collected when the CR is deleted. -
Adds an emptyDir volume — Attaches an emptyDir volume with
sizeLimitto the scanner DaemonSet. This volume uses zero disk until a checkpoint is written. If the total size exceeds the limit, Kubernetes evicts the pod to protect the host. -
Mounts the encryption key — Mounts the Secret into the scanner container at
/etc/guardimesh/checkpoint-key/encryption-key. -
Sets environment variables — Configures the scanner container:
Variable Value CHECKPOINT_STORAGE_TYPElocalCHECKPOINT_STORAGE_PATH/var/lib/guardimesh/checkpointsCHECKPOINT_ENCRYPTION_KEY_FILE/etc/guardimesh/checkpoint-key/encryption-keyCHECKPOINT_RETENTION_DAYSValue from checkpointRetentionDays
RBAC
Forensic checkpointing requires nodes/proxy: create permission for the kubelet checkpoint API. This is granted automatically when forensicCheckpointEnabled: true is set on the CR, in addition to the pods: patch permission from detectionActionsEnabled.
Storage Sizing
Each checkpoint archive size depends on the container's memory footprint and filesystem state. As a rough guide:
| Container Memory | Approximate Archive Size |
|---|---|
| 128 Mi | 50–150 MB |
| 512 Mi | 200–600 MB |
| 2 Gi | 800 MB–2.5 GB |
Set checkpointStorageSizeLimit based on your expected detection frequency and container sizes. Kubernetes enforces this limit — if exceeded, the scanner pod is evicted and rescheduled, clearing the volume.
Retention and Cleanup
The scanner runs a background cleanup routine that:
- Runs an initial cleanup pass on startup.
- Checks for expired archives every 6 hours.
- Deletes both the encrypted archive (
.tar.enc) and its metadata file (.meta.json) when the retention period has passed.
Archive expiration is calculated at creation time: createdAt + retentionDays.
SaaS Retention
SaaS retention is enforced server-side. Team customers have 90-day retention; Enterprise customers have 180-day retention.