Skip to main content
Workload scanning is agentless: Plerion never installs anything on a workload you’re scanning. Instead, it works from a snapshot of the workload’s disk, scans that copy in a dedicated scanning project inside your own Google Cloud organization, and deletes everything it created once the scan finishes. This page covers the mechanics behind that: the flow, the identities involved, and what happens to encrypted disks.

​
The scan flow

Every step below runs as Plerion’s existing tenant service account, using the same keyless Workload Identity Federation chain the GCP organization integration already uses for posture scanning. No new credential type or long-lived key is introduced.
1

Snapshot the target disk

Plerion creates a snapshot of the VM’s disk in place, in the same project and region the VM lives in. Since this is a snapshot, it doesn’t pause, slow, or otherwise touch the running workload. It’s a crash-consistent copy taken out of band from the running workload.
2

Create a scan disk from the snapshot

Plerion creates a new disk from that snapshot inside the scanning project: the same region, a different project, still inside your organization. The disk is sized to match the source disk automatically.
3

Boot a scanner VM

A short-lived scanner VM boots in the scanning project from a stock public Ubuntu LTS image, with the pinned scanning toolchain installed at boot. The scan disk is attached to it read-only.
4

Scan

The scanner VM mounts the disk and runs the scan locally: vulnerabilities, SBOM, and (if enabled) sensitive data. Nothing about this step calls back to any GCP API.
5

Upload results

The scanner VM uploads scan results directly to Plerion over an authenticated, time-limited upload link. Only findings, never disk contents, leave your organization.
6

Clean up

Plerion deletes the scan disk, the scanner VM, and the original snapshot. A backstop sweeper checks for and removes anything left behind by an interrupted scan, so nothing Plerion created outlives its scan.
A scan is bounded by a hard 120-minute timeout: if a scan hasn’t finished by then, Plerion tears it down and marks it failed rather than leaving resources running indefinitely.

​
Where everything lives

Both the snapshot and the scan disk stay inside your Google Cloud organization at every step: same region as the source disk, different project. Nothing is copied to a Plerion-owned project or account. The scanning project itself is created once, during onboarding, and reused for every scan afterward.

​
The identity model

Two identities are involved, and they’re deliberately unequal in what they can do:
  • The tenant service account drives every GCP API call in the flow above: snapshotting, creating the scan disk, booting and deleting the scanner VM. It’s reached only through Plerion’s existing per-tenant WIF chain, which you can revoke at any time by deleting the workload identity pool in your Plerion service project.
  • The scanner VM runs under its own dedicated service account that holds no IAM roles at all. The VM never calls a GCP API directly. Plerion hands it a mounted disk and a short-lived, single-purpose upload token at boot, and that token only authorizes uploading scan results. If a scanner VM were ever compromised, an attacker would get the contents of one scan disk and a token that can only upload results (nothing that reaches your broader GCP environment).
Because the scanning project is yours, you can inspect a running scanner VM in your own console at any time. None of the compute Plerion runs there is hidden from you.

​
Encrypted disks

  • Customer-managed encryption keys (CMEK): the snapshot inherits the source disk’s key, but the scan disk created in the scanning project uses Google-managed encryption instead of your key: Plerion doesn’t need, and isn’t granted, access to your CMEK key to create it. This is a deliberate trade: the disk is short-lived, stays inside your organization, and is deleted once the scan finishes, but its encryption during that window is Google-managed rather than customer-managed. This behavior is disclosed here and in the KMS access step of onboarding.
  • CSEK (customer-supplied encryption keys): Plerion has no way to supply your key at snapshot or disk-creation time, so CSEK-encrypted disks can’t be scanned. See Coverage for how this and other gaps are surfaced.

​
No-trace cleanup, backed by a sweeper

Every resource Plerion creates for a scan (snapshot, scan disk, scanner VM) is named with a plerion-scan- prefix and labeled with the owning tenant, integration, and execution. Normal cleanup runs at the end of every scan; a separate, scheduled sweeper independently lists anything matching that naming and label pattern and removes it if it’s older than expected, so an interrupted scan (a killed execution, a Plerion-side outage) never leaves orphaned resources behind indefinitely. Because everything lives in your own scanning project, you can also see and delete any leftover resource yourself at any time.

​
Next steps