Managing multiple projects in Google Cloud often involves keeping a close eye on admin activity logs for security and auditing purposes. However, consolidating these logs across projects can be tricky. This blog post dives into strategies for routing your Google Cloud admin activity audit logs.
Why centralize admin activity audit logs?
Before we jump into the how, let’s quickly cover the why. Here are some reasons it may benefit your team to centralize your Google Cloud admin activity logs:
- See the complete picture of admin activity across all your projects, enabling you to spot and address potential security risks more quickly.
- Meet compliance requirements by having all admin activity logs in a single, easily accessible location.
- Export your centralized logs to your preferred third-party analysis tools for advanced threat detection, correlation, and reporting.
Considerations to keep in mind
Now that we have covered the why, here are few things to consider before you decide to centralize yourGoogle Cloud admin activity logs:
- For larger organizations with hundreds/thousands of projects, centralizing logs at the folder or organization levels using aggregated sinks is highly recommended. See this blog post on best practices for log centralization.
- Storage costs: admin activity audit logs stored in the _Required bucket of a Google Cloud project by default are free. Centralizing them in a different log bucket will incur storage costs.
- Log sinks support various destinations, which we cover in more detail later. Of the possible destinations, using a Google Cloud project is recommended as it allows that project to act as a central management hub for log processing.
Routing admin activity audit logs
Google Cloud’s core logging functions are managed through Cloud Logging. The diagram above shows how logs flow into a Google Cloud project. As depicted, logs from diverse sources such as API calls, Google Cloud services, and VM agents, first come to Cloud Logging through the Log Router. The log sinks within the router examines each log entry and employs predefined inclusion and exclusion filters to determine its destination.
Cloud Logging provides two predefined sinks for each Google Cloud project, billing account, folder, and organization: _Required and _Default. All logs that are generated in a resource are automatically processed through these two sinks and then are stored either in the correspondingly named _Required or _Default log buckets. Ultimately, admin activity audit logs are routed to the dedicated _Required log bucket by default. This bucket is subject to security measures designed to prevent any malicious deletion of logs, ensuring the preservation of critical data.
Log Sinks gives you fine-grained control over the routing of these logs. By specifying inclusion and exclusion filters based on attributes like log severity and resource type, you can direct specific log streams to tailored destinations. This is the mechanism that can be used to route admin activity audit logs to a destination of your choice.
Log sink admin activity audit logs configuration
There are several differentGoogle Cloud destinations we can use for our log sink: Log Buckets, Google Cloud Storage Buckets, BigQuery, Pub/Sub, and Google Cloud Projects. When a sink is configured to route logs to another Google Cloud project as destination, admin activity audit logs are not routed to the _Required log bucket in the destination project. The _Required bucket will only have admin activity audit logs of the project it belongs to.
We will need to take the following into account when directing admin activity logs from source projects to a destination project:
When selecting a Log Bucket, Google Cloud Bucket, BigQuery, or Pub/Sub as your destination… The log sink will need to have an inclusion filter set to capture all admin activity audit logs of the source project.
Log Source is a Project
logName="projects/gcp-project-a/logs/cloudaudit.googleapis.com%2Factivity"
Log Source is a Folder
logName="folders/gcp-folder-a/logs/cloudaudit.googleapis.com%2Factivity"
Log source is a Organization
logName="organizations/gcp-org-a/logs/cloudaudit.googleapis.com%2Factivity"
The destination log bucket will need to already exist and the Writer Identity of the log sink will require the correct permissions.
When selecting a Google Cloud Project as your destination… admin activity audit logs won’t automatically be directed to the _Required log bucket. To ensure all logs are captured, you can create an additional sink within your destination to redirect logs to an already existing Log Bucket or another source. This extra sink should have the same inclusion filter as the log sink configured in the source project.
In the above example, both log sinks depicted would have the same inclusion filter looking for Admin activity audit logs. In order for the log sink to be able to write to a destination such as a log bucket, it is also important to ensure that the writer identity of the sink has the appropriate permissions.
The following command will create a gcp-log-sink-a in gcp-project-a
gcloud logging sinks create gcp-log-sink-a logging.googleapis.com/projects/gcp-project-b --log-filter='logName="projects/gcp-project-a/logs/cloudaudit.googleapis.com%2Factivity"'
The following command will create a gcp-log-sink-b in gcp-project-b
gcloud logging sinks create gcp-log-sink-b logging.googleapis.com/projects/gcp-project-b/locations/global/buckets/_Default --log-filter='logName="projects/gcp-project-a/logs/cloudaudit.googleapis.com%2Factivity"'
The solutions described above will allow you to route all logs, including admin activity audit logs to a central location. This allows for a comprehensive view of all admin activity across your environment and enables prompt identification of potential security threats. Whether you choose to direct logs to a dedicated log bucket, a Google Cloud Storage bucket, BigQuery, Pub/Sub, or even another Google Cloud project, the flexibility of log sinks provides you with the control you need to achieve your specific audit and security goals.
