Google Cloud integrations

The six shapes

Each integration uses the right wire pattern for its data plane — polling, pulling, sidecar or in-process.

Cloud Monitoring GA

Shape: control-plane poll. REST against monitoring.googleapis.com/v3/projects/<id>/timeSeries. Curated default plan of 11 metric types across GCE / Cloud Run / Functions / Cloud SQL / Pub/Sub / Storage / Load Balancing / GKE — extensible.

Cloud Logging GA

Shape: Pub/Sub pull. Customer creates a Cloud Logging sink → topic → subscription; PulseBoard pulls in batches of up to 100, decodes, ships logs, then ACKs. At-least-once. Severity mapped to PulseBoard log levels.

Cloud Billing (BigQuery) GA

Shape: BigQuery query. Aggregated SQL over the partitioned gcp_billing_export_v1_… table at the service, project or sku axis. Cents-per-poll thanks to usage_start_time partition pruning.

Google Kubernetes Engine GA

Shape: two halves. Control-plane poll returns cluster shape (status, version, channel, autopilot, nodepool autoscaling) across every region in one round-trip via the locations/- wildcard. In-cluster pulseboard-agent DaemonSet ships pod logs + host metrics. Operators run either or both.

Cloud Run sidecar GA

Shape: multi-container service manifest. We provision an envsubst-rendered Knative-style Service where your app container talks OTLP to the PulseBoard agent sidecar on localhost:4318. Gen2 execution environment. ~30 MiB sidecar overhead.

Cloud Functions Gen2 GA

Shape: in-process tracer SDK. NODE_OPTIONS=--require @pulseboard/tracer/register for Node (zero source change), or one-line start() for Python. OTEL_RESOURCE_ATTRIBUTES fully populated by our deploy wrapper.

The 4-hop Workload Identity dance

PulseBoard's OIDC issuer signs an assertion. STS gives us a federated token. IAMCredentials hands us a Service Account access token. That token is what hits Cloud Monitoring / Pub/Sub / BigQuery / GKE.

1
Mint an RS256 JWT
Subject = pulseboard:workspace/<slug>:account/<id>. Audience = the WIF provider URL.
2
POST to STS
RFC 8693 token exchange at sts.googleapis.com/v1/token → federated access token.
3
Impersonate the SA
POST to iamcredentials.googleapis.com/v1/.../serviceAccounts/<email>:generateAccessToken with the federated token → SA access token (1h lifetime).
4
Call the data plane
Use the SA token as Bearer against Cloud Monitoring, Pub/Sub, BigQuery, GKE — whichever the integration is.

We never see a JSON key file. The customer never copies one out of GCP. The Federated Identity Pool can be revoked in one gcloud iam workload-identity-pools delete.

Onboarding

# Idempotent gcloud-based onboarding (creates pool, provider, SA, IAM bindings)
git clone https://github.com/OpenPulseBoard/pulseboard-cloud-infra
cd pulseboard-cloud-infra/gcp

./onboarding.sh \
  --project <project-id> \
  --project-number <project-number> \
  --issuer https://cloud.pulseboard.dev \
  --subject pulseboard:workspace/acme:account/<account-id>

# Enable specific integrations (opt-in beyond Cloud Monitoring)
./onboarding.sh --enable-logging \
  --log-topic pulseboard-logs --log-sub pulseboard-logs-sub
./onboarding.sh --enable-billing \
  --billing-dataset billing_export
./onboarding.sh --enable-gke

What you get

Hub-and-spoke ready

Cross-project billing exports and per-spoke monitoring work via the datasetProject / subscriptionProject overrides.

Autopilot-safe

The GKE DaemonSet has no priorityClassName, no hostNetwork, no host-path writes, and only requires read-only volumes. It deploys unchanged to Autopilot.

Cents-per-poll billing

BigQuery export queries use partition pruning on usage_start_time, so a typical 7-day service aggregation scans 8-15 MiB — about $0.10–$0.20 per project per month.

Six integrations. Zero stored credentials.