Skip to main content
Migration Notice
We're migrating documentation from the old portal into this one. Some things may look a little different or out of place in the meantime — we know, and we're working to get it right. If something's unclear or doesn't look right, let us know.

Lifecycle Watch - Inventory Security Surface

Lifecycle Watch presents the Kubernetes inventory as a security surface for short-lived and destroyed resources. Instead of browsing raw snapshots, you see the pods, PVCs, and buckets that appeared and then disappeared, lived only briefly, or were repeatedly re-spawned. These patterns often accompany reconnaissance, data exfiltration, attacker cleanup, or unstable workloads.

The page aggregates the pod, PVC, and bucket snapshot history captured by the K8 scanner into three lifecycle signals over a look-back window.

Where: Data Security Posture > K8 inventory · lifecycle security

For the page layout, controls, and deep links, see Lifecycle Watch.

Time range​

The Range selector at the top drives the entire surface, and changing it re-queries all three signals.

RangeUse
Last 24hDefault. The tightest, most actionable window.
Last 48hShort incident reviews.
Last 7dMulti-day reviews.
Last 30dThe widest window, useful for slow-burn investigations.

A wider window returns more history but is more expensive on high-volume clusters.

Lifecycle signals​

Three threat tiles show the deleted, ephemeral, and recreated totals, and a card under each tile lists the matching resources.

Deleted​

Pods, PVCs, or buckets that were observed within the window but stopped appearing in the most recent scans, which means they were destroyed. This is the primary signal for data loss and for attacker cleanup, where evidence is destroyed after an intrusion.

Each row shows the namespace (or device, for buckets), the name, when it was first and last seen, and how long it existed. For pods, a row also shows the short pod UID and, when recorded, the deleter as ✕ <user>.

Ephemeral​

Short-lived pods and PVCs whose total lifespan (last seen minus first seen) is below the ephemeral threshold. Very short-lived resources are a classic reconnaissance or exfiltration signal: an attacker starts a throwaway pod, mounts storage, copies data out, and removes it before the next scan would normally notice.

Recreated​

Pods only. The same pod name was observed under two or more distinct pod UIDs within the window. Each UID is a separate incarnation, so a high incarnations count, shown per row, means the workload was repeatedly destroyed and re-spawned. Causes include churn, crash-loops, redeploys, and attacker re-spawn.

Controls​

The Ephemeral ≤ N min cutoff, the resource-type filter, the cluster scope chips, and Refresh work as described in Lifecycle Watch.

Buckets apply only to the Deleted signal, Ephemeral applies to Pods and PVCs, and Recreated applies only to Pods. A deleted resource that lived less than the ephemeral cutoff is also flagged ephemeral.

Secondary tools​

The Snapshot Timeline and Pod Lifecycle Search panels are collapsed by default. See Inventory - Snapshot Timeline, Snapshot Diff, and Pod Lifecycle Search.

Scan cadence and granularity​

All three signals come from periodic inventory snapshots, not a real-time event stream. Detection resolution is bounded by scan cadence and by the Snapshot Frequency setting (see K8 Inventory Snapshots):

  • A resource is flagged as deleted only once its last snapshot is older than the most recent overall scan. A short grace period ensures a resource present in the newest scan is never flagged by mistake.
  • A resource created and destroyed entirely between two scans is never observed and cannot appear here. Ephemeral detection catches short-lived resources that survived at least one scan.
  • Reported lifespan is the span between the first and last snapshot that saw the resource, not its true lifetime. Actual creation and deletion can be up to one scan interval earlier or later.

For forensics finer than the scan interval, correlate with the audit event stream on the File Activity page rather than relying on snapshot lifecycle alone.

Workflows​

Hunt for attacker cleanup after a suspected intrusion​

  1. Set Range to the window that covers the incident, for example Last 48h.
  2. Read the Deleted card for pods, PVCs, and buckets that vanished in that window.
  3. For a suspicious pod, note the ✕ <user> deleter badge and the last-seen time.
  4. Open File Activity and query that namespace and path around the last-seen time to see what the resource touched before it was destroyed.

Spot short-lived exfiltration pods​

  1. Stay on Last 24h and set Ephemeral ≤ to 5 to 15 minutes.
  2. Read the Ephemeral card for pods that lived only minutes.
  3. Cross-check the Recreated card. A name that also re-spawns under new UIDs is a stronger evasion signal.

Tips​

  • Snapshot history is bounded by the retention period, and bucket snapshots have their own retention. The Last 30d window can therefore show fewer bucket rows than pod and PVC rows near its edge.
  • Start at Last 24h with a low ephemeral threshold (5 to 15 minutes) to surface the most suspicious transient pods, then widen the window to see whether the pattern repeats.
  • A pod that appears in both Recreated (high incarnations) and Ephemeral (each incarnation short-lived) is a strong re-spawn or evasion indicator worth investigating.