GCP Infrastructure

Every resource the GCP deployment creates, and what each one is for.

The GCP deployment is shaped differently from the other two before you even get to the resources themselves: it's a Config Connector manifest, not a native Deployment Manager or Terraform template. Applying it requires a GKE Autopilot cluster with Config Connector already running — that cluster is what turns the resources below into real GCP infrastructure, the way CloudFormation or an ARM deployment does natively on the other two clouds.

Once applied, the shape is close to Azure's: one Cloud Run service does everything, and three of its four secrets have to be filled in by hand before deploying — Config Connector can't generate a value the way CloudFormation can.

Cloud-Vex GCP infrastructure. A Cloud Run service is the public HTTPS endpoint itself, with no separate edge layer. One service runs the API, the web UI, and by the app's own default the scan scheduler - no separate scheduler or worker service, the same shape as the Azure deployment. It reaches the VPC through direct VPC egress restricted to private ranges, and reaches Postgres specifically through a Cloud SQL Auth Proxy sidecar rather than a direct connection. Inside the VPC, a custom-mode network with an app subnet and a database subnet, both with Private Google Access enabled, a Cloud SQL for PostgreSQL 13 instance holds the findings store, SSL required, 30-day backups, deletion protection off, and a Memorystore for Redis Basic-tier instance provides the cache - its connection host is only known after it finishes provisioning, a genuine two-step deploy. Outside the VPC, Secret Manager holds four secrets - licence key, database password, admin password, and the Redis connection URL - three filled in before deploying and the Redis one only after it's ready. An IAM service account is what Cloud Run authenticates as, holding roles/cloudsql.client and roles/redis.viewer. A monitoring notification channel and a health check are declared for future use but not yet wired to anything, since Cloud Run doesn't need a health check for its own traffic.

Compute

  • Cloud Run — backend service — one service running the API, the web UI, and (the app's own default) the scan scheduler together. Public HTTPS endpoint itself, no separate edge layer in front of it.
  • Direct VPC egress, private ranges only — reaches the VPC without a separate VPC Access Connector resource. Normal internet egress (pulling the image, calling the licence service) stays on the default path.
  • Cloud SQL Auth Proxy sidecar — how the service actually reaches Postgres: a local socket Cloud Run runs for it, not a direct connection to a private IP.
  • No separate scheduler or worker service. Same shape as Azure, unlike AWS's three-way split.

Network

  • VPC, custom mode — automatic subnet creation off, two subnets defined explicitly.
  • App subnet & database subnet — both with Private Google Access enabled, so resources inside them can reach Google APIs without a public IP.
  • Firewall rules — internal traffic allowed within the VPC's address range, port 5432 allowed from the app subnet only, and a declared (currently unused by Cloud Run) rule for tagged instances on 80/443.

Data

  • Cloud SQL for PostgreSQL 13 — the findings store. SSL required, 30-day backups, deletion protection off.
  • Memorystore for Redis — cache, reached over private service access. Basic tier, 1GB.

Secrets & identity

  • Secret Manager — four secrets: licence key, database password, admin password, and the Redis connection URL. The first three are supplied before applying the manifest; the Redis URL can only be set afterward, once Memorystore has actually provisioned and reports a host.
  • IAM service account — what Cloud Run authenticates as. Granted roles/cloudsql.client to reach Postgres through the proxy, and roles/redis.viewer to read the Redis instance's connection info.

Monitoring

  • Notification channel (email) — where an alert would go.
  • Health check — declared against the app's /health endpoint for a future load balancer. Not wired to anything yet; Cloud Run doesn't need one for its own traffic.

What isn't here

  • No customer-managed encryption key. Cloud SQL and Memorystore encrypt at rest with Google-managed keys by default, the same gap as the Azure template.
  • No storage bucket for collector templates. Same gap as Azure — no Cloud Storage equivalent of the AWS deployment's S3 bucket.
  • No native one-click template. This is the trade-off for using Config Connector: real Kubernetes-shaped resources, checked against live CRDs, but a GKE Autopilot cluster has to exist first.

This is the hub's own project. Adding another GCP project, or AWS or Azure, deploys a much smaller collector into it instead — covered by the permission model and the scan cycle pages.

Need this against your own security review checklist? Email support@cloud-vex.com.

Join the waitlist