Follow Use gcloud logging read with a filter on cloudaudit.googleapis.com, or run the same query in Logs Explorer and download the results as JSON:
gcloud logging read 'logName:"cloudaudit.googleapis.com" AND timestamp>="2026-10-19T00:00:00Z" AND timestamp<"2026-10-20T00:00:00Z"' \
--project=my-project --format=json > gcp_audit_1019.json
Admin Activity audit logs are always on and kept for 400 days. Data Access logs are off by default, except for BigQuery, and kept for 30 days once enabled.
Cloud Audit Logs record who changed what in your Google Cloud projects: IAM grants, new service account keys, firewall changes, VMs spun up in odd regions. Prime Core has 140 detection rules for Google Cloud audit logs, mapped to 74 MITRE ATT&CK techniques. Among them: abuse of cloud accounts (T1078.004), extra credentials such as new service account keys (T1098.001) and tampering with logging itself (T1562.008).
Before you start
Know which audit log you need.
| Type | On by default? | Retention | What’s in it |
|---|---|---|---|
| Admin Activity | Always, can’t be disabled | 400 days | Config and IAM changes |
| System Event | Always | 400 days | Actions Google systems took on your resources |
| Data Access | No (except BigQuery) | 30 days | Reads of data and metadata |
| Policy Denied | Yes | 30 days | Requests blocked by security policies |
If the question is “who read this bucket?” and Data Access logs were never enabled, the answer isn’t in Cloud Logging.
Permissions. Logs Viewer (roles/logging.viewer) covers Admin Activity, System Event and Policy Denied. Data Access logs need Private Logs Viewer (roles/logging.privateLogViewer).
Scope. Audit logs live per project. Organization- and folder-level activity has its own logs. Query those with –organization=<ORG_ID> or –folder=<FOLDER_ID> instead of –project.
Option 1: Logs Explorer
In the console, open Logging → Logs Explorer, enter logName:”cloudaudit.googleapis.com”, set the time range, run the query, then download the results as JSON. The download is capped. For larger ranges, use gcloud.
Option 2: gcloud logging read
The command at the top is the basic form. Three details save time.
Always put the time window in the filter. Without a timestamp condition, gcloud logging read silently limits itself to the last day (–freshness defaults to 1d). That surprises nearly everyone once.
Raise the limit when needed. Add –limit=100000 (or whatever fits) for large windows.
Flatten for upload. The output is one JSON array. Turn it into one entry per line:
jq -c '.[]' gcp_audit_1019.json > gcp_audit_1019.jsonl
Useful narrower filters:
# Admin Activity only
logName="projects/my-project/logs/cloudaudit.googleapis.com%2Factivity"
# new service account keys
protoPayload.methodName="google.iam.admin.v1.CreateServiceAccountKey"
# everything one identity did
protoPayload.authenticationInfo.principalEmail="suspicious-sa@my-project.iam.gserviceaccount.com"
Option 3: Bulk history from sinks
If your organization routes audit logs through a sink to Cloud Storage or BigQuery, that copy may go back further than the buckets above. Pull the files with gcloud storage cp, or query BigQuery and export the result as JSON.
What to look for
| Method or field | Why it matters |
|---|---|
| CreateServiceAccountKey | Long-lived credentials an attacker can take away |
| SetIamPolicy | Role grants; watch for roles/owner, roles/editor and allUsers |
| UpdateSink, DeleteSink, new exclusions | Someone redirecting or silencing logs |
| v1.compute.instances.insert in unusual regions | The classic cryptomining footprint |
| Bursts with status.code: 7 (PERMISSION_DENIED) | Stolen credentials feeling out what they can do |
Upload, sanitize and review in LogTotal
- Upload. Open logtotal.com and drop in the .jsonl file.
- Sanitize. [what gets masked: principal emails, project IDs, IPs, resource names]. Look it over before you continue.
- Review.
When it goes wrong
| Symptom | Likely cause | Fix |
|---|---|---|
| Only the last 24 hours come back | No timestamp in the filter, so –freshness=1d applies | Put the window in the filter |
| No Data Access entries | Data Access logs were never enabled | Expected; enable them for the future |
| PERMISSION_DENIED reading logs | Missing Private Logs Viewer for Data Access | Request roles/logging.privateLogViewer |
| Results stop short | Default or explicit –limit reached | Raise –limit, or split the window |
| Org-level changes missing | You queried a project | Use –organization |
FAQ
Are Google Workspace logs in here?
Only if your organization shares Workspace data with Google Cloud, and then at the organization level.
What about GKE?
GKE writes its Kubernetes audit logs into Cloud Audit Logs too
