Skip to main content
With GCP workload scanning, Plerion creates billed infrastructure in your Google Cloud organization, so it needs a few things a posture-only GCP integration doesn’t. Check the items below before you start.

​
Before you begin

  • Someone who can run onboarding. The onboarding script or Terraform template runs with the same Organization Admin (or equivalent) access the organization integration needs, plus the billing role below. In Google Cloud Shell, the script uses your signed-in account. For Terraform, your Application Default Credentials must belong to that account.

​
Billing account

Onboarding creates a dedicated scanning project and links it to a billing account you choose. All scanning compute is billed there.
  • Find the billing account ID with gcloud billing accounts list or in the Google Cloud billing console. The format is XXXXXX-XXXXXX-XXXXXX.
  • The person running onboarding needs Billing Account User (which carries billing.resourceAssociations.create) on that billing account. At many organizations this is held by a different team than Organization Admin, so arrange it ahead of time.
The script checks that it can read the billing account before it creates anything. If it can’t, it stops and names the roles it needs. Google Cloud only checks billing.resourceAssociations.create when the project is linked. A caller who can view the account but lacks Billing Account User fails a few minutes later, at the link step, with a PERMISSION_DENIED error from gcloud. Grant the role and re-run the same command.

​
APIs

Onboarding enables the APIs it needs. You don’t enable anything by hand. The organization integration already enables the IAM, Security Token Service, Resource Manager, Service Usage, and Organization Policy APIs in the Plerion service project. Nothing is enabled in the projects whose workloads are scanned. A workload project does need the Compute Engine API for its instances, images, and groups to be scanned. A project that has never enabled compute.googleapis.com is skipped for workload scanning, while its posture scanning continues.

​
Organization policies

Some organization policy constraints block parts of the scanning flow. Onboarding checks one of them. Plerion checks all four at the start of every scan run and fails the run for that project if one blocks it. The failed run appears on the project’s Workload scans tab, and the blocking constraint is recorded in Plerion’s logs, which support can check.
The scanner VM’s image can come from two projects. projects/ubuntu-os-cloud is Google’s public Ubuntu image; it’s required regardless of policy, since it’s the fallback path every scan must be able to take. projects/pln-public-artifacts is Plerion’s pre-built image with the scanning toolchain already installed; allowing it is optional and only makes scans start faster. An organization that restricts image projects to its own golden images must still allow projects/ubuntu-os-cloud, a pre-existing requirement independent of this option.
The script’s check of compute.vmExternalIpAccess reads the organization-level effective policy only. A folder- or project-level policy that denies external IPs isn’t detected until a scan runs. Either way, the fix is to switch to Cloud NAT.
Onboarding also creates firewall rules on the scanning project’s network that deny all ingress and allow egress on TCP port 443 only. If your organization applies hierarchical firewall policies, make sure they allow HTTPS egress from the scanning project.

​
VPC Service Controls

Plerion doesn’t check VPC Service Controls. If a workload project sits inside a service perimeter that restricts compute.googleapis.com, artifactregistry.googleapis.com, or cloudfunctions.googleapis.com, Plerion’s calls from outside the perimeter are denied. You have two options. Add ingress rules for the tenant service account, and if you scan images or functions, also for the plerion-scanner-artifact@ and plerion-scanner-source@ service accounts. Or include the scanning project in the same perimeter.

​
Quota

Workload scanning runs in the scanning project, which starts with a new project’s default quotas. During a scan, Plerion creates short-lived resources there, in the same region as the workloads it is scanning:
  • A copy of each boot disk in scope, the same size as the original.
  • A scanner VM for each batch of disks, with its own 30 GB boot disk.
Plerion deletes all of it when the scan finishes, so this is temporary capacity rather than storage that grows over time. Quotas are per region and belong to the scanning project. Every project in your organization scans through the same scanning project, so its quota covers your whole organization in that region. If your workloads are spread across several regions, each region needs its own headroom.

​
The quotas that matter

Cloud Run job executions for image and source scans don’t use either quota.

​
What happens when quota is short

Plerion keeps every scan within the scanning project’s quota. When several projects need more capacity than a region allows at once, scans wait and run in turn, so a low quota makes scanning slower rather than making it fail. Two cases do stop a scan. Both come with a message naming the region and the current limit, and in almost every case the figure to ask for:
  • A single workload is too large to fit even on its own. Its boot disk plus the scanner VM’s 30 GB boot disk is more than the region’s limit. A managed instance group counts as one workload. The scan stops before creating anything.
  • One of the scan’s scanner VMs has waited four hours for its turn. The whole scan is marked as failed.

​
How much to ask for

Use the figure in the message. For a workload that can’t fit on its own, the figure is that workload’s boot disk plus the scanner VM’s 30 GB, with 20 percent headroom. For a scan that waited or ran slowly, Plerion calculates the figure from the workloads it has seen across your organization in the last seven days, so it reflects what you actually run. Treat it as a starting point with headroom. Another quota can still run short as your workloads grow. If you want a rough figure before your first scan, take the largest boot disk in the region, add 30 GB, add 20 percent, and round up to the next 50 GB. That is enough for a scan to start. The quota you need for scans to run at full speed depends on how many workloads you have, which is why the figure in the message is the better guide.

​
Steps to raise a quota

1

Open the quotas page for the scanning project

Go to https://console.cloud.google.com/iam-admin/quotas?project=<scanning-project-id>, replacing <scanning-project-id> with your scanning project’s ID.
2

Find the quota

Filter Name by Persistent Disk SSD or CPUs, then add a filter on the Region named in the message. One row should remain.
3

Request the increase

  • Select the row and click Edit.
  • Enter the new value.
  • In the request description, say that the capacity is temporary. For example:
Plerion workload scanning runs in this project. During a scan it creates a temporary copy of each in-scope boot disk plus a 30 GB boot disk per scanner VM, all deleted when the scan finishes. Requesting N GB to cover the organization’s current workloads with headroom for growth.
4

Wait for approval

Small increases on an established billing account are often approved within seconds. A large first request on a new account may be queued or refused. If that happens, raise it in smaller steps. You can track the request on the Increase Requests tab of the same page.
Google’s quota adjuster can raise eligible quotas for you as usage grows, in steps of roughly 10 to 20 percent. It acts on usage history, so it can’t raise a quota before your first scans run, and it skips any quota you have set by hand.

​
Next step