Monitor VPC-SC violations on your GCP org with Data Studio

TL;DR: Google Cloud VPC Service Control is a key feature to mitigate data exfiltration in your organization. Enforcing it on existing projects can be challenging: you can make resources unavailable or break production applications and workloads. In this article I’d like to share some tips to minimize issues and problems when activating it, using Data Studio(*) to monitor VPC-SC violations.

(*) Note: Data Studio won’t work once you enable VPC-SC, you’ll need to use a different tool if the BigQuery dataset is enforced by VPC-SC.

To mitigate data exfiltration your organization may have identified VPC Service Control as a key feature to enable in your GCP organization. The feature will help you create security perimeters around your projects. Within those perimeters you’ll be able to decide which services could be reached, and which are the allowed sources (based on the User identity, IP or device type).

If you are going to enable the feature on an organization where there are live production GCP workloads, this can be challenging. If you misconfigure VPC-SC you may end up inhibiting communication between resources that need to communicate.

To mitigate issues I would recommend a 3 step approach:

1. Get familiar with the feature
2. Design your Perimeters architecture
3. Setup Dry-Run mode, monitor and fix violations

In this article I will cover in depth the importance of fixing VPC-SC violations, and share a dashboard I wrote to help monitor and group them.

Get familiar with the feature

You can find a lot of documentation on this. I do not want to cover VPC-SC features in this article, but since from my experience VPC-SC is an easy to misread feature, I really suggest you to get familiar with it and make some tests on your organization.

I would suggest to test simple scenarios such as:

• A GCS bucket or Bigquery dataset in a project within a VPC-SC perimeter: what happens if I reach the resource from within the perimeter? and from outside the perimeter?
• What does an Access Level enable?
• How do VPC-SC and shared VPC interfere?

Design your Perimeters architecture

Once you are familiar with VPC-SC features, you can start designing your perimeters architecture. List your business requirements and identify VPC-SC features to address each of them. Below you can find some patterns I saw across several organizations:

• Create a Perimeter for each shared VPC configured in your organization.
• Create a Perimeter for each environment (production, integration, dev, …), but less granular than your shared VPC configuration.
• Create an Access Level for your Company Internet proxy. The Access Level will let your employees access resources on the GCP console while connected to the corporate network.
• Create a perimeter for the landing project and bridge perimeters between the landing project and prod / no prod projects to let onprem resources access GCP resources protected by VPC Service Controls.

Below you can find an example architecture:

Setup dry run mode, monitor and fix violations

Once you have identified your VPC-SC architecture, implement it in dry run mode and monitor your logs to check if you were able to capture all your use cases and your architecture is addressing all your needs.

Checking logs across projects can be challenging. My suggestion would be to create a log export sync to Bigquery at folder or organization level. You can create one with the following gcloud command:

gcloud beta logging sinks create SINK_NAME\
bigquery.googleapis.com/projects/PROJECT_ID/datasets/DATASET_NAME \
 - folder=FOLDER_ID \
 - include-children \
 - log-filter='protoPayload.metadata.@type:"type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"' \
 - use-partitioned-tables

From now on GCP will copy your logs into the specified Bigquery dataset:

To easily navigate and group logs you can create a simple Data Studio dashboard:

You can create a Data Studio dataset with the following query:

SELECT
   *,
    CASE
      WHEN REGEXP_CONTAINS(protopayload_auditlog.status.message,'(Dry Run Mode)*') THEN 'Dry Run'
      ELSE 'Enforced'
    END enforced_type,
    CASE
      WHEN REGEXP_CONTAINS(protopayload_auditlog.requestMetadata.callerIp, r"(^127\.)|(^10\.)|(^172\.1[6-9]\.)|(^172\.2[0-9]\.)|(^172\.3[0-1]\.)|(^192\.168\.)") OR protopayload_auditlog.requestMetadata.callerIp = 'private' THEN 1
      ELSE 0
    END internal_ip,
    REGEXP_EXTRACT(protopayload_auditlog.metadataJson, r'servicePerimeterName":"[a-zA-Z]+\/[\d]+\/[a-zA-Z]+\/([a-zA-Z]+)') as perimeter,
    REGEXP_EXTRACT(protopayload_auditlog.metadataJson, r'violationReason":"([a-zA-Z_]+)') as violation_reason,    
FROM 
  `PROJECT_ID.DATASET_NAME.cloudaudit_googleapis_com_policy`

and copy the example dashboard based on the query above.

In the dashboard you can group violation on several dimensions:

• by project

• by perimeter

• by violation reason

You can create the grouping criteria that helps you the most to speed up actions to fix unexpected violations.

Next Steps

Once you have fixed all unexpected violations from your VPC-SC logs, enforce your configuration and keep all your data more securely on your GCP resources. You are now able to mitigate data exfiltration on your GCP resources by limiting device type or IPs that can access your data!!!