Skip to main content
Workload scanning is a capability of the existing GCP organization integration, so there’s no separate integration to create. Turning it on adds one step and one script flag to onboarding you’ve likely already done.
If your GCP organization is already connected to Plerion, use the edit dialog on the integration’s detail page instead of starting a new integration. The same wizard steps below appear there.

​
Step 1: Turn on CWPP in the capabilities step

1

On the Plerion dashboard, go to Settings > Integrations

Open your GCP organization integration, or start a new one and reach the capabilities step.
Sidebar navigation with Settings expanded and Integrations highlighted
2

Turn on Cloud workload protection platform (CWPP)

  • Cloud security posture management (CSPM) and Cloud infrastructure entitlement management (CIEM) are always on.
  • Turn on Cloud workload protection platform (CWPP) to reveal the workload scanning step below.
  • Choose a Cloud Key Management Service (KMS) access mode (All keys or Selected KMS keys) as usual. This is unchanged by workload scanning. See the GCP integration overview for what each mode grants.

​
Step 2: Configure workload scanning

This step only appears when CWPP is on, and asks for scan capabilities, workload types, a billing account ID, and a networking mode:
  • Scan capabilities: Vulnerability and SBOM scanning are on by default. Sensitive data scanning is off by default: turn it on if you want secrets on disk (API keys, tokens, private keys) reported too.
  • Workload types: Compute Engine is pre-checked and is the only workload type available in v1. Other types will appear here as they’re added.
  • Billing account ID (XXXXXX-XXXXXX-XXXXXX): required. Enter the billing account the scanning project should link to. See Prerequisites for the permission this needs. The field links directly to the Google Cloud billing console and shows the gcloud billing accounts list command as a hint.
  • Networking mode: choose one.
    • Ephemeral external IP (default): no standing network cost. The scanner VM gets a temporary external IP for outbound traffic only; nothing can reach it inbound.
    • Cloud NAT: required if your organization blocks external IPs (constraints/compute.vmExternalIpAccess). Adds a standing per-region monthly charge plus data processing on your own bill, at Google’s Cloud NAT pricing. Choosing this mode also requires selecting which regions to provision Cloud NAT in.
  • Workload regions (optional): limit scanning to specific regions. Leave empty to scan workloads in every region where they’re found. This is a scan-scope filter only, and unlike the AWS service account model, it doesn’t provision any region-specific infrastructure up front.
Click Next once these are filled in. All of these fields are editable later from the integration’s edit dialog.

​
Step 3: Grant access

Same Script or Terraform tab as the base integration, with new flags added automatically:
The generated command now includes --enable-workload-scanning --billing-account <id> (and --nat if you chose Cloud NAT). Paste and run it in Google Cloud Shell as before.Before creating anything, the script checks that the billing link will succeed and that the effective vmExternalIpAccess policy matches your chosen networking mode, and fails with a specific message if either check doesn’t pass.
The script’s output ends with the ID of the scanning project it created. Plerion also stores this ID against the integration once registration completes.

​
Step 4: Verify setup

Once registration completes, Plerion runs two checks automatically, and you can re-run either from the integration detail page’s Re-check setup action:
  • Static probe: confirms the scanning project exists, billing is linked, the network is in place, the scanner service account exists, and the tenant service account’s role is bound. If any check fails, the integration page names exactly which one and why.
  • Canary: once the static probe passes, Plerion boots one minimal scanner VM in the scanning project (no disk attached), confirms it can reach Plerion and report in, then deletes it. This proves quota headroom, permissions, and network egress all work under your organization’s actual policies, and costs only cents.
Once the canary passes, the workload scanning badge on the integration shows setup verified: first scan runs after the next posture scan.
If you turned on CWPP before workload scanning existed, the badge shows a re-run required notice. The access toggle alone doesn’t create the scanning project. Re-run the script or terraform apply with the new flags to finish setup.

​
First-scan expectations

Workload scanning doesn’t run on its own schedule. It fires after the next CSPM scan of each project completes, so the first findings typically land within one scan interval (up to 24 hours on a default daily schedule).

​
Next steps