> ## Documentation Index > Fetch the complete documentation index at: https://docs.plerion.com/llms.txt > Use this file to discover all available pages before exploring further. # GCP workload scanning prerequisites > What to have in place before turning on GCP workload scanning: roles, a billing account, APIs, organization policies, and quota With **[GCP workload scanning](/guides/integrations/gcp/workload-scanning/overview)**, 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](https://console.cloud.google.com/billing). 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. | Project | APIs enabled | | - | - | | Plerion service project | `cloudbilling.googleapis.com` | | Scanning project | `compute.googleapis.com`, `iam.googleapis.com`, `logging.googleapis.com`, `run.googleapis.com` | 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. | Constraint | What it blocks | Checked | What to do | | - | - | - | - | | `constraints/compute.vmExternalIpAccess` | The default **Ephemeral external IP** networking mode | By the script before it creates anything, and at every scan run | Choose **Cloud NAT** in the wizard and select the regions to provision it in. If you run the script by hand, pass `--nat --workload-regions ` | | `constraints/compute.storageResourceUseRestrictions` | Creating the scan disk in the scanning project from a snapshot taken in a workload project | At every scan run | Make sure the policy's allowed values include your own organization (`under:organizations/`). A policy locked to same-project use, or to another organization, blocks Compute Engine scanning | | `constraints/gcp.resourceLocations` | Creating scan disks, scanner VMs, and job executions in a workload's region | At every scan run, against the first region in your **Workload regions** setting | Allow the regions your workloads run in. If **Workload regions** is empty, this check is skipped | | `constraints/compute.trustedImageProjects` | Booting the scanner VM's image, whichever path it boots from | At every scan run | Add `projects/ubuntu-os-cloud`. Also allow `projects/pln-public-artifacts` for faster scanner VM startup | 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 | Quota (Google Cloud console name) | What it limits | | - | - | | **Persistent Disk SSD (GB)** | The disk copies and scanner boot disks a scan creates | | **CPUs** | The cores scanner VMs use: 2 per VM, or 4 when **Sensitive data** is on | 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 Go to `https://console.cloud.google.com/iam-admin/quotas?project=`, replacing `` with your scanning project's ID. Filter **Name** by `Persistent Disk SSD` or `CPUs`, then add a filter on the **Region** named in the message. One row should remain. * 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. 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](https://cloud.google.com/docs/quotas/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 * [Getting started](/guides/integrations/gcp/workload-scanning/getting-started) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.