GCP Enterprise Landing Zone | Securing the ingress traffic for Cloud Run through the Palo Alto VM Series ( NGFW )

Ankit Awal
Google Cloud - Community
4 min readNov 14, 2022

It’s 2022, We are living in an era where Cloud transformation is in high demand. Earlier, the startups were flexible to onboard to the cloud environments to avail the benefits of cloud — mainly innovation and agility.

It was easier for the startups to start using the cloud since they had none or less baggage of on-premises and associated vendors / system dependencies. The Enterprises had huge challenges to get started on cloud mainly due to the following reason :-

  1. Dependent Systems / Vendors
  2. Outdated Systems / Applications
  3. Adherence to Security Compliance and Audits

The Cloud has been maturing since it’s inception and slowly paving ways through documentation, new features to enables enterprises to be comfortable to move to cloud and avail the business benefits that it brings.

An Organisation can utilise cloud broadly into 3 different ways. Every way provides different business benefits. These are :-

  1. IaaS ( Infrastructure as a service )
  2. PaaS ( Platform as a service )
  3. SaaS ( Software as a service )

Enterprises usually onboard to cloud with the expectation to use security as per their compliance with their auditing and security.

One of the major requirement is to enable NGFW inspection for the internet traffic before hitting the internal application.

This is applicable for the IaaS and PaaS since the SaaS are software deployed on a URL and managed by a seperate team

Enabling NGFW in IaaS ( Hub and Spoke Model )

Figure 1.1

Figure 1.1 is a sample architecture to enable the IaaS on GCP

On a high level, In the following architecture,

  1. The internet traffic enters from the public LB
  2. This traffic is inspected by the NGFW
  3. Finally, the traffic is forwarded to the internal application and the return traffic is initiated completing the entire flow

Enabling NGFW in PaaS ( Hub and Spoke Model )

PaaS stands for Platform as a Service. We would be considering Cloud Run for the scope of this document. ( Only Cloud Run is supported as of now )

Till recently, it was challenging to inspect traffic through NGFW from internet to Cloud Run. Following were the ways to setup Cloud Run on landing zone :-

  1. When we spin a Cloud Run application, we get a public url associated with the application. We can use this public URL to load the application. Unfortunately, we are not be able to inspect the traffic to the cloud run through the NGFW using the public url.
  2. We can extend the above setup along with a Global L7 Load Balancer in the same project where Cloud Run is spinned up. The Global L7 Load Balancer has the functionality of Serverless NEG that can be leveraged to connect to the Cloud Run privately. Cloud Armor could also be integrated to the load balancer. This setup provides additional security in terms of enabling the WAF capabilities in front of the Cloud Run. Unfortunately, the traffic won’t be inspected from the NGFW

There was no way to connect Cloud Run while inspecting through the NGFW in a private and secure way

GCP has released a new feature on 9th May’2022 that enables the internal lb to connect to Cloud Run privately. This is in preview mode as on 14th Nov’2022 ( https://cloud.google.com/load-balancing/docs/l7-internal/setting-up-l7-internal-serverless )

We can leverage this new feature to connect the Cloud Run through the NGFW in a secure manner. The high level architecture would look like :-

Figure 1.2

Ingress :

  1. Internet traffic enters from the Public LB
  2. This traffic gets inspected through the NGFW
  3. The traffic is forwarded to the internal load balancer present in the spoke ( Spoke 1 ) project that is internally connected to the Cloud Run

Egress :

  1. Cloud Run is connected to the spoke network using the serverless connectors
  2. The traffic originating from the Cloud Run enters the spoke network through the serverless connector and moves to the destined path
  3. If the connection is destined to the internet or resources in other spoke project then the connection is inspected through the NGFW

The implementation of the above setup would require the following steps :-

  1. Access to a GCP Project
  2. VPC and Subnet planning and creation ( Untrust, Trust, Management, and Spoke VPC )
  3. VPC Peering between the trust VPC and the spoke VPC
  4. Creation of the Palo Alto VM Series connected with the untrust, trust and Management VPC ( This can be achieve using the GCP marketplace )
  5. Attaching the Palo Alto VM’s to umig ( unmanaged instance group )
  6. Creation of Global Load Balancer and attaching the palo alto umig as the backend service in the GLB
  7. Creation of Cloud Run in the spoke project with the internal load balancer
  8. Configuring the the Palo Alto for basic ingress and outbound connectivity
  9. Configuring the GLB with domain name / ssl for the specific application
  10. Configuring the Palo Alto NGFW to route the traffic to the Cloud Run

Authors

Ankit Awal

Bhavish Kumar

Mohammed Sahil

--

--