Cloud Monitoring
Cloud Monitoring collects metrics, evaluates alert policies and notifies channels. The GCP Enterprise Baseline makes acme-core-security the one place that sees every project's metrics and sends every security alert, from 13 log-based detections over the central audit log bucket.
What it does
Every project has metrics; a metrics scope lets one scoping project view the metrics of other monitored projects. A log-based metric counts log entries that match a filter, and can run over a specific log bucket. An alert policy watches a metric with a condition and notifies its notification channels, which must live in the alert policy's own project. Cloud Trace stores distributed traces that applications send, for example through OpenTelemetry.
How BuiltForProd uses it
One scope. The organization-scoped metrics-scope unit makes acme-core-security the scoping project and every other project a monitored project, so dashboards and alert policies there see all 14. The same unit creates the email notification channel for the security mailbox (security_alert_email in security.hcl), the Pub/Sub topic acme-security-alerts for Security Command Center findings, and the organization-level Essential Contact for security notices.
Thirteen detections. The cis-alerts unit (enable_cis_alerts = true, free) creates one log-based metric per detection over the central bucket acme-audit in acme-core-audit, where a bucket-scoped metric must live, and one alert policy per metric in acme-core-security, the channel's project. Each policy fires on any match within five minutes, with severity WARNING, closes itself after 30 minutes, and its documentation names the bucket and the filter to investigate with.
| Source | Detections |
|---|---|
| CIS Google Cloud Foundations Benchmark, section 2 | project ownership changes, audit configuration changes, custom role changes, firewall rule and policy changes, route changes, network changes, storage IAM changes, Cloud SQL configuration changes |
| The platform's own | organization policy changes, service account key creation, break-glass sign-in, Security Command Center HIGH and CRITICAL findings, sink changes |
The break-glass detection exists once at least one account is listed in break_glass_emails of the cis-alerts unit. The detections read logs that the organization sinks of Cloud Logging bring in, so they cover every project from one place.
Per-project read access and traces. The observability unit of every project grants the auditor groups Monitoring Viewer; in the stage projects it also enables Cloud Trace (cloudtrace.googleapis.com) for OpenTelemetry and gives the stage's engineer groups Monitoring Viewer and Cloud Trace User. The Web App Blueprint's application identity holds Cloud Trace Agent, so the API sends its traces to its stage project.
Terms you will see
| Term | Meaning |
|---|---|
| Metrics scope | The set of projects whose metrics acme-core-security can view. |
| Log-based metric | A counter of log entries matching a filter, here over the central bucket. |
| Alert policy | A condition on a metric and the channels it notifies. |
| Notification channel | The email destination of the security mailbox. |
break_glass_emails | The emergency accounts whose sign-ins raise an alert. |
Where to read more
- GCP Enterprise Baseline overview for the detective controls.
- Cloud Logging for the bucket the detections read.
- Observable for the observability pillar of the BuiltForProd Standard.