GCP Serverless Scanner

The GCP serverless scanner runs entirely inside your GCP project. A Cloud Run service (the orchestrator) discovers the projects in a configured organization or folder on a schedule, then fans out one Cloud Run Job execution per project to run cnspec and ship results to Mondoo. Nothing scans from Mondoo's side, and no long-lived service account key is stored when you use Workload Identity Federation.

What gets deployed

A single terraform apply of the serverless-scanner-gcp module (deploy/terraform) creates three Cloud Run resources plus the Pub/Sub, Cloud Storage, IAM, and (optionally) Cloud Scheduler scaffolding that connects them:

• Orchestrator, a Cloud Run service that receives schedule ticks, enumerates the projects in scope, and dispatches one scan task per project.
• Scanner, a Cloud Run Job. The orchestrator launches one execution per project; each execution runs cnspec against that project. The Job uses a Google Cloud SDK base image that downloads a per-execution scan script from the orchestrator bucket and runs it, so there is no cnspec image to pull.
• Updater, a Cloud Run Job that polls Mondoo's registry for a newer orchestrator image and rolls the service to it, so you do not have to re-apply after each release.

Prerequisites

• A dedicated GCP host project (separate from the projects you scan) with these APIs enabled: run, pubsub, iam, cloudresourcemanager, logging, secretmanager, storage, and monitoring. Add cloudscheduler only if you keep the built-in scheduler (see enable_scheduler). The module verifies the APIs read-only and stops the plan if one is missing; it never enables them for you.
• A Mondoo GCP serverless integration created in the console, which gives you an integration MRN and a credential (a Workload Identity Federation config or a service account JSON).
• An Artifact Registry repository the module's images are served from.
• The runtime service account's read access to the organization or folder you scan. The module can grant this, or you can grant it out-of-band (see manage_scope_iam).

Usage

module "serverless_scanner" {
  source = "github.com/mondoohq/serverless-scanner-gcp//deploy/terraform"

  project_id = "my-scanner-host"
  region     = "europe-west3"
  image      = "europe-west3-docker.pkg.dev/my-scanner-host/mondoo/orchestrator:prod"

  # What to scan and where results go.
  scope                  = "organizations/123456789012" # or folders/<id>
  mondoo_integration_mrn = "//integrations.api.mondoo.com/spaces/<space>/integrations/<id>"
  mondoo_config_base64   = filebase64("mondoo.json") # WIF config or SA JSON
}

Configuration reference

Core inputs

Schedules

The orchestrator is driven by four triggers, each a cron expression interpreted in UTC: scan_schedule (the scan pass, every 12 hours by default), metrics_schedule (telemetry), sync_schedule (backend-config sync), and checkin_schedule (a liveness ping, every 10 minutes by default). auto_update_schedule controls the updater (hourly by default).

Options for restricted environments

The following inputs exist so the module can deploy into sovereign, Assured Workloads, or otherwise policy-restricted projects. Each defaults to the unrestricted behavior, so leaving them unset changes nothing.

Restricted and sovereign environments

Locked-down GCP organizations (sovereign clouds, Assured Workloads) enforce organization policies that reject the module's default resources. The options below make each requirement satisfiable.

Customer-managed encryption (CMEK)

Where constraints/gcp.restrictNonCmekServices is enforced, resources created without a customer-managed key are rejected. Set kms_key_name to a Cloud KMS key and the module encrypts the orchestrator bucket, every Pub/Sub topic, the Cloud Run service and Jobs, and the config secret with it. The secret switches to regional (user_managed) replication in region, since automatic replication cannot use a single regional key.

kms_key_name = "projects/<key-project>/locations/europe-west3/keyRings/<ring>/cryptoKeys/<key>"

Air-gapped scan workloads

When the scan workloads cannot reach the public internet, set installer_url to an internal mirror. The scan then fetches the cnspec binary from <installer_url>/package/... and its providers from <installer_url>/providers/..., so the mirror must serve both path layouts under one base URL.

installer_url = "https://install.mirror.example.internal"

If the host project also blocks Cloud Run from pulling the default gcr.io scanner base image, mirror a Google Cloud SDK image into your registry and set scanner_image to it.

Driving triggers without Cloud Scheduler

Where Cloud Scheduler is unavailable (for example, org policy blocks the App Engine service family), set enable_scheduler = false. The module then creates no scheduler jobs and does not require the cloudscheduler API. The scan-trigger Pub/Sub topic still exists, so an external driver, such as a Kubernetes CronJob, can publish the typed trigger payloads to it on your own schedule.

Delegating IAM when the deployer cannot set it

In delegated-admin setups, the identity running Terraform may not set folder, organization, or project IAM, even though it can create the resources themselves. Two flags move those grants out-of-band:

• manage_scope_iam = false: the module does not grant the runtime SA its org/folder scan roles. Grant them yourself at the scope node.
• manage_project_iam = false: the module does not grant the runtime SA (or the Cloud Run service agent) their host-project roles. Grant them yourself in the host project.

When manage_project_iam = false, grant these in the host project out-of-band:

Resource-level IAM (Pub/Sub publisher, Cloud Run invoker, Secret Manager accessor) is always managed by the module and is unaffected by these flags.