Protecting Sensitive Data: Securing Data Pipelines on Google Cloud (part 2)

Jérôme NAHELOU
CodeShake
Published in
3 min readMar 8, 2023

This series of stories will help you to design and secure workload on GCP with different levels of protection.

A well-known security concept called security-in-depth or defense-in-depth involves adding multiple layers of security. In addition to authentication, VPC Service Control protects Google Cloud services for a set of projects (called perimeter). You will be able to control incoming and outgoing traffic for most Google Services based on user context (location, device, IP address, etc).

Lets dive into the classic use case we saw in part 1.

VPC Service Control

IAM provides authentication and authorization, but anyone with leaked service account keys can abuse it. To protect service account key usage only from trust devices or locations, VPC SC will help.

Keep in mind that VPC service control introduces complexity and should be considered as early as possible in the design process.

The concepts behind VPC Service controls are simple: control ingress and egress of managed services within a single perimeter (you cannot attach a project to multiple perimeters).

  1. Create access level (optional): rules to include out of scope devices in the perimeter (IP, Users, Devices, etc.)
  2. Create a perimeter
  3. Select projects within the perimeter
  4. Select Google Services you want to protect
  5. Set ingress rules
  6. Set egress rules

Theory versus Practice

A VPC SC Perimeter now includes my GCP project. I added restrictions to Cloud Run, Pub/Sub and Datastore.

Cloud Run services have been switched to Internal ingress only, a GCP feature to only accept network traffic from my project or project within the perimeter (see https://cloud.google.com/run/docs/securing/ingress).

At this stage, even if my personal user is allowed to invoke the cloud run service, the VPC service control denies requests from outside.

(cloud shell) $ curl -v -H "Authorization: Bearer $(gcloud auth print-identity-token)" https://endpoint.a.run.app/submit
<html><head>
<meta http-equiv="content-type" content="text/html;charset=utf-8">
<title>403 Forbidden</title>
</head>
<body text=#000000 bgcolor=#ffffff>
<h1>Error: Forbidden</h1>
<h2>Access is forbidden.</h2>
<h2></h2>
</body></html>

You can easily find the cloud logging entry:

Without ingress rules, front and back cannot be used. Let’s add an ingress rule to allow all sources within my project to use protected services.
Note: Push subscription does not support custom domains (https://cloud.google.com/pubsub/docs/push#push_subscription_and)

Ingress Rule 1
From:
Identities: ANY_IDENTITY
Source > Projects = iac-jnu-arf
To:
Projects = All projects
Services = All services

I also set an Access Level with:
- my public IPv4 address to invoke the front service from my laptop
- my IPv6 address to use Cloud console from my browser

The same curl command now works as expected, my house is now in the perimeter (it may take a few seconds to take effect).

But cloud run is still not able to use managed services (here Pub/Sub and Datastore).

RTFM hits me… https://cloud.google.com/run/docs/securing/using-vpc-service-controls#deploy-compliant-services

To be considered in the VPC SC perimeter, Cloud run egress traffic must pass through a VPC in the perimeter. That’s why I have:
- Added one connector
- Forced traffic through the connector
- Enabled private google access on the connector subnet
- Replaced *.googleapis.com with restricted.googleapis.com

And now, the messages are saved successfully.

Pros:

  • Fine ingress and egress control for managed services.
  • Dry-run mode
  • Native Cloud Logging support

Cons:

  • Introduce complexity.
  • The serverless connector is not serverless…
  • Advanced access level functionalities are limited without BeyondCorp Enterprise premium.
  • Configuration only at organization level

In the next part, we will see how to filter network traffic using Cloud Armor and Firewall rules/policies.

--

--

CodeShake
CodeShake

Published in CodeShake

Learnings and insights from SFEIR community.

Jérôme NAHELOU
Jérôme NAHELOU

Written by Jérôme NAHELOU

Cloud rider at SFEIR the day, Akita Inu lover #MyAkitaInuIsNotAWolf