Cloud Audit Logs overview

Google Cloud services write audit logs that record administrative activities and resource access. You can use Cloud Audit Logs to answer "who did what, where, and when?" within your Google Cloud resources with the same level of transparency as in on-premises environments. These audit logs help your security, auditing, and compliance teams monitor Google Cloud data and systems for vulnerabilities or data misuse.

Google Cloud services producing audit logs

For a list of Google Cloud services that provide audit logs, see Google Cloud services with audit logs. All Google Cloud services will eventually provide audit logs.

Google Cloud MCP servers write Data Access audit logs. Data Access audit logs written by Google Cloud MCP servers API calls are service-specific and use the format SERVICE_NAME.googleapis.com/mcp. You can enable these Data Access logs by turning on audit logging for mcp.googleapis.com in the IAM AuditConfig object. For more information about audit logging for Google Cloud MCP servers, see Google Cloud MCP servers audit logging.

For an overview of Google Workspace audit logs, see Audit logs for Google Workspace.

Required roles

To view audit logs, you must have the appropriate Identity and Access Management (IAM) permissions and roles:

• To get the permissions that you need to get read-only access to Admin Activity, Policy Denied, and System Event audit logs, ask your administrator to grant you the Logs Viewer (roles/logging.viewer) IAM role on your project.

  If you have only the Logs Viewer role (roles/logging.viewer), then you cannot view Data Access audit logs that are in the _Default bucket.

• To get the permissions that you need to get access to all logs in the _Required and _Default buckets, including Data Access logs, ask your administrator to grant you the Private Logs Viewer (roles/logging.privateLogViewer) IAM role on your project.

  The Private Logs Viewer role (roles/logging.privateLogViewer) includes the permissions contained in the Logs Viewer role (roles/logging.viewer), and those necessary to read Data Access audit logs in the _Default bucket.

For more information about the IAM permissions and roles that apply to audit logs data, see Access control with IAM.

Types of audit logs

Cloud Audit Logs provides the following audit logs for each Google Cloud project, folder, and organization:

• Admin Activity audit logs
• Data Access audit logs
• System Event audit logs
• Policy Denied audit logs

Admin Activity audit logs

Admin Activity audit logs are log entries written by user-driven API calls or other actions that modify the configuration or metadata of resources. For example, these logs record when users create VM instances or change Identity and Access Management permissions.

Admin Activity audit logs are always written; you can't configure, exclude, or disable them. Even if you disable the Cloud Logging API, Admin Activity audit logs are still generated.

For a list of services that write Admin Activity audit logs and detailed information about which activities generate those logs, see Google Cloud services with audit logs.

Data Access audit logs

Data Access audit logs are log entries written by API calls that read the configuration or metadata of resources. They are also written by user-driven API calls that create, modify, or read user-provided resource data.

Publicly available resources that have the Identity and Access Management policies allAuthenticatedUsers or allUsers don't generate audit logs. Resources that can be accessed without logging into a Google Cloud account, Google Workspace, Cloud Identity, or Drive Enterprise account don't generate audit logs. This helps protect end-user identities and information.

Except for BigQuery, Data Access audit logs are disabled by default because they can generate large volumes of data. To record Data Access audit logs for Google Cloud services other than BigQuery, you must explicitly enable them. Data Access audit logs are written to the Google Cloud project whose data is accessed. Enabling these logs might result in your Google Cloud project being charged for additional log usage. For instructions on enabling and configuring Data Access audit logs, see Enable Data Access audit logs.

For a list of services that write Data Access audit logs and detailed information about which activities generate those logs, see Google Cloud services with audit logs.

Data Access audit logs are stored in the _Default log bucket unless you've routed them elsewhere. For more information, see the Storing and routing audit logs section of this page.

System Event audit logs

System Event audit logs are log entries written by Google Cloud systems and managed service agents that modify the configuration of resources. System Event audit logs aren't driven by direct user action. For example, a System Event audit log is written when VMs are automatically added to or removed from managed instance groups (MIGs) due to autoscaling.

System Event audit logs are always written; you can't configure, exclude, or disable them.

For a list of services that write System Event audit logs and detailed information about which activities generate those logs, see Google Cloud services with audit logs.

Policy Denied audit logs

Policy Denied audit logs are log entries written when a Google Cloud service denies access to a user or service account because of a security policy violation.

Policy Denied audit logs are generated by default and your Google Cloud project is charged for log storage. You can't disable Policy Denied audit logs, but you can use exclusion filters to prevent Policy Denied audit logs from being stored in Cloud Logging.

For a list of services that write Policy Denied audit logs and detailed information about which activities generate those logs, see Google Cloud services with audit logs.

Audit log entry structure

Every audit log entry in Cloud Logging is an object of type LogEntry. What distinguishes an audit log entry from other log entries is the protoPayload field; this field contains an AuditLog object that stores the audit logging data.

To understand how to read and interpret audit log entries, and to view a sample entry, see Understanding audit logs.

Log name

Cloud Audit Logs log names include the following:

• Resource identifiers indicating the Google Cloud project or other Google Cloud entity that owns the audit logs.

• The string cloudaudit.googleapis.com.

• A string that indicates whether the log contains Admin Activity, Data Access, Policy Denied, or System Event audit logging data.

The following are the audit log names, including variables for the resource identifiers:

   projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Factivity
   projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fdata_access
   projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fsystem_event
   projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fpolicy

   folders/FOLDER_ID/logs/cloudaudit.googleapis.com%2Factivity
   folders/FOLDER_ID/logs/cloudaudit.googleapis.com%2Fdata_access
   folders/FOLDER_ID/logs/cloudaudit.googleapis.com%2Fsystem_event
   folders/FOLDER_ID/logs/cloudaudit.googleapis.com%2Fpolicy

   billingAccounts/BILLING_ACCOUNT_ID/logs/cloudaudit.googleapis.com%2Factivity
   billingAccounts/BILLING_ACCOUNT_ID/logs/cloudaudit.googleapis.com%2Fdata_access
   billingAccounts/BILLING_ACCOUNT_ID/logs/cloudaudit.googleapis.com%2Fsystem_event
   billingAccounts/BILLING_ACCOUNT_ID/logs/cloudaudit.googleapis.com%2Fpolicy

   organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity
   organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access
   organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fsystem_event
   organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fpolicy

Caller identities in audit logs

Audit logs record the identity that performed the logged operations on the Google Cloud resource. The caller's identity is held in the AuthenticationInfo field of AuditLog objects.

Audit logging doesn't redact the caller's principal email address for any access that succeeds or for any write operation.

For read-only operations that fail with a "permission denied" error, Audit logging might redact the caller's principal email address unless the caller is a service account.

In addition to the conditions listed above, the following applies to certain Google Cloud services:

• Legacy App Engine API: Identities aren't collected.

• BigQuery: Caller identities and IP addresses, as well as some resource names, are redacted from the audit logs, unless certain conditions are met.

• Cloud Storage: When Cloud Storage usage logs are enabled, Cloud Storage writes usage data to the Cloud Storage bucket, which generates Data Access audit logs for the bucket. The generated Data Access audit log has its caller identity redacted.

• Firestore: If a JSON Web Token (JWT) was used for third-party authentication, then the thirdPartyPrincipal field includes the token's header and payload. For example, audit logs for requests authenticated with Firebase Authentication include that request's auth token.

• VPC Service Controls: For Policy Denied audit logs, the following redaction occurs:

  • Parts of the caller email addresses might be redacted and replaced by three period characters ....

  • Some caller email addresses belonging to the domain google.com are redacted and replaced by google-internal.

• Organization Policy: Parts of the caller email addresses might be redacted and replaced by three period characters ....

IP address of the caller in audit logs

The IP address of the caller is held in the RequestMetadata.callerIp field of the AuditLog object:

• For a caller from the internet, the address is a public IPv4 or IPv6 address.
• For calls made from inside the internal production network from one Google Cloud service to another, the callerIp is redacted to "private". This includes calls made by Google-owned service accounts (service agents) even when initiated by a user, or calls initiated by Google's internal infrastructure.
• For a caller from a Compute Engine VM with an external IP address, the callerIp is the external address of the VM. This applies to both standard VMs and Google-managed VMs, such as Google Kubernetes Engine nodes. In multi-service flows, such as Cloud Logging calling Cloud KMS, the service propagates the immediate caller's origin unless explicit identity delegation is configured. As a result, an external address might appear instead of "private".
• For a caller from a Compute Engine VM without an external IP address, if the VM is in the same organization or project as the accessed resource, then callerIp is the VM's internal IPv4 address. Otherwise, the callerIp is redacted to "gce-internal-ip". For more information, see VPC network overview.

Viewing audit logs

You can query for all audit logs or you can query for logs by their audit log name. The audit log name includes the resource identifier of the Google Cloud project, folder, billing account, or organization for which you want to view audit logging information. Your queries can specify indexed LogEntry fields. For more information about querying your logs, see Build queries in the Logs Explorer

The Logs Explorer lets you view filter individual log entries. If you want to use SQL to analyze groups of log entries, then use the Log Analytics page. For more information, see:

• Query and view logs in Observability Analytics.
• Sample queries for security insights.
• Chart query results.

Most audit logs can be viewed in Cloud Logging by using the Google Cloud console, the Google Cloud CLI, or the Logging API. However, for audit logs related to billing, you can only use the Google Cloud CLI or the Logging API.