Google Cloud Platform — Service Account Key Usage Visibility

Google Cloud Platform — Service Account Key Usage Visibility

Google Cloud Platform — Service Account Key Usage Visibility

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/c71e040fb4b71d798ce4baca14e15ab62115aaef"
   },
 }
}

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

Create a Log Sink Export

Create a Log Sink Export

3. Select Convert to Advanced Filter in the dropdown

Convert to Advanced Filter

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
Edit Sink

Edit Sink

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)

Create Sink

Create Sink

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.

Big Query Results

Big Query Results

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:

  1. Create a Service Account and associated Service Account Key
  2. Using gcloud, activate the service account key → gcloud auth activate-service-account …
  3. 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

Explore your data with Data Studio

Explore your data 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.

Visualize your Data

Visualize your Data

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.

About Us

ScaleSec is a service-disabled, veteran-owned small business (SDVOSB) for cloud security and compliance that helps innovators meet the requirements of their most scrutinizing customers. We specialize in cloud security engineering and cloud compliance. Our team of experts guides customers through complex cloud security challenges, from foundations to implementation, audit preparation and beyond. Learn more at https://scalesec.com.

We are hiring!

A Comparison of Secrets Managers for GCP

With so many options to manage your secrets in the cloud, the decision on how to handle secrets can be cumbersome for organizations of many sizes.

Next article

Here for you

Have questions? Leverage our expertise to help you meet your business goals with a strong security posture.

Join us

ScaleSec is a well-connected, fully remote team. We thrive in the great undocumented beyond. We’re hiring in most US metros.

Get in touch

Considering cloud? Want to optimize and transform your existing digital portfolio?
Reach out to us.

Gap Assessment

Get perspective. Address security comprehensively.

Prepare for compliance.

ScaleSec
San Diego, CA 92120, United States

619-SCALE15

© 2020 ScaleSec. All rights reserved. | Privacy Policy