Summary
Two of these grants are broad by nature.
PlerionWorkloadScanArtifactPull lets the artifact-scanner identity pull any container image in your organization, and PlerionWorkloadScanFunctionSourceRead lets the source-scanner identity download the deployed source of any 1st gen function. Both exist only while their workload type is on.
Managed instance group scanning adds no role or permission. It uses PlerionWorkloadScan and PlerionWorkloadScanCompute as they are.
Organization-level roles granted with the capability
Turning on the Workload scanning capability in the capabilities step grants these two bindings to the tenant service account. They exist whether or not the scanning project has been created yet, and they let Plerion read workload metadata and take snapshots.PlerionWorkloadScan
The role is unconditioned at organization scope.
compute.snapshots.list returns snapshot names and labels for every snapshot in your organization, including your own backups. That is metadata only. Reading a snapshot’s contents, deleting it, or relabeling it is governed by the conditioned role below.
PlerionWorkloadScanSnapshots
All three are bound under one IAM condition:
plerion-scan- prefix, so these permissions only ever apply to snapshots Plerion created. Plerion cannot read the contents of, delete, or relabel any other snapshot in your organization, including your backups. GCP IAM enforces this, not Plerion’s software.
Organization-level roles gated by workload type
These roles exist only while the matching workload type is turned on. The access command Plerion generates reflects your current selection. It creates a role when its type is on and removes it when the type is off. See Changing workload types.PlerionWorkloadScanImageRead
Created when Compute Engine custom images is on. Bound to the tenant service account.
The binding carries a tag condition:
PlerionAccess: Denied is excluded, so Plerion can’t read that project’s custom images at all. A name-prefix condition like the snapshot role’s isn’t possible here, because Plerion has to read images you named. The role is organization-wide because custom images live in every project, and a per-project binding would need updating as images are built.
PlerionWorkloadScanArtifactPull
Created when Cloud Run or Cloud Functions (2nd gen) is on. Bound to the artifact-scanner service account, plerion-scanner-artifact@<scanning-project>.iam.gserviceaccount.com, not the tenant service account.
The role is unconditioned and organization-wide because a service and the image it runs often live in different projects. It lets the artifact-scanner identity pull any image in your organization. For a 2nd gen function, the image lives in the
gcf-artifacts repository Google creates in your project. It is an ordinary Artifact Registry repository, and Plerion pulls only the image the function is currently serving.
The tenant service account already holds downloadArtifacts through PlerionWorkloadScan. What turning on the type adds is the dedicated identity that runs the scan job, and its role. A Compute Engine-only integration has no artifact-scanner identity and no PlerionWorkloadScanArtifactPull role.
PlerionWorkloadScanFunctionSourceRead
Created when Cloud Functions (1st gen) is on. Bound to the source-scanner service account, plerion-scanner-source@<scanning-project>.iam.gserviceaccount.com.
This is the only permission the source-scanner identity holds. It doesn’t include
cloudfunctions.functions.get or .list, so the identity can only act on function names Plerion already found through PlerionWorkloadScan. It lets the source-scanner identity read the deployed source of any 1st gen function in your organization.
Scanning project role: PlerionWorkloadScanCompute
Inside the scanning project, a project-scoped custom role is bound to the tenant service account. It covers running scanner VMs and Cloud Run scan jobs in that one project and nothing outside it.
The
run.* permissions are granted with the rest of the role regardless of which workload types are on. A workload type controls the identity that can reach your images or source, which is the artifact-scanner or source-scanner service account.
The tenant service account also holds roles/iam.serviceAccountUser on each scanner service account in the scanning project, so it can start VMs and jobs that run as them.
Scanner service accounts
The scanner VM account is created with workload scanning. The other two are created with their workload type and removed when the type is turned off and the access command re-run. Because they are separate identities, compromising one grants none of the others’ access.
Image pulls and source downloads by these identities appear in your Cloud Audit Logs only if Data Access audit logging is enabled for
artifactregistry.googleapis.com and cloudfunctions.googleapis.com. Google Cloud doesn’t enable Data Access logs by default. Turn them on if you want every pull and download, including Plerion’s, in your own logs.Reviewing and removing grants
The onboarding script prints eachgcloud command before running it, including the --permissions list of each workload scanning role it creates or updates. To review the commands without running any, pass --dry-run. The Terraform template declares the same roles in plain text. Afterward, the roles appear in your IAM console under the organization’s custom roles and, for PlerionWorkloadScanCompute, in the scanning project.
No Plerion identity can change your organization’s IAM, so removing a grant is always something you do. Re-running the access command removes the type-gated roles for any type you have turned off, and --remove-workload-scanning deletes the scanning project and all three type-gated roles. See Managing workload scanning for both, and the GCP integration overview for revoking Plerion’s access entirely.