Google Cloud Platform — Service Account Key Usage Visibility

One of the first tenets of any cloud security strategy should be to ensure a high degree of visibility across your cloud resources. Visibility can come from a variety of sources in GCP, but the main source of visibility data in GCP is through Audit Logs. GCP Audit Logs provide visibility to answer the question “Who did what and when?” in the environment.

In this article, we will cover a newly released feature in GCP which can provide Security Operations teams increased visibility into Service Account Keys Usage.

Service Account Primer

For a quick primer, let’s go over the basics of what Service Accounts are, what a Service Account Key is, and when to use Service Account Keys.

What are Service Accounts?

Service Accounts are a special kind of account which are intended to be used by an application or Compute Engine VM instance to make authorized calls to GCP APIs. Service Accounts allow us to provide a unique identity to the application or VM, removing the need to provide the credentials of someone’s individual user account.

What are Service Account Keys?

Service Account Keys are public/private RSA key pairs which are used to authenticate to Google Cloud APIs. Service Account Keys come in two forms; Google-Managed and User-Managed. This article will focus on User-Managed Service Account Keys. Google defines a User-Managed Service Account Key as follows:

“User-managed key pairs imply that you own both the public and private portions of a key pair. You can create one or more user-managed key pairs (also known as “external” keys) that can be used from outside of Google Cloud. Google only stores the public portion of a user-managed key.”

User-Managed Keys present a higher level of security risk to the GCP customer, as it is the customer’s responsibility to secure the Service Account Keys.

When to use User-Managed Service Account Keys?

If the application is running outside of GCP (AWS, Azure, On-Prem), it is recommended to provide your application with a User-Managed Service Account Key.

Your application will use this Service Account key to obtain an OAuth token which is presented with each API request to GCP.

Visibility into Service Account Keys Usage

It is a GCP Security best practice to keep User-Managed Service Account Keys secure and to monitor their usage. It is critically important to monitor Service Account usage to ensure that a User-Managed Service Account Key has not been compromised. Should a bad actor obtain a User-Managed Service Account Key, they will now have access into your environment with the permissions associated with that Service Account (assuming no other controls, such as using Access Context or VPC Service Controls, exist).

Historically, it was not possible to associate which Service Account Key was used by a Service Account to make an API call to the Google Cloud Platform. The audit log (example below) would show that an API request was made by a Service Account, but it did not specify how or with which key.

protoPayload: {
 @type: "type.googleapis.com/google.cloud.audit.AuditLog"
 authenticationInfo: {
  principalEmail: "my-service-
account@myproject.iam.gserviceaccount.com"
 }

If your Service Account had more than one key associated with it, it was impossible to determine which key had been used. This lack of traceability caused issues during an incident response scenario or when performing a cleanup of Service Account Keys and trying to determine stale keys.

Thankfully, GCP has released a new feature which provides the resource name of the Service Account Key used for the API request. An example of the new log format can be found below.

{
"protoPayload": {
"@type": "type.googleapis.com/google.cloud.audit.AuditLog",
"authenticationInfo": {
"principalEmail": "my-service-account@my-
project.iam.gserviceaccount.com",
"serviceAccountKeyName": 
"//iam.googleapis.com/projects/my-
project/serviceAccounts/my-service-account@my-
project.iam.gserviceaccount.com/keys/c71e040fb4
b71d798ce4baca14e15ab62115aaef" },
}
}

How Security Operations Teams Use This Data

Let’s take what we’ve learned in the first section and begin to gain some valuable insight into Service Account Key usage data across our project. This same concept could be extended to the entire Organization by using an Aggregated Sink at the Organization Level.

In the following sections, we’ll perform a tutorial on how to analyze Service Account Key usage using BigQuery and visualize it with Data Studio.

Step 1: Create a Log Sink Export

First, create a Log Sink Export to push the logs into BigQuery.

1. Navigate to Logging -> Log Router

2. Select CREATE SINK

3. Select Convert to Advanced Filter in the dropdown

4. Enter the following query into the search bar. Be sure to replace <PROJECT> with your Project ID:

logName:"projects/<PROJECT>/logs/cloudaudit.googleapis.com" 
protoPayload.authenticationInfo.serviceAccountKeyName:"*"

Translated, the above query will select all logs:

with log name which contains a match of projects/<PROJECT>/logs/cloudaudit.googleapis.com

AND

contain a field for protoPayload.authenticationInfo.serviceAccountKeyName

5. Navigate to the “Edit Sink” pane on the right and enter information for you sink:

Sink Name: SA-Key-Logs-BQ-Export
Sink Service: BigQuery
Use Partitioned Tables : Selected
Sink Destination: Choose Create new BigQuery dataset. A new window will pop up and ask to name the new BigQuery Dataset

6. Select the Create Sink Button. A new window will pop up with the service account which has been created for this sink (keep this Service Account Name handy)

Step 2: Run a Query

Wait a few minutes for data to start showing up in BigQuery. You will see two tables being created:

cloudaudit_googleapis_com_activity
cloudaudit_googleapis_com_data_access

Run the following query:

SELECT protopayload*auditlog.authenticationInfo.serviceAccountKeyName,
COUNT(\*)
FROM `Demo_SA_Key_Audit_Logs.cloudaudit_googleapis_com*\*`
GROUP BY protopayload_auditlog.authenticationInfo.serviceAccountKeyName

This Query will return the number of API calls by Service Account Key.

The GCP Audit logs contain a lot of different data points that are useful during analysis. We’ve provided a very simple example here, but there are endless possibilities of more advanced uses.

Important Note: The log sink filter was configured to only send audit logs which used a Service Account Key for Authentication. If Service Account Keys are not being used in your project, no data will show up in the table. To generate data:

Create a Service Account and associated Service Account Key
Using gcloud, activate the service account key → gcloud auth activate-service-account …
Run a few gcloud commands to create data → gcloud compute instances create test …

Step 3: Visualize the Data

A bonus feature of using BigQuery for log analysis is the simple one-click integration it has with Data Studio, Google’s Data Visualization Product.

To push query results to Data Studio, perform the following:

1. Select the Explore Data Dropdown and choose Explore with Data Studio

2. Visualize your Data

The Query results are passed over to Data Studio and can now be used to quickly generate charts and dashboards based on the query results.

For a walkthrough on different ways to visualize your data with BigQuery and Data Studio, see the tutorial in the GCP Documentation.

By following the steps in this article, GCP users can gain visibility into the actions performed by a specific service account key and use Data Studio to visualize the data. There is no action required by users to enable this functionality on GCP and should be reflected in new Stackdriver logs. This same pattern can also be applied to any other security use cases, such as Firewall Rule changes, where specific actions are logged in Stackdriver.