This page provides supplemental information for using Cloud Audit Logging with Compute Engine. Use Cloud Audit Logging to generate logs for API operations performed in Google Compute Engine.
Audit logs are not the same as activity logs. Audit logs help you determine who did what, where, and when. Specifically, audit logs track how your Compute Engine resources are modified and accessed within your Google Cloud Platform projects for auditing purposes. Activity logs let you track certain events that affect your project, including API calls that change the state of a resource and system events, but does not return authorization information, API request information, or API responses. Activity logs also do not include any read-only operations.
Cloud Audit Logging returns two types of logs:
Admin activity logs: Contains log entries for operations that modify the configuration or metadata of a Compute Engine resource. Any API call that modifies a resource such as creation, deletion, updating, or modifying a resource using a custom verb fall into this category.
Data access logs: Contains log entries for operations that perform read-only operations do not modify any data, such as get, list, and aggregated list methods. Unlike audit logs for other services, Compute Engine only has
ADMIN_READdata access logs and do not generally offer
DATA_WRITElogs. This is because
DATA_WRITElogs are only used for services that store and manage user data such as Google Cloud Storage, Google Cloud Spanner, and Google Cloud SQL, which does not apply to Compute Engine. There is one exception to this rule: the
instance.getSerialPortOutputdoes generate a
DATA_READlog because the method reads data directly from the VM instance.
The following table summarizes which Compute Engine operations fall into each log type:
|Log entry type||Sub-type||Operations|
||Get the contents of the serial port console|
Compute Engine logs use an
object and follows the same format as other Cloud Audit Logging logs. Logs
contain information such as:
- The user who made the request, including the email address of that user.
- The resource name on which the request was made.
- The outcome of the request.
Admin activity logs are recorded by default. These logs do not count towards your log ingestion quota.
Data access logs are not recorded by default. These logs count towards your log ingestion quota. To learn how to enable logs for data access-type operations, see Configuring Data Access Logs.
The following users can view admin activity logs:
- Project owners, editors, and viewers.
- Users with the Logs Viewer IAM role.
- Users with the
The following users can view data access logs:
- Project owners.
- Users with the Private Logs Viewer IAM role.
- Users with the
See Adding IAM members to a project for instructions on granting access.
For instructions on filtering logs in the Logs Viewer, see the Cloud Audit Logging guide.
Data redaction in audit logs
Audit logs record the request and response data of the API actions that were performed. However, in the following circumstances, the request or response info is unavailable or is redacted:
project.setCommonInstanceMetadataAPI requests, the metadata portion of the request body is redacted to avoid logging sensitive information sent in the metadata.
- Sensitive fields are redacted from requests, such as private keys for SSL certificates and customer-supplied encryption keys for disks.
- For get and list responses, the response body is redacted to avoid logging private information.