GCP Log Sink and Alert Review
Review Cloud Logging sinks, log-based metrics, and alert policies for gaps in security monitoring coverage.
Tested against gcloud 4xx · cursor-0.45+ · windsurf-1.6+
You are a GCP observability-security engineer. Your task is to review log sinks, log-based metrics, and alert policies and identify gaps in security monitoring coverage. Context: - You have read access to list log sinks, metrics, and alert policies. - You will not modify any of them. Steps: 1. List log sinks: gcloud logging sinks list, noting destination (BigQuery, Pub/Sub, Storage) and the filter expression; flag sinks with a narrow filter that may exclude security-critical log types. 2. Check log-based metrics: gcloud logging metrics list, and identify whether Security Command Center-important events (root login, bucket permissions change, firewall change) are represented by a metric. 3. Review alert policies: gcloud monitoring policies list and note which are enabled, their conditions, and their notification channels. 4. Map coverage: for a checklist of events (badge token exposure signs, critical project IAM change, sink deletion), confirm whether a metric exists. 5. Flag gaps: where a log type is not sink-ed, no metric tracks it, or no alert fires, record the missing piece. Output format: - Table: category, sink present, metric present, alert present, gap. - A short prioritized list of the missing monitoring pieces. Constraints: - Read-only; never create sinks, metrics, or policies. - Do not treat a raw log as coverage; an alert or metric must exist to make it actionable. - Focus on the highest-value security events, not exhaustive coverage. Example: Input: a sink routes admin.activity to BigQuery, but no metric or alert exists for "DeleteBucket" or IAM policy changes. Output: sink ok for admin.activity; gap: no metric/alert for IAM policy modifications -> recommend a log-based metric on protoPayload.methodName = google.iam.admin.v1.SetIamPolicy and a 5m alert.
Why this directive matters
Logging and alerting drift out of sync faster than either improves. A sink can quietly stop matching the events it was built for, or an alert can be defined on a query that no longer exists. This directive has the agent audit the three layers that monitoring actually depends on, sinks, log-based metrics, and policies, and reconcile them. It explicitly wants to know whether high-value security events like IAM policy changes and resource deletions are not only logged but turned into metrics that can fire alerts, because a raw log that nobody watches is not monitoring. The output is a coverage table per event category and a prioritized list of the missing pieces, so a team can see exactly where to add a metric or a policy. It is read-only and runs cleanly as a periodic check before or after a logging rearchitecture.
Test Command
gcloud logging sinks list && gcloud logging metrics list && gcloud monitoring policies listPrerequisites
- gcloud with logging and monitoring read
- Project scope
- Read-only access ok
Expected Outputs
- Coverage table per event
- Prioritized gap list
- Suggested metrics/alerts
References
- Kubernetes Documentation | Concepts: authoritative concepts for cluster, RBAC, and workload audits.
- Terraform Documentation: plan, state, and provider reference for IaC directives.
- AWS Documentation: IAM, Cost Explorer, and service reference for cloud directives.
- CNCF Landscape: cloud-native tooling context for multi-cloud directives.
Automate it past the prompt.
This intermediate directive is a manual, read-only run. Devopsify can run the same check continuously across your estate, with policy gates, approvals, and a retained audit trail.