Integration / GCP

Connect Google Cloud to CYBRET.

CYBRET reads your GCP organization end to end and joins it to the application code that runs on it. Workload Identity bindings, IAM Conditions, and the Cloud Run services that quietly leak service-account tokens through the metadata server become one navigable graph.

What CYBRET sees on GCP

The org, projects, and the bindings between them.

The GCP integration covers the resources that decide whether an application identity reaches a piece of customer data. We read organization, folder, and project IAM, plus the per-resource policies that override them. We don't pull workload memory or object data; we pull the metadata that determines reachability, plus the Cloud Audit Logs that prove it was used.

  • Cloud IAM: members, predefined and custom roles, IAM Conditions (CEL expressions), service accounts and their keys, organization policy constraints.
  • Networking: VPCs, subnets, firewall rules (including hierarchical firewall policies), Cloud Armor backends, Cloud NAT and the public IPs that result, PSC and PGA endpoints.
  • Compute and runtimes: GCE instances, GKE clusters with Workload Identity bindings, Cloud Run services and their ingress settings, Cloud Functions and their service-account configuration.
  • Data and secrets: Cloud Storage buckets with bucket-level and object-level IAM, Cloud SQL instances and authorized networks, BigQuery datasets, Secret Manager secret metadata, Artifact Registry repositories.
  • Telemetry: Cloud Audit Logs (Admin Activity, Data Access where enabled), Asset Inventory feed for change detection.
Three real attack-path examples

What we find in the first week.

These show up consistently on first-time GCP connects. They are the paths that CSPM tools see only the cloud half of, and SAST tools see only the code half of. CYBRET joins both.

1. Public Cloud Storage bucket fronts a real export job

Public bucket with allUsers : roles/storage.objectViewer → nightly export job writes redacted-but-not-empty PII → URL discoverable from a sitemap reference.

The bucket isn't empty and isn't a static website. It receives a nightly batch from a Cloud Run job that is supposed to scrub PII, but the scrub has a column-level bug. CYBRET surfaces theallUsers binding from the Storage IAM, traces the writer back to the Cloud Run service, and reads the export code to flag the unmasked column. Triage closes the path in two changes: the public binding is removed and the export job's test fixture is updated.

2. GKE Workload Identity reaches the wrong bucket

GKE pod with KSA bound to GSA → GSA holds roles/storage.objectViewer at the project level → project contains the customer-data bucket.

The Kubernetes service account is bound to a GCP service account that looks scoped to one bucket but is actually held at the project level. Any pod scheduled with that KSA can read every bucket in the project, including the one with customer exports. CYBRET reads theiam.gke.io/gcp-service-account annotation, resolves the binding chain, and shows the effective set of buckets and the deployment that gives an attacker pod a path to it.

3. Cloud Run SSRF leaks service-account token via metadata server

Cloud Run service with --allow-unauthenticated → URL fetcher endpoint → SSRF to metadata.google.internal → identity token of attached service account → admin in another project.

The Cloud Run service is internet-reachable and has a URL preview handler with no allowlist. The attached service account has editor-equivalent on a sister project via cross-project IAM. CYBRET recognises the SSRF pattern in the handler, reads the metadata-server IP from the runtime, and resolves the IAM binding chain across the two projects. The proof is a metadata token; the fix is an SSRF allowlist plus a tighter service-account scope.

How the integration works

One service account. Read-only at org scope.

The base integration is a service account in a central CYBRET project, granted read-only viewer roles at the organization level via Cloud Asset Inventory and IAM. There is no agent on workloads.

  1. Open the CYBRET console and go to Integrations → GCP.
  2. Click Connect GCP. Copy the generated gcloud commands or the Terraform module. Both create the same service account and bindings.
  3. Run them as an Organization Admin. The bindings include roles/iam.securityReviewer, roles/cloudasset.viewer, and roles/orgpolicy.policyViewer at the org level.
  4. Configure Workload Identity Federation between your CYBRET tenant and the service account. CYBRET never holds a service-account JSON key.
  5. Pick the projects and folders in scope. The first asset feed populates within ten minutes; reachable paths land in Exposure Intelligence as the graph builds.
  6. Optional: enable the Cloud Audit Logs sink for runtime correlation, and the GKE audit log forwarder for Kubernetes reachability.

Disconnect by removing the IAM bindings. The service account is in your org; CYBRET cannot retain access if you revoke the binding.

Permissions and data scope

Read-only. No agents. Workload Identity Federation, not keys.

The base scope is roles/iam.securityReviewer,roles/cloudasset.viewer, and a small set of resource-specific viewer roles for storage, compute, container, and run. None of these grant a write action. There is no agent in GKE, Cloud Run, or any compute target. The integration calls Google APIs from the CYBRET tenant, authenticated via Workload Identity Federation; we never hold a long-lived service-account key.

For runtime detection, the optional log sink streams Cloud Audit Logs and Data Access logs (where enabled) to the customer-tenancy CYBRET deployment. The sink is read-only by construction. Customers who run CYBRET in a self-managed configuration can use a project-level service account in place of org-level access; reachability is then narrowed to that project.

How GCP maps to the three CYBRET products

Where GCP data shows up in the platform.

Exposure Intelligence is the primary consumer. The reachable-path engine joins your GCP IAM and network graph with application code, secrets in Git, and the Workload Identity bindings that connect Kubernetes service accounts to GCP service accounts. CYBRET resolves IAM Conditions in CEL, so a path that requires request.time < ... is treated correctly.

Validation uses GCP context to generate proof-of-exploit. When CYBRET claims a Cloud Run service is reachable and exposes a metadata token, Validation issues the SSRF against a non-prod replica and returns the redacted token shape. We do not validate against production resources where the test would mutate state.

Runtime Detection ingests Cloud Audit Logs and the Asset Inventory feed to confirm exercise of paths. A surfaced path becomes a runtime alert when the binding it depends on is actually used by a non-employee principal. Runtime Detection is strongest when paired with the application Runtime collector; GCP-only telemetry is one signal among several.

FAQ

Questions security engineers actually ask.

How does authentication work?

Workload Identity Federation between your GCP organization and the CYBRET tenant. We do not request, store, or rotate service-account JSON keys. The federated trust is unique per tenant and revocable in your console at any time.

Where does the GCP data live?

Inside the CYBRET deployment in your VPC. EU customers run an EU-resident control plane; US customers run a US one. We do not copy GCP metadata to a multi-tenant SaaS backend.

Is it really agentless?

Yes. The base integration uses Google APIs only. No DaemonSet on GKE, no sidecar in Cloud Run, no eBPF on GCE. Runtime Detection on GCP also runs agentlessly via Cloud Audit Logs.

How do you handle GCP API quotas?

We use Cloud Asset Inventory feeds rather than per-API polling for the bulk of inventory; this is the same mechanism Google recommends to security tools. Per-resource API calls are concurrency-limited and respect quota signals.

Multi-project and Shared VPC?

Supported. CYBRET enumerates host and service projects, follows Shared VPC bindings, and resolves IAM at the org and folder layers. Custom-role expansions and IAM Conditions are evaluated, not flattened.

Can we limit scope to a single project?

Yes. The integration accepts project-level credentials; reachability is then constrained to that project and any resources it shares. Org-level coverage is recommended for full graph coverage but is not required.

Next step

Connect GCP →

One service account, one Workload Identity Federation, no keys to rotate. First reachable paths typically resolve inside an hour.

Connect GCPSee Exposure Intelligence