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

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

• Part 1: Authentication & Authorization
• Part 2: VPC Service Control, Private Service Connect
• Part 3: Firewall rules, Firewall policies and Cloud Armor

The last article of this story consists to add:
- Ingress traffic filtering at level 7 using Cloud Armor
- Egress traffic filtering at level 4 using firewall rules or firewall policies

Incoming traffic

VPC Service control provides effective protection against data exfiltration but vulnerabilities can be stored in applications themselves. Cloud Armor provides a web application firewall at load balancer level.

For my use case, I added my Cloud Run in a Serverless Network Endpoint Group. This feature allows you to add load balancing features (DDOS protection, WAF, CDN, IAP, etc.) on serverless services like Cloud Run, Cloud Functions or AppEngine.
Once the NEG is created, you can use it to configure backend service in your load balancer.

I’ve attached a basic Cloud Armor Security Policy with preconfigured WAF rules and a rule to allow traffic only from home.

Don’t forget to switch Cloud Run ingress traffic from Internal to Internal and Load balancing.

Outgoing traffic

First create a Private Service Connect to create a private IP that you can use to join Google APIs.

Private Service Connect | VPC | Google Cloud

Then use firewall rules to deny all outgoing traffic except traffic to PSC. The serverless connector is a set of instances managed by Google but deployed on the network. Instances are subject to firewall rules using the special tag vpc-connector or vpc-connector-REGION-CONNECTOR_NAME.
As described in the Google documentation, rules lower than 1000 (higher priority) can be used to limit access from the connector.

Now only outgoing traffic is limited to the PSC IP.

Conclusion

I hope this architecture pattern will help you to improve the security of your cloud environments. Quick wins you can make:

When designing the project:

• Consider complexity and costs versus risk by having a solid data categorization that helps you choose the best architecture.
• Avoid service account keys to deploy terraform code, consider workload identity federation
• Create one service account per service and assign appropriate permissions
• Identify network flows to configure ingress and egress traffic
• Leveraging encryption (not covered in this story)

When deploying the project:

• Create Cloud Logging alerts based on VPC SC or Cloud Armor entries
• Monitor infrastructure changes (policies, firewall rules, IAM, or others configuration updates)
• Limit administrators access to resources (enforce Infra as Code + review process)
• Use Google Cloud Security Health Analytics to detect misconfigurations