Beacon evaluates Google Cloud projects against the CIS Google Cloud Foundations Benchmark and additional controls spanning IAM, logging and monitoring, networking, compute, storage, databases, encryption, and Security Command Center, covering all projects in the customer's organization or a specific project. No agent is deployed in the customer environment. Beacon authenticates as its own scanner service account; the customer simply grants that service account read roles. No customer secrets are ever stored.
Beacon maintains its own scanner service account (SA) in the Beacon GCP project. To grant Beacon access, the customer runs a single gcloud command (or completes the equivalent steps in the GCP Console IAM page) to bind that SA to two read-only roles on their organization or project. Beacon never asks the customer to create credentials, export keys, or share any secrets, the scanner SA email is shown in the onboarding wizard.
The scanner SA is granted only roles/viewer and roles/iam.securityReviewer on the customer's organization or project. These roles provide broad read access for compliance scanning but grant no write, delete, or administrative permissions.
Unlike service-account key file approaches, Beacon uses its own SA identity authenticated via Workload Identity. The customer never generates or hands over a JSON key file. Revoking Beacon's access is as simple as removing the IAM bindings in the customer's GCP Console.
There are two ways to grant Beacon access. The Cloud Shell path is fastest and requires only a browser; the manual path is available if the customer prefers to use the GCP Console IAM UI or Terraform.
Beacon generates a pre-filled Open in Cloud Shell deep-link that opens Google Cloud Shell in the customer's browser with the gcloud … add-iam-policy-binding command pre-populated. The customer clicks Run and the binding is applied in seconds, no copy-pasting of service account emails or role names required.
Open the client wizard in Beacon
Go to Clients → Add client (or Edit an existing client) and select GCP as the cloud provider. Beacon displays the scanner SA email and generates a Cloud Shell URL.
Click 'Open in Cloud Shell'
Click the Open in Cloud Shell button in the wizard. A new browser tab opens in the customer's GCP Console with Cloud Shell pre-loaded and the gcloud command ready to run. The command targets either the customer's organization (recommended) or a specific project, whichever scope you selected in the wizard.
Run the command
The customer (or you, if you have the appropriate GCP access) clicks Run in Cloud Shell. The binding is applied immediately. For organization scope, two bindings are created, one for roles/viewer and one for roles/iam.securityReviewer.
Complete the wizard in Beacon
Return to the Beacon wizard tab and click Verify & save. Beacon attempts a live connection test. On success, the client is saved and a first scan is queued automatically.
Use this path if the customer prefers to run the commands themselves, use Terraform, or apply bindings through the GCP Console IAM page rather than Cloud Shell.
Retrieve the scanner SA email
Call GET /api/clients/gcp/onboarding-info (or open the GCP connection wizard in Beacon). The response returns scannerSaEmail, the Beacon scanner service account email, and a pre-built cloudShellUrl if you prefer the Cloud Shell path.
Grant roles at organization scope (recommended)
Run the following two commands in any shell where the customer has the resourcemanager.organizations.setIamPolicy permission. Replace ORG_ID with the customer's GCP organization ID and SCANNER_SA_EMAIL with the email from step 1:
gcloud organizations add-iam-policy-binding ORG_ID \ --member="serviceAccount:SCANNER_SA_EMAIL" \ --role="roles/viewer" gcloud organizations add-iam-policy-binding ORG_ID \ --member="serviceAccount:SCANNER_SA_EMAIL" \ --role="roles/iam.securityReviewer"
Or: grant roles at project scope
If only a single project should be scanned (see the Scope section below), bind to the project instead:
gcloud projects add-iam-policy-binding PROJECT_ID \ --member="serviceAccount:SCANNER_SA_EMAIL" \ --role="roles/viewer" gcloud projects add-iam-policy-binding PROJECT_ID \ --member="serviceAccount:SCANNER_SA_EMAIL" \ --role="roles/iam.securityReviewer"
Save the connection in Beacon
Edit the client in Beacon, select GCP as the provider, choose the appropriate scope (Organization or Project), and enter the organization ID or project ID. Click Save changes.
Do not grant any roles beyond roles/viewer and roles/iam.securityReviewer. Beacon's scanner is designed to operate within these read-only bounds and does not require write access of any kind.
Beacon supports two scopes for GCP connections:
Beacon scans all projects in the customer's GCP organization in a single connection. When new projects are created in the organization, Beacon discovers them automatically on the next scan and raises a GCP-PROJECT-001, Unapproved project detected finding. Use the Approve project action (or call POST /api/clients/{id}/connection/projects/approve) to add a project to the approved list and resolve the finding.
Beacon scans a single GCP project. Use this when the customer has no GCP organization (standalone project) or wants to grant Beacon access only to a specific project without organization-level IAM bindings. Project drift detection (GCP-PROJECT-001) is not applicable in project scope.
GCP-PROJECT-001, Unapproved project detected. When scanning at organization scope, Beacon compares the set of discovered projects against the approved-projects list you maintain per client. If a project exists in the organization but is not on the approved list, Beacon raises a finding. Use the Approve project action on the finding (or call POST /api/clients/{id}/connection/projects/approve) to add it to the approved list and resolve the finding.
Beacon's GCP checks map to the CIS Google Cloud Foundations Benchmark and include additional controls across the following domains:
IAM
Service account key age and rotation, primitive role usage (Owner/Editor on non-root), service account admin separation, corporate login restrictions, and API key restrictions.
Logging & monitoring
Audit logs enabled (Admin Activity, Data Access) across all services, log metric filters and alerts for key admin actions, log sink configured to export to Cloud Storage or BigQuery, and retention policy on log buckets.
Networking
Default firewall rules for SSH/RDP (0.0.0.0/0 and ::/0), VPC flow logs enabled on all subnets, private Google access enabled, DNS logging on VPC networks, and load balancer SSL policy strength.
Compute / VMs
VM instances with public IPs, OS login enforced, Shielded VM enabled, serial port access disabled, default service account usage on VMs, and confidential computing availability checks.
Storage / GCS
Bucket-level public access (allUsers / allAuthenticatedUsers), uniform bucket-level access enforcement, bucket logging enabled, versioning on sensitive buckets, and retention locks.
Cloud SQL
SSL enforcement on database instances, public IP not assigned, authorized networks locked down, automated backups enabled, and binary logging for MySQL.
BigQuery
Dataset public access (allUsers / allAuthenticatedUsers), customer-managed encryption key (CMEK) usage, and table-level access controls.
KMS
Key rotation period within policy limits, key version state (disabled/destroyed keys in use), and separation of KMS admin and crypto-user roles.
Security Command Center
SCC Standard or Premium tier enabled, active high/critical SCC findings ingested as Beacon findings, and Event Threat Detection enabled.
Labels
Required-label compliance on Compute instances, GCS buckets, Cloud SQL instances, and BigQuery datasets against the label policy configured per client.
Project drift
GCP-PROJECT-001: projects discovered in the organization but not on the approved list trigger a finding, surfacing shadow projects before they accumulate.
Checks that cannot be evaluated because a service is not enabled in the project (for example, Cloud SQL not in use, or no KMS keys present) are recorded with a status of unknown rather than fail, so they do not unfairly penalise the compliance score.
Once the GCP connection is saved, a Sync now button appears on the client detail page. Beacon also runs scans automatically on the configured schedule (global default: every 6 hours). You can override the scan frequency per client on the client edit form.
During each GCP scan, Beacon:
Most common cause: the IAM binding was applied at the wrong scope (project instead of organization, or vice versa), or the wrong scanner SA email was used. Re-check the binding using gcloud organizations get-iam-policy ORG_ID (or gcloud projects get-iam-policy PROJECT_ID) and confirm the Beacon scanner SA email appears with both required roles.
Permission denied on API calls — One or both of the required roles (roles/viewer and roles/iam.securityReviewer) is missing. Verify both bindings are present and target the correct resource (organization or project).
Organization policy constraint blocking API — Some organizations enforce constraints/iam.allowedPolicyMemberDomains to restrict which identities can be granted IAM roles. Ask the customer's GCP admin to allowlist the Beacon SA domain, or switch to project scope if only one project is needed.
Scan stuck in "syncing" state — A large number of projects or API quota exhaustion on the customer's project may cause the fan-out to run long. Beacon retries quota errors with exponential backoff. If the scan does not complete within 15 minutes, contact support.
SCC findings not appearing — Security Command Center must be enabled (Standard or Premium tier) in the customer's organization. SCC findings are only ingested if the scanner SA has the roles/viewer role at organization scope, which includes SCC read access.
Beacon connects Azure, AWS, and Google Cloud the same agentless, read-only way. See the other per-cloud setup guides, or review the security model.