As with the rest of the GCP integration, every permission granted here is reviewable: in this page, in the script or Terraform template itself, and afterward in your own GCP IAM console.
Org-level: two roles, five permissions
Turning on workload scanning adds permissions to the org custom role your GCP organization integration already uses, and creates one new org custom role alongside it. Splitting them this way exists for one reason: GCP doesn’t let a single role binding carry different IAM conditions on different permissions, and three of these five permissions need to be conditioned much more tightly than the role that already existed.PlerionWorkloadScan (extended, unconditioned)
Two permissions are added to the existing PlerionWorkloadScan role you already granted when you turned on CWPP access:
These are unconditioned, at the same org scope as the rest of
PlerionWorkloadScan. list returns only snapshot names and labels (never disk contents), so a condition adds no meaningful protection here, and create only lets Plerion make a new snapshot, never read or delete an existing one.
PlerionWorkloadScanSnapshots (new role, name-prefix conditioned)
A second, new org custom role carries the three remaining permissions, bound with an IAM condition:
All three are bound under the same condition:
plerion-scan- prefix. This condition means the useReadOnly, delete, and setLabels grants only ever apply to snapshots matching that name, across any project in your organization. Plerion cannot read the contents of, delete, or relabel a snapshot it didn’t create, including your own backups, and this is enforced by GCP IAM itself, not just by Plerion’s own software logic or naming convention. Without this condition, an org-wide grant of any of these permissions would reach every snapshot in your organization.
To be precise about what Plerion can and cannot see: the unconditioned
compute.snapshots.list permission above lets Plerion see the name and labels of every snapshot in your organization, including your own backups. That is metadata only. Reading snapshot contents, deleting, and relabeling are all limited by the condition above to snapshots Plerion created itself.Scanning-project role: PlerionScanCompute
Inside the scanning project onboarding creates for you, a project-scoped custom role called PlerionScanCompute is bound to the tenant service account. It covers only what’s needed to run scanner VMs in that one project:
This role grants
compute.instances.setMetadata and compute.instances.setServiceAccount. GCP requires both at instances.insert whenever the create request carries startup metadata and a service account, which every scanner VM boot does, so neither permission can be left out. The real limits on what this buys are scope, not the permission list: the role only reaches the scanning project, never a customer’s own project, and the iam.serviceAccounts.actAs grant below is restricted to the scanner VM’s own service account, which itself holds zero IAM roles (see The scanner VM’s own service account).
The tenant service account also gets iam.serviceAccounts.actAs on the scanner VM’s own service account, so it can boot VMs that run under it.
The scanner VM’s own service account
The scanner VM itself runs under a dedicated service account,plerion-scanner@<scanning-project>.iam.gserviceaccount.com, that holds zero IAM roles. See How scanning works for what this buys you.
Encryption keys
Workload scanning needs no additional Cloud KMS grant beyond what your existing KMS access mode already provides. Creating a scan disk from a customer-managed encryption key (CMEK)-protected snapshot doesn’t require decrypting your key at all. See How scanning works for what happens to the encryption on that disk instead.Reviewing the grants yourself
The onboarding script and Terraform template both list every permission above before creating anything. You can review either one before running it, and review the same grants afterward in your GCP IAM console under the two org-level custom roles andPlerionScanCompute in the scanning project.