Skip to main content
With GCP workload scanning turned on, you manage it from the GCP organization integration’s detail page: settings, the access command, cost, and turning scanning off or removing it.

​
Where settings live

On the integration’s detail page:
  • Capabilities > Edit opens the Capabilities panel, with the same Workload scanning capability, workload scan type, workload, billing account, networking, and region settings as the wizard.
  • Update Plerion access opens the Plerion access panel with the Script and Terraform tabs. The command shown there is generated for your current settings, so re-running it brings the grants in Google Cloud in line with what you’ve selected.
  • Coverage > Edit opens Manage projects, where you choose which projects the integration covers.
Each project under the organization also has its own Capabilities panel. There you can turn workload scanning off for that project, or narrow its scan types, workloads, and regions below the organization’s settings. A project’s region override can only narrow the organization’s list, not add to it.

​
Re-running the access command

The onboarding script and Terraform template are safe to run again at any time. Re-run them after changing a capability or workload type, or when the Capabilities panel shows the Update Plerion access in Google Cloud warning. Re-running the script:
  • Finds the existing scanning project by the plerion-scan=true label onboarding gave it, and fixes anything missing rather than creating a second project. If it finds more than one project with that label in the organization, it stops and asks you to resolve the duplicate.
  • Re-links the billing account, so passing a different --billing-account moves the scanning project to that account.
  • Creates or removes the type-gated roles and scanner service accounts to match the --workload-types in the generated command (see Changing workload types).
  • Never removes PlerionWorkloadScan or PlerionWorkloadScanSnapshots, the grants that come with the capability itself. See Access and permissions for what each role is.
Re-running Terraform applies the updated variables (enable_workload_scanning, billing_account_id, workload_nat, workload_regions, workload_types) against your existing state. Keep using the same state; to run it again from a fresh state, set scan_project_id to the existing scanning project. Terraform also doesn’t re-link billing on an existing scanning project.

​
Workload regions

Workload regions limits scanning to the regions you list, up to 16. Leave it empty to scan workloads wherever they are. What the setting does depends on your networking mode:
  • Ephemeral external IP: a scope filter only. Plerion creates subnets on demand in whichever region a scan runs.
  • Cloud NAT: also the list of regions where onboarding provisions a subnet, a Cloud Router, and Cloud NAT. At least one region is required, and a workload outside the list isn’t scanned. After adding a region, re-run the access command so it provisions NAT there.
A change takes effect on the next scan run. A run already in progress finishes with the settings it started with.
In Cloud NAT mode, subnet address ranges are assigned by list position. Reordering the list on its own changes nothing, but reordering it while adding or removing a region at the same time can fail with an address collision. Add or remove regions without reordering the rest.

​
Changing workload types

Turning a workload type off in the Capabilities panel stops new scans of that type from the next run. Turning one on starts them from the next run, once any grant it needs exists. Some types come with their own role or scanner identity. Plerion can’t change your organization’s IAM, so creating or removing those is done by the access command, which is generated for the types currently on: Turning off Cloud Run while Cloud Functions (2nd gen) stays on (or the reverse) leaves the shared artifact grant in place, because the remaining type still needs it. See Access and permissions for what each grant allows.
An integration that turned on the Workload scanning capability before newer workload types existed has only Compute Engine instances on. The other types stay off until you turn them on in the Capabilities panel, save, and re-run the access command.

​
Cost

Scanning compute is billed to the scanning project on your own Google Cloud bill. There is no separate Plerion charge for it. Every resource Plerion creates is labeled with the owning tenant, integration, and execution, so you can filter for it in billing reports. The table below estimates one scan run for a project with 10 workloads of each type, at Google’s list prices. Your bill depends on disk sizes, scan duration, region, and any committed-use or free-tier discounts, so treat these as an order of magnitude rather than a quote. Beyond per-run compute:
  • Cloud NAT, if you chose that networking mode, is a standing charge per provisioned region plus data processing, billed whether or not a scan is running. See Google’s Cloud NAT pricing.
  • Ephemeral external IP mode has no standing cost. Nothing stays running between scans.
  • Cloud Run jobs cost nothing while idle.
  • A disk scan run is bounded by a 12-hour timeout, so a single run’s cost has a ceiling.

​
Turning workload scanning off

Turning the Workload scanning capability off in the Capabilities panel stops Plerion from starting new workload scans as soon as you save. A run already in progress finishes and cleans up after itself as usual. It does not delete anything in Google Cloud. The roles stay granted until you remove them, and the scanning project, its network, and any Cloud NAT stay in your organization and keep accruing their standing costs until you delete the project. The panel says so under the heading Access stays granted in Google Cloud.

​
Removing workload scanning entirely

To delete the scanning project and everything in it:
Re-run the onboarding script with --remove-workload-scanning. It deletes the scanning project (network, Cloud NAT, scanner service accounts, and their bindings) and the organization-level PlerionWorkloadScanArtifactPull, PlerionWorkloadScanFunctionSourceRead, and PlerionWorkloadScanImageRead roles and bindings if they exist.It doesn’t remove PlerionWorkloadScan or PlerionWorkloadScanSnapshots, since those belong to the Workload scanning capability rather than the scanning project. The script prints the gcloud commands that remove their bindings. Removing the bindings is what ends the access. The role definitions stay in your organization. A role with no bindings grants nothing, so leaving them is safe. To delete them, run gcloud iam roles delete <role> --organization=<org-id>.
Deleting the GCP organization integration in Plerion doesn’t delete the scanning project or any role in Google Cloud. Plerion has no permission to change your organization’s IAM or delete your projects. Remove workload scanning with one of the methods above first, or afterward.

​
Next step