GCP – Elevate network security and migrate your legacy VPC firewall rules to Cloud NGFW

Over the past 18 months, Google Cloud has significantly enhanced its network security offerings, culminating in the launch of Cloud Next-Generation Firewall (NGFW), formerly Cloud Firewall Plus. This evolution reflects the platform’s expanded capabilities and our commitment to robust network protection. Cloud NGFW includes advanced capabilities such as an intrusion detection and prevention system (IDPS), TLS inspection, FQDN and geo-location filtering, and integrates with Google’s threat intelligence for firewall policy rules. 

With the general availability of Cloud NGFW Enterprise, Google Cloud customers are encouraged to transition from legacy VPC firewall rules to Cloud NGFW’s powerful and flexible firewall policies. In addition to the benefits we outlined in the earlier blog, Why you should migrate to network firewall policies from VPC firewall rules, you can now benefit from the enhanced network security controls included in Cloud NGFW Standard and Enterprise tiers by migrating to the new policy model. 

To help make this process easy and smooth-proof, we have developed a migration tool that automates most parts of this process. Let’s delve into the migration process and explore how to  upgrade your network security infrastructure to harness the full potential of Google Cloud NGFW.

Transitioning to firewall policies: a simple case

Imagine a straightforward migration scenario with VPC firewall rules that don’t involve network tags or service accounts. We’ll use this simplified use case to demonstrate the power of the automated migration tool in streamlining the transition to firewall policies.

The migration process starts by scanning the configured VPC firewall rules and generates an equivalent firewall policy with corresponding rules. In cases where duplicate priorities exist within the original VPC firewall rules, the tool automatically adjusts the rule priorities to help provide a seamless and conflict-free transition.

Once the firewall policy is created and carefully reviewed, it has to be attached to the VPC. Make sure logging is enabled to monitor rule hit counts. To ensure that the new policy takes precedence, the enforcement order is switched, prioritizing the firewall policy over legacy VPC firewall rules. Continued monitoring of hit counts reveals the gradual shift towards the new rules, with the legacy rules eventually receiving zero hits. At this point you should be able to disable the old rules, validate possible negative impacts, then delete the old legacy VPC firewall rules.

Once you’re satisfied with the new policy, you can use the migration tool to help you generate a corresponding Terraform script for this policy. 

This marks a crucial point where you can add the advanced NGFW features into this base policy object, including IDPS, TLS inspection, geo-restrictions, FQDN-based filtering, address groups, and Google-managed Threat Intelligence IP lists. You can first test the features by directly modifying the policy objects associated with your network. Once the tests complete successfully, you can then manually add these new parameters into the Terraform script you had for the base policy before you incorporate it into your production CI/CD pipeline. 

Transitioning to firewall policies: a complex case 

In the previous section, we discussed a relatively straightforward migration scenario with no dependencies. But most existing environments contain dependencies — VPC firewall rules that reference network tags and/or service accounts. Firewall policies do not support network tags, but do support secure tags, which provide IAM controls. Service accounts are supported in a firewall policy as targets for applying the rule, however can not be used to evaluate rules themselves. In the traditional VPC firewall rule, a service account can be used as a source filter for ingress traffic. Firewall policy requires a tag to be used as a source filter instead.

Because of this change, some pre-work is required for a successful migration. To start, you can use the migration to identify all of the network tags and/or service accounts that are referenced in the VPC firewall rules, and output a JSON file for tag-mapping.

Here is an example output of the JSON file with the following format:

Create the required secure tags for the list of network tags and/or service accounts listed in the mapping file. Edit the JSON file to map the network tags and the service accounts to the corresponding secure tags.

Here is an example of updating the mapping file with the tag values of newly created tags, which replace network tags and service accounts.

Once the mapping file has been manually updated with the tag values for all secure tags, you are now ready to use the migration tool to bind these tags to the relevant VMs. This process binds secure tags to the instances with the network tags and/or service accounts that match the secure tags from the tag mapping file. Note that if there are managed instance groups (MIGs) that contain network tags, you need to manually update them to use the updated secure tags.

Now you can reference the tag-mapping file to the migration tool to generate the migrated firewall policy with all the secure tags mapped. As described in the section about the simple use case, you have two options for how to proceed with the migration: automatic firewall policy creation

 or a Terraform script output

Once the firewall policy is created by your choice of deployment, carefully review it. Ensure that the network tags and/or service accounts from VPC firewall rules are appropriately replaced by the corresponding secure tag.

Then, when you’re ready, associate the VPC and ensure logging is enabled to monitor rule hit counts. To ensure the new policy takes precedence, switch the enforcement order, prioritizing the firewall policy over legacy VPC firewall rules. Continued monitoring of hit counts will reveal the gradual shift towards the new rules, with the legacy rules eventually receiving zero hits. At this point you can disable the VPC firewall rules, validate possible negative impacts, and eventually delete the VPC firewall rules.

Similarly to the simple use case, this marks a crucial point where you can leverage firewall policies’ enhanced capabilities and integrate advanced features like IDPS, TLS inspection, geo-restrictions, FQDN-based filtering, Network Threat Intelligence, and more.

Advanced migrations: GKE VPC firewall rules 

In most cases, the migration tool attempts to migrate the existing VPC firewall rules to new firewall policy rules, with one exception: for VPC firewall rules created by Google Kubernetes Engine, which it skips. GKE is unique in that it automatically creates VPC firewall rules when deploying a cluster, service, ingress, gateway, or HTTPRoutes.

That means that if your node pools use network tags, you’ll need to  manually ​​update the nodepool configuration to use the corresponding secure tag.

From there, continue to use the steps for the simple use case for a dependency-free migration, or for the complex case to migrate and create your firewall policies with network tags/service accounts.

After validating the firewall policy, associate the VPC to the policy. 

Then, because your firewall policy does not contain the GKE auto-generated rules, follow these three steps:

1. Keep the existing enforcement order and disable the user defined VPC firewall rules. 

2. Manually create a firewall policy rule to allow/inspect ingress traffic destined to the GKE service IP.

3. Disable the GKE auto-generated allow ingress VPC firewall rule for GKE service (source: 0.0.0.0/0 and destination: load balancer IP). 

Auto generated GKE VPC firewall rules that have been excluded have the following regular expressions (regex):

gke-(.+)-ipv6-all
gke-(.+)-(.+)-((master)|(vms)|(all)|(inkubelet)|(exkubelet)|(mcsd))
k8s-fw-(l7-)?(.+)
k8s-(.+)-((node)|(http)|(node-http))-hc
(.+)-hc
k8s2-(.+)-(.+)-(.+)-(.+)(-fw)?
k8s2-(.+)-l4-shared-hc-fw
gke((gw)|(mcg))1-l7-(.+)-(.+)

With the exception of the GKE service firewall rule, all GKE workloads will continue to function with VPC firewall rules. Your non-GKE workloads and GKE service traffic will be processed by the firewall policies rules.

Now hopefully you have got a good idea on how to proceed with your migration project to upgrade your VPC firewall rules to the new network firewall policies and leverage the advanced NGFW feature set. 

For more information on how to use the automated migration tool, check out the “VPC firewall rules migration tool demo” video and refer to the documentation site for further details.