GCP Log Sources

Overview

GCP log sources feed security events from your Google Cloud infrastructure into Fencer’s SIEM module. Each log source type captures a different category of activity — from administrative actions and network flows to storage access and firewall decisions. You connect a log source by creating a GCP monitor connection, which sets up a log sink in your GCP project that routes matching logs through a Pub/Sub pipeline into Fencer’s data lake.

Batch data sources are deprecated

Fencer is deprecating batch data sources, which load logs from a Cloud Storage bucket, and moving to streaming ingestion. Once new batch connections are closed for your organization, the GCP monitor integration no longer appears in the catalog unless you already have one. To use streaming for your GCP logs, contact us.

Prerequisites

• A GCP project with the IAM, Cloud Logging, and Cloud Resource Manager APIs enabled. Some log types need one more API, such as Compute Engine for VPC Flow Logs and firewall logs; the setup instructions list it.
• A service account with the roles/logging.configWriter and roles/serviceusage.serviceUsageConsumer roles, which allow Fencer to create a log sink in your project.
• Administrator role in Fencer (the integrations:create ability).
• An active subscription with the SIEM feature enabled.

How it works

GCP log sources use a log sink pipeline to route events from your GCP project into Fencer. When you connect a log source, Fencer creates a log sink in your project with a filter matching the selected log type. The log sink sends matching events to a Pub/Sub topic that Fencer owns, which writes them to a Cloud Storage bucket. From there, Fencer loads the data into its data warehouse for normalization and analysis.

Fencer normalizes all GCP log types into the OCSF (Open Cybersecurity Schema Framework) standard, enabling consistent detection rules and hunt queries across all your log sources.

Supported log types

Cloud Audit Logs

Cloud Audit Logs record administrative activity and data access events across your GCP services. This is the primary log source for detecting unauthorized access, configuration changes, privilege escalation, and suspicious admin actions. Most GCP detection rules in Fencer target Cloud Audit Logs.

What it captures: Admin activity (resource creation, deletion, and modification), data access events, system events, and policy denied events across all GCP services.

VPC Flow Logs

VPC Flow Logs capture network traffic metadata for your Virtual Private Cloud subnets. Use these to detect unusual traffic patterns, lateral movement, data exfiltration attempts, and communication with known malicious IPs.

What it captures: Source and destination IP addresses, ports, protocol, bytes sent, packets sent, and flow direction for each network flow in your VPC subnets.

Cloud Storage Access Logs

Cloud Storage access logs record operations performed on your Cloud Storage buckets and objects. Use these to detect unauthorized data access, unusual download patterns, permission changes, and potential data exfiltration.

What it captures: Requester identity, bucket and object details, operation type, response status, and bytes transferred for each storage API call.

Firewall Rule Logs

Firewall rule logs record the outcome of traffic evaluated against your VPC firewall rules. Use these to detect blocked intrusion attempts, misconfigured firewall rules, and unexpected allowed traffic.

What it captures: Source and destination IP addresses, ports, protocol, firewall rule name, action taken (allow/deny), and direction for each evaluated connection.

Cloud Armor Logs

Cloud Armor logs record security policy evaluations from your Cloud Armor WAF and DDoS protection. Use these to detect web application attacks, bot activity, and DDoS attempts targeting your HTTP(S) load balancers.

What it captures: Request details, matched security policy and rule, action taken (allow/deny/throttle), source IP, and request attributes for each evaluated request.

Cloud DNS Logs

Cloud DNS logs record DNS queries handled by your Cloud DNS zones. Use these to detect DNS tunneling, queries to known malicious domains, domain generation algorithm (DGA) activity, and unusual DNS resolution patterns.

What it captures: Query name, query type, response code, source IP, and protocol for each DNS query.

Cloud SQL Logs

Cloud SQL logs capture database activity for your Cloud SQL instances. Use these to detect suspicious database connections, unauthorized access attempts, configuration changes, and unusual query patterns.

What it captures: Database connections, authentication events, query activity, and error conditions for your Cloud SQL instances (PostgreSQL, MySQL, and SQL Server).

Connecting a log source

1. Go to Admin > Integrations and find the GCP - Google Cloud Platform (Monitor) integration.
2. Click Connect. On the first step, choose the Log Source Type you want to ingest from the list above, and click Continue.
3. Create the service account. The Manual Setup tab lists the console steps: enable the APIs, create a service account with the roles/logging.configWriter and roles/serviceusage.serviceUsageConsumer roles, and download a JSON key. The CLI Instructions tab gives a Cloud Shell script that creates the service account and downloads the key for you.
4. Upload the key file under Service Account Key (JSON).
5. Optionally enter a Data Source Name (optional) and a Connection name (optional) for identification.
6. Click Connect. Fencer validates the credentials, creates a log sink in your project with the appropriate filter, and provisions the monitoring pipeline in the background.

Note

Provisioning runs asynchronously. Data usually appears in Operations > Threat Hunting a few minutes after connecting.

Tip

You can connect multiple log source types from the same GCP project. Each log source type requires its own monitor connection with its own log sink.

Examples

Connecting Cloud Audit Logs for threat detection:

1. In Fencer, start a GCP - Google Cloud Platform (Monitor) connection and select GCP Cloud Audit Logs as the Log Source Type.
2. In the GCP Console, create a service account and grant it roles/logging.configWriter and roles/serviceusage.serviceUsageConsumer on the project you want to monitor.
3. Download the service account key JSON file.
4. Upload the key file and click Connect.
5. Fencer creates a log sink that filters for audit log entries and routes them through Pub/Sub into the data lake. Built-in detection rules automatically analyze these events for threats like unauthorized API calls, IAM policy changes, and resource deletions.

Troubleshooting

• Logs not appearing after setup — Confirm the log sink was created in your GCP project by checking Logging > Log Router in the GCP Console, then search for recent events in Operations > Threat Hunting.
• Service account validation fails — Verify the service account has the roles/logging.configWriter and roles/serviceusage.serviceUsageConsumer roles on the target project. Ensure the key JSON file is valid and not expired.
• “Permission denied” creating log sink — The service account needs the logging.sinks.create permission (included in roles/logging.configWriter). Check that the role assignment is at the project level, not just a resource level.
• Missing log types — Some log types require explicit enablement in GCP. For example, VPC Flow Logs must be enabled on each subnet, Data Access audit logs must be enabled for each service you want them for, and Cloud DNS logging must be enabled on your DNS policies. Enable the logging for the relevant GCP service before connecting.

Related pages

• Security Monitoring (SIEM)
• Detection Rules
• Detections
• Network Flows
• GCP Integration