Source URL: https://cloud.google.com/blog/products/networking/from-vpc-firewall-rules-to-cloud-ngfw-network-firewall-policies/
Source: Cloud Blog
Title: Elevate network security and migrate your legacy VPC firewall rules to Cloud NGFW
Feedly Summary: 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.
aside_block
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.
code_block
<ListValue: [StructValue([(‘code’, ‘gcloud beta compute firewall-rules migrate –source-network=$vpc –export-tag-mapping –tag-mapping-file=$file.json’), (‘language’, ”), (‘caption’, <wagtail.rich_text.RichText object at 0x3e54245cf430>)])]>
Here is an example output of the JSON file with the following format:
code_block
<ListValue: [StructValue([(‘code’, ‘{“networktag1": null, "networktag2": null, "networktag3": null, "networktag4": null, "networktag5": null, "networktag6": null, "networktag7": null, "networktag8": null, "sa:serviceaccount1.iam.gserviceaccount.com": null, "sa:serviceaccount2.gserviceaccount.com": null}’), (‘language’, ”), (‘caption’, <wagtail.rich_text.RichText object at 0x3e54245cfc10>)])]>
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.
code_block
<ListValue: [StructValue([(‘code’, ‘{"networktag1": "tagValues/281478364041843", "networktag2": "tagValues/281482792789759", "networktag3": "tagValues/281483765957244", "networktag4": "tagValues/281481907254071", "networktag5": "tagValues/281482152015869", "networktag6": "tagValues/281482761609158", "networktag7": "tagValues/281482620993032", "networktag8": "tagValues/281475492376131", "sa:serviceaccount1.iam.gserviceaccount.com": "tagValues/281479588083409", "sa:serviceaccount2.gserviceaccount.com": "tagValues/281478236400704"}’), (‘language’, ”), (‘caption’, <wagtail.rich_text.RichText object at 0x3e54245cf940>)])]>
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.
code_block
<ListValue: [StructValue([(‘code’, ‘gcloud beta compute firewall-rules migrate –source-network=$vpc –tag-mapping-file=$file.json –bind-tags-to-instances –force’), (‘language’, ”), (‘caption’, <wagtail.rich_text.RichText object at 0x3e54245cf490>)])]>
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
code_block
<ListValue: [StructValue([(‘code’, ‘gcloud beta compute firewall-rules migrate –source-network=$vpc –tag-mapping-file=$file.json –target-firewall-policy=$migrated-policy –force’), (‘language’, ”), (‘caption’, <wagtail.rich_text.RichText object at 0x3e54245cfca0>)])]>
or a Terraform script output
code_block
<ListValue: [StructValue([(‘code’, ‘gcloud beta compute firewall-rules migrate –source-network=$vpc –export-terraform-script –tag-mapping-file=$file.json –target-firewall-policy=$migrated-policy –terraform-script-output-file=$migration.tf –force’), (‘language’, ”), (‘caption’, <wagtail.rich_text.RichText object at 0x3e54245cfa00>)])]>
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:
Keep the existing enforcement order and disable the user defined VPC firewall rules.
Manually create a firewall policy rule to allow/inspect ingress traffic destined to the GKE service IP.
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-allgke-(.+)-(.+)-((master)|(vms)|(all)|(inkubelet)|(exkubelet)|(mcsd))k8s-fw-(l7-)?(.+)k8s-(.+)-((node)|(http)|(node-http))-hc(.+)-hck8s2-(.+)-(.+)-(.+)-(.+)(-fw)?k8s2-(.+)-l4-shared-hc-fwgke((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.
AI Summary and Description: Yes
Summary: The text discusses advancements in Google Cloud’s network security, focusing particularly on the new Next-Generation Firewall (NGFW) as a replacement for legacy systems. It emphasizes the new firewall’s advanced features and the migration process from older VPC firewall rules, highlighting the importance of system upgrades in enhancing network protection.
Detailed Description:
The text outlines the significant improvements Google Cloud has made to its network security capabilities through the launch of the Cloud Next-Generation Firewall (NGFW). This update is part of a larger trend to enhance security frameworks within cloud infrastructures, which is highly relevant for security and compliance professionals.
Key Points:
– **Next-Generation Firewall (NGFW) Launch**: Google Cloud introduced its NGFW which offers advanced functionalities including:
– Intrusion Detection and Prevention System (IDPS)
– TLS inspection
– Fully Qualified Domain Name (FQDN) and geo-location filtering
– Integration with Google’s threat intelligence for more effective firewall policies.
– **Migration Guidance**: With the introduction of Cloud NGFW Enterprise, Google urges clients to transition from outdated VPC firewall rules to the new, more efficient firewall policies. The advantages of adopting these new policies are presented as critical for improving network security.
– **Automated Migration Tool**: To facilitate the migration, Google Cloud has developed a tool that automates most of the transition process. The tool aids in:
– Scanning existing VPC firewall rules
– Generating equivalent firewall policies
– Adjusting rule priorities
– Producing Terraform scripts for easier integration into existing CI/CD workflows.
– **Complex Migration Changes**: The document details the need for planning in complex environments where VPC firewall rules are tied to network tags or service accounts. This includes:
– Identifying and mapping existing dependencies.
– Modifying the transition to accommodate secure tags which offer IAM controls, replacing traditional network tags used in VPC firewall rules.
– **Examples and Use Cases**: The migration process is demonstrated with both simple and intricate scenarios that typically occur within enterprises. The text highlights potential pitfalls and adjustments needed for a smooth transition.
– **GKE Considerations**: There are specific nuances regarding Google Kubernetes Engine (GKE) firewall rules that require additional steps to ensure a successful migration involving firewall policies.
The analysis of this text reveals valuable insights for security and compliance professionals, particularly in understanding the implications of migrating to modern firewall systems within cloud environments, including the critical role of automation in enhancing security protocols and overall infrastructure integrity.