Managing cloud environments is like running a complex machine, and when something goes wrong,
you’d better know which gear slipped. That’s where Google Cloud Platform (GCP) audit logs come in.
Think of them like a flight recorder for your cloud: they capture every major action, every login, every configuration tweak.
But while GCP logs are powerful, they can be overwhelming if you don’t know where to look.
This deep dive is meant to cut through the noise.
We’ll show you how to read these logs like a security analyst: who did what,
when it happened, and how to respond when something doesn’t look right.
Along the way, we’ll focus on a key concept - the “principal part” - and walk through how to
track down critical changes, spot suspicious activity, and take action before it turns into an incident.
Why GCP Audit Logs Matter
Think of GCP audit logs as your cloud’s running commentary. They track everything from user access
to configuration changes, and are essential for:
- Detecting unauthorised access
- Monitoring sensitive operations
- Responding quickly during incidents
GCP splits audit logs into three types:
- Admin Activity Logs — cover configuration and management actions.
- Data Access Logs — track data reads/writes (disabled by default due to volume).
- System Event Logs — capture infrastructure-level operations.
Together, they provide a layered view of your environment.
1. Understanding the Structure of GCP Audit Logs
Each log is a structured JSON entry, packed with metadata. Here’s what matters most:
- principalEmail — who did it
- methodName — what they did
- resourceName — where it happened
- timestamp — when it happened
- serviceName — which GCP service it hit
2. The "Principal Part" - Who Did It?
The most useful field for investigation is often principalEmail. It identifies the user or service account that triggered the action.
This is critical for:
- Tracking who made a change
- Investigating privilege escalations
- Flagging unfamiliar service accounts
Example: A service account suddenly modifies IAM roles - that’s not typical behavior.
Seeing principalEmail in context helps you tell normal from suspicious.
3. Monitoring High-Impact Events
Some actions deserve special attention. Watch for:
- IAM changes — look for SetIamPolicy
- VM and bucket creation/deletion — CreateInstance, DeleteBucket
- Service account key use — CreateServiceAccountKey, DeleteServiceAccountKey
These events are often associated with breach escalation or misconfiguration.
You can use log-based metrics to track these actions, or feed them into alerting tools like Google Cloud Monitoring.
Here’s how a typical IAM policy change might look in a GCP audit log:
You’ll want to monitor these types of changes, especially in critical projects, to prevent unauthorised users from gaining more privileges than they should.
4. Detecting Suspicious Activity
In practice, spotting something odd early makes all the difference. Maybe a VM pops up at 2:45 a.m.,
or a service account you've barely touched starts accessing sensitive storage.
🚩 Common red flags:
- Out-of-hours resource creation
- Access from unusual IPs or geographies
- Spike in PermissionDenied errors
For example, imagine you find a log entry showing a new VM instance was created at an odd time by a service account:
This is something you’ll want to investigate immediately.
5. Responding to Threats
Here’s how to respond when audit logs reveal something suspicious:
- Investigate the principal — who did it, and are they supposed to?
- Review permissions — was this expected or excessive?
- Correlate events — did they do anything else around the same time?
- Take action — disable credentials, rotate keys, or lock accounts
- Set up future alerts — turn anomalies into signal
6. Automating Log Monitoring
Manual log review doesn’t scale. Use these tools to stay ahead:
- Log-based Metrics — create filters for key actions
- Alerts — trigger notifications via Google Cloud Monitoring
- Security Command Center — central dashboard for threats
For example, you could set up an alert to notify you of any IAM policy changes in your projects:
{
"condition": {
"metricThreshold": {
"filter": "resource.type=\"gce_instance\" AND protoPayload.methodName=\"SetIamPolicy\"",
"aggregations": [{
"alignmentPeriod": "60s",
"crossSeriesReducer": "REDUCE_COUNT"
}]
}
}
}
This alert would trigger anytime an IAM policy change is made, helping you stay on top of critical changes.
7. Case Study: Tracing an Unauthorised VM
Scenario: A VM was created with no ticket, no approval, and no one owns up.
What you do:
- Search for CreateInstance in logs
- Find the principalEmail
- Review that identity’s other actions
- Disable access and rotate credentials
- Add alerts for future off-hours VM creation
That’s incident response powered by logs.
Conclusion
GCP audit logs are your early warning system. When decoded effectively, they reveal who’s changing what
and whether you should be concerned.
The more fluently you can read them, the faster you can respond, investigate, and harden your environment.
Don’t treat logs like noise. Treat them like evidence.