How We Built a Solution That Improves Google Cloud Security by Leveraging Managed Instance Groups

By Jonathan Maresky, Cloud Product Marketing Manager

The three pillars of CloudGuard are “Security · Automated · Everywhere”.

We explain this in the CloudGuard pages in the Check Point website, in our marketing material and all through our presentations. This is also an easy way to remember our vision as well as the value to our customers.

This blog post is relevant to the “Automated” and “Everywhere” pillars:

Automated cloud security is important for a number of reasons. The cloud is a dynamic environment, with constant changes in demand for services, with instances scaling up and down (as well as in and out), IP addresses changing, cloud vendor services being added or updated regularly, customer services being added or updated in CI/CD cycles, new users, etc. The recent Buyer’s Guide to Cloud Network Security explains that “any cloud solution that does not enable high levels of automation will be impossible to support and will be abandoned by customers. Legacy security approaches that rely heavily on human intervention cannot scale to meet the volume, velocity and variety of today’s cybersecurity threats.”

Cloud security everywhere is important because customer deployments span multiple public and private clouds, and security is required everywhere – preferably in easy-to-use processes and tools that are consistent across these clouds and even across on-prem networks where relevant. According to the Buyer’s Guide, “leading cloud security solutions are cloud-native and deeply integrated into the cloud vendors’ offerings. Tight integration also contributes greatly to overall ease of use, allowing configurations and tasks to be carried out with the least number of clicks and minimal navigation through complex interfaces.”

An important part of the above is the need to constantly improve CloudGuard’s automation and ease-of-use. This is done by integrations with new cloud services as well as adding new functionality to CloudGuard to improve existing user experience and make life easier for cloud developers, architects and security engineers.

This blog post will briefly explain some significant enhancements to CloudGuard’s integration with new and existing Google Cloud features, in order to help customers improve their Google Cloud security architecture, operational efficiency and ease-of-use. These new enhancements are a significant improvement and will provide immediate benefit to Google Cloud customers.

And if you are using Google Cloud, I will explain how your Google Cloud security can benefit from this new functionality immediately.

What is a Google Cloud Managed Instance Group (MIG)?

Google Cloud enables users to create a collection of VM instances that can be managed as a single entity, called an instance group. Instance groups can be managed or unmanaged. Managed instance groups allow the use of automated services, including autoscaling, autohealing, regional (multiple zone) deployment, and automatic updating. A Google Cloud MIG has similar functionality to an ASG in AWS and a VMSS in Azure.

What are the important considerations and objectives for using MIGs with CloudGuard Network Security?

• Ensure CloudGuard supports dynamic MIG functionality (e.g autoscaling) for outbound (“egress”) traffic as well as East-West traffic, which moves laterally inside the Google Cloud deployment.
• Enable customers to deploy one MIG for inbound (“ingress”), outbound and East-West traffic, instead of requiring the use of more than one MIG.
• CloudGuard security gateways can automatically respond to health checks by the load balancer. This also allows CloudGuard security gateways to be used with internal as well as external load balancers. The health check confirms that the CloudGuard security gateway is functional and if not, the load balancer will not forward traffic to this specific instance. The security gateways start responding to health checks immediately after being automatically configured.
• Support symmetric hashing to avoid the need for source NAT in East-West.

These objectives are now all supported by CloudGuard. Some of these were made possible by Google Cloud improvements, some by CloudGuard improvements and some by a combination (in other words: a deeper integration).

This blog post will explain these four objectives in more detail and how these were achieved:

Dynamic MIG functionality for outbound and East-West traffic

In the previous CloudGuard integration, when sending outbound traffic via a set of security gateways, users need to configure a route for each of the gateways. This required the user to maintain a fixed number of gateways – a suboptimal solution, especially for when the user needed to change the number of gateways and needed to update the routing table.

The new integration supports the Google Cloud capability of adding an ILB as a next hop. The ILB can now redirect the packets to the targets of the load balancer, and then to the CloudGuard Network Security gateway instances in the MIG.

This allows the MIG to easily increase and decrease the number of members, and supports an auto-scaling solution for outbound/egress and East-West traffic protection.

One MIG for inbound, outbound and East-West traffic

This architecture was not possible until recently because Google Cloud did not support specifying a specific interface when setting a MIG as an ILB backend pool. Internal and external load balancers could keep only the external interfaces as backend pool. This may lead to asymmetrical routing.

Google recently added support for users to define to which interface to route traffic. This is achieved by using ILB in each VPC network to direct traffic to the CloudGuard security gateway interface associated with that network. Google also configures the backend VM instances with the ILB IP address.

Automatic response to health checks

How do internal and external load balancers know which instances are functioning properly in order to route traffic to them? They send regular health checks to all security gateways in their instance groups (each connection attempt is called a probe).

Because the source IP ranges for Google Cloud health checks are the same for internal and external load balancers, CloudGuard security gateways could not use the static route to answer these probes.

Because the internal load balancer is now able to store the internal interface of the instances in its backend pool, new CloudGuard functionality starting with software version R81.10 enables the security gateways to respond properly to these health checks. The responses to health checks are now automated without requiring any additional configuration by the user.

Of course, the security gateway will start to respond to the probe immediately only after being automatically configured.

What is Google Cloud Symmetric Hashing?

Google announced symmetric hashing a few weeks ago. Symmetric hashing is used by internal load balancers so that “when packets belong to the same flow, Google Cloud calculates the same hash. In other words, the hash doesn’t change when the source IP address:port is swapped with the destination IP address:port.”

Let’s see how this improves the automation and ease of use of Google Cloud traffic routing with CloudGuard.

The diagram below shows lateral traffic (East-West), where an instance communicates with another instance in a different VPC

With East-West traffic, it is good security practice to inspect the traffic to prevent threats from spreading laterally inside the cloud deployment. An instance in Spoke1 communicates to an instance in Spoke2, and the traffic is routed via a load balancer to a Check Point CloudGuard Network Security gateway inside a managed instance group (MIG) of CloudGuard gateways. The gateway inspects the traffic and after inspection, routes it to Spoke2 via the load balancer.

The same gateway needs to inspect the returning traffic from Spoke2 to Spoke1. If another gateway inspects this traffic, it will possibly block this traffic (because it is not aware of the original traffic sent from Spoke1 to Spoke2). Before the release of symmetric hashing, to ensure that the traffic returning from Spoke2 to Spoke1 is routed to the same gateway, this gateway needed to use source network address translation (SNAT) on the traffic: in other words, assign its own IP instead of the source IP from Spoke1. In this case, the load balancer would know to route the returning traffic to the same gateway which would then inspect the traffic and after inspection, perform the reverse source NAT and route the traffic back to Spoke1.

A disadvantage of this approach is that the use of SNAT means that Spoke2 is not aware of the true source of the traffic and thinks that the security gateway is the source. In certain situations, the application in Spoke2 needs the true source of the traffic for decision-making purposes, and this is often a significant limitation and source of frustration for cloud customers. SNAT also has a performance impact on the security gateway’s throughput.

Google Cloud’s new feature simplifies the process considerably by providing a hash function to the internal load balancer that, given the same source and destination, IP and ports, directs the traffic to the same CloudGuard security gateway instance each time. This eliminates the need for SNAT by the gateway, and Spoke2 will see the traffic’s source as Spoke1 and not the CloudGuard gateway. And of course, it is symmetric, so traffic returning from Spoke2 to Spoke1 will use the same security gateway.

Another benefit to customers is the improved performance of the security gateway.

As far as I know, Google Cloud is the first and only cloud vendor to allow East-West communication without the need for SNAT, and CloudGuard uses this feature as part of its MIG solution.

Check Point worked closely with the Google Cloud team while these new features were in preview and before official release. Now that the new features are launched (“General Availability”) we are excited to tell our customers and the world about the elegant new functionality and how it makes it easier to improve Google Cloud security with CloudGuard Network Security capabilities.

And now for some videos!

• Shay Levin, the indefatigable CloudMates Community Manager, uploaded this high-level video of the new functionality
• Dmitry Suschevsky from the cloud QA team made these great technical videos:

For any technical questions, please contact your Security Engineer or contact us.

These new capabilities are supported in the R81.10 software release (and later releases).

Existing Google Cloud customers can deploy a MIG

And another benefit that is related to Automation:

The new solution is available using Terraform and can be found in the CloudGuard Network Security GitHub repository.

For more detailed information about configuring the new MIG capabilities, please refer to the Administration Guide.