Improve network security by switching to Cloud NGFW from your outdated VPC firewall rules.
Cloud Next-Generation Firewall (NGFW), formerly known as Cloud Firewall Plus, is the result of Google Cloud’s extensive network security services over the last 18 months. The platform’s increased capabilities and its dedication to strong network security are reflected in this progression. Advanced features including FQDN and geolocation filtering, TLS inspection, intrusion detection and prevention system (IDPS), and integration with Google’s threat intelligence for firewall policy rules are all included in Cloud NGFW.
Google Cloud users are advised to switch from outdated VPC firewall rules to Cloud NGFW’s robust and adaptable firewall policies now that Cloud NGFW Enterprise is generally available. By switching to the new policy paradigm, you can now make use of the improved network security controls offered by Cloud NGFW Standard and Enterprise tiers.
Google Cloud has created a migration tool that automates the majority of this procedure to assist make it simple and error-proof. To fully utilize Google Cloud NGFW, let’s examine how to improve your network security infrastructure and dive into the migration process.
A straightforward example of switching to firewall policies
Consider a simple VPC firewall rule-based migration scenario without network tags or service accounts. This streamlined use case will be used to illustrate how effective the automatic migration tool is in expediting the switch to firewall policies.
In order to create an analogous firewall policy with matching rules, the migration method first scans the configured VPC firewall rules. The utility automatically modifies the rule priorities to facilitate a smooth and conflict-free transition in situations when the original VPC firewall rules have duplicate priorities.
The firewall policy must be connected to the VPC after it has been developed and thoroughly examined. Verify that logging is turned on in order to track the number of rule hits. The enforcement order is changed to prioritize the firewall policy over the old VPC firewall rules, guaranteeing that the new policy takes precedence. The legacy rules finally receive zero hits as a result of the slow transition towards the new rules, as seen by ongoing hit count monitoring. You should now be able to disable the outdated rules, confirm any potential adverse effects, and then remove the outdated legacy VPC firewall rules.
After you’re happy with the new policy, you can create a Terraform script for it with the help of the migration tool.
The sophisticated NGFW features, including as IDPS, TLS inspection, geo-restrictions, FQDN-based filtering, address groups, and Google-managed Threat Intelligence IP lists, can now be added to this base policy object at this critical juncture. By directly altering the policy objects connected to your network, you can initially test the functionality. Before integrating it into your production CI/CD pipeline, you can manually add these additional parameters to the Terraform script you had for the base policy when the tests are finished successfully.
Making the switch to firewall policies: a challenging situation
It covered a quite simple, dependency-free migration case in the previous section. However, dependencies on VPC firewall rules that make use of network tags and/or service accounts are present in the majority of current settings. While network tags are not supported by firewall regulations, secure tags that offer IAM controls are. A firewall policy can support service accounts as targets for rule application, but they cannot be used to assess rules directly. A service account can be used as a source filter for incoming traffic in the conventional VPC firewall rule. Instead, a tag must be utilized as a source filter under firewall rules.
A successful migration now requires some pre-work due to this modification. The migration can be used to first determine which network tags and/or service accounts are mentioned in the VPC firewall rules. It can also provide a JSON file for tag mapping.
gcloud beta compute firewall-rules migrate –source-network=$vpc –export-tag-mapping –tag-mapping-file=$file.json
This is a sample JSON file output in the format shown below:
{“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}
For the network tags and/or service accounts specified in the mapping file, create the necessary secure tags. To map the network tags and service accounts to the appropriate secure tags, edit the JSON file.
This is an illustration of how to update the mapping file with the newly formed tag values, which take the place of service accounts and network tags.
{“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”}
You can now use the migration tool to tie these tags to the appropriate virtual machines (VMs) after manually updating the mapping file with the tag values for each secure tag. Using the network tags and/or service accounts that correspond to the secure tags from the tag mapping file, this procedure attaches secure tags to the instances. Keep in mind that in order to use the updated secure tags, you will need to manually update any managed instance groups (MIGs) that use network tags.
gcloud beta compute firewall-rules migrate –source-network=$vpc –tag-mapping-file=$file.json –bind-tags-to-instances –force
To create the migrated firewall policy with all the secure tags mapped, you may now refer to the tag-mapping file in the migration tool. You can move forward with the migration in one of two ways, as explained in the section on the simple use case: generation of firewall policies automatically
gcloud beta compute firewall-rules migrate –source-network=$vpc –tag-mapping-file=$file.json –target-firewall-policy=$migrated-policy –force
or an output from a Terraform script
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
Examine the firewall policy carefully after it has been built using the deployment method of your choosing. Ensure that the network tags and/or service accounts from the VPC firewall rules are replaced with the appropriate secure tag.
When you’re prepared, attach the VPC and make sure that logging is turned on so that rule hit counts may be tracked. Change the enforcement order to give the firewall policy priority over the old VPC firewall rules in order to guarantee that the new policy takes precedence. The old rules will eventually receive zero hits as a result of the slow transition towards the new rules, which will be shown by ongoing hit count monitoring. You can now disable the VPC firewall rules, check for any potential negative effects, and then remove them altogether.
This is a critical stage, similar to the simple use case, when you can integrate sophisticated features like IDPS, TLS inspection, geo-restrictions, FQDN-based filtering, Network Threat Intelligence, and more, and take advantage of firewall policies’ improved capabilities.
Advanced migrations: firewall rules for GKE VPC
With the exception of VPC firewall rules generated by Google Kubernetes Engine, which it bypasses, the migration tool typically aims to move the current VPC firewall rules to the new firewall policy rules. When deploying a cluster, service, ingress, gateway, or HTTPRoutes, GKE is special because it automatically generates VPC firewall rules.
This implies that you will have to manually modify the nodepool settings to utilize the appropriate secure tag if your node pools employ network tags.
After that, follow the instructions for either the difficult use case, which involves creating your firewall policies using network tags and service accounts, or the basic use case, which involves a migration without dependencies.
Connect the VPC to the firewall policy after it has been validated.
Then, since the GKE auto-generated rules are not included in your firewall policy, take the following three actions:
- Disable the user-defined VPC firewall rules and maintain the current enforcement order.
- Create a firewall policy rule by hand to permit or examine incoming traffic going to the GKE service IP.
- The GKE service’s allow ingress VPC firewall rule (source: 0.0.0.0/0 and destination: load balancer IP) should be disabled.
The following regular expressions (regex) are found in the auto-generated GKE VPC firewall rules that have been excluded:
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-(.+)-(.+)
Except for the GKE service firewall rule, all GKE workloads will continue to run under VPC firewall rules. The firewall policy rules will handle both GKE service traffic and your non-GKE workloads.
Hopefully, you now have a clear understanding of how to move on with your migration project in order to take use of the sophisticated NGFW feature set and upgrade your new network firewall regulations to the VPC firewall rules.
