Intertwined

Virtual private clouds (VPCs) have seen Google and other hyperscalers revolutionize network management in the cloud. Although the process of dynamically creating and managing networks in on-premises IT can be very time-consuming – despite new developments such as software-defined networking (SDN) – cloud providers now offer APIs that can be used to create network constructs such as VPCs in next to no time.

However, cloud networks are often managed by DevOps teams, and the level of knowledge in DevOps is not always such that all security concerns are diligently taken into account. Additionally, the field of network security is relatively wide and presupposes expertise in tasks such as creating VPCs and their subnets, routing, analyzing flow logs, setting up firewalls, and establishing threat detection. Such concerns prompted this look into key security aspects in the Google Cloud Platform (GCP).

Enhancing Security with Shared VPC

Shared VPC is an evolution of the virtual private cloud. Shared VPC allows you to connect resources from multiple projects to a common VPC network. You can easily create a VPC with any kind of misconfiguration you can imagine. The approach of Shared VPC is to delegate the tasks of creating and managing the VPCs to a dedicated team to offload the burden of network security from the application teams, letting them take care of their applications.

Figure 1 illustrates the use of Shared and simple VPCs. In the lower part of the image, you can see a VPC spanning two regions with one subnet per region. The VPC and the virtual machines (VMs) belong to the same project, and you can see a dedicated host project at the top of the image, where Shared VPC was configured and shared. Service projects A and B are allowed to use Shared VPC, which means the projects run the VMs themselves, and the interfaces of the VMs are docked to Shared VPC.

Figure 1: The Shared VPC architecture (top) compared with a classic VPC (bottom). © Google [1]

This approach offers greater security, but also means greater configuration overhead, starting with the initial setup, with a number of steps to be completed. For a start, Shared VPC Admin (compute.xpnAdmin) and Project IAM Administrator (resourcemanager.projectIamAdmin) authorizations are required at the organization level. These permissions are assigned by an organization administrator.

Once these permissions are in place, you can upgrade the corresponding project to a HubHost project by setting up Shared VPC. To do this, click VPC Network | Shared VPC | Set up Shared VPC menu on the GCP console. This starts a wizard, where you upgrade the project to a host project in the first step; then select whether you want to share all subnets of the VPCs or only dedicated individual subnets. In the third step, select the users you want to authorize for the subnets. Specifically, this means assigning the Network User role (compute.network.User). The projects in which these users or service accounts reside then become service projects through the sharing process.

Securing VPCs with Firewalls

Once you have created your VPCs, the next step is to take care of securing them. Firewall rules are an important part. Here, especially, Google has added massive value in the last few years, allowing for different types of firewalls:

• VPC firewall rules apply to a specific project and network.
• Firewall policies group multiple firewall rules to update them simultaneously. These rules end up in a policy object that you can apply in different ways: globally, regionally, or to organizational elements such as folders or projects.
• Cloud firewalls, which are relatively new, offer additional features such as stateful inspection, address groups, or rules at the level of fully qualified domain names (FQDNs).

Firewall rules can be combined, but you must know the process of resolving the rules: For network communication, you need to check whether you have a rule at the organization level. If this is the case, network traffic is either allowed or denied and is followed by a check at the folder level. If you find no rules there, the VPC firewall rules come into play, followed by the global rules. If global rules do not exist either, regional rules apply. Finally implicit rules apply, which state that outgoing traffic is allowed by default and all incoming traffic is prohibited.

When creating a VPC firewall rule, you need to set a few attributes, either in the Google Cloud Console in the Firewalls tab of the corresponding VPC under VPC Network | VPC Networks or under VPC Network | Firewall . Some input is required to create a rule (Figure 2):

• The firewall rule Name should be as descriptive as possible, and policies should be created by use case and not be too specific about individual ports or IP addresses.
• The Description field should describe the rule in more detail.
• If needed, you can enable firewall logging. Logs help you evaluate network traffic and are useful for troubleshooting. However, logging can incur additional expense.
• Specify the VPC to which the firewall rule applies in the Network drop-down list.
• Enter a number in Priority; the default is 1000 . Lower numbers are processed first.
• Use Actions on Match to determine whether network traffic is allowed or denied.

Figure 2: When creating a VPC firewall rule, Priority is set to 1000 by default. A new entry changes the order for processing the rule.

Now specify the Targets to which the firewall rule will apply. These can be either All instances in the network , specific machines with a tag, or specific service accounts. If you use tags, it is important to note that you cannot enforce them. Any user who can manage a machine can assign any tags to the VM. In contrast, service accounts can only be used by VMs that have appropriate authorization. Service accounts for VMs can only be changed while the machine is stopped. Accordingly, the second approach is more restrictive in terms of security.

If you previously set a rule for incoming network traffic, now is the time to configure the Source filters. These can be IPv4 or IPv6 address ranges, tags, or service accounts. The Destination Filter must be set for outbound traffic. In this case, you can only configure classless interdomain routing (CIDR) ranges. Finally, you need to configure the desired protocols and ports. You can set these up in a granular way or simply unlock all of them at once. After saving the rule, you are taken back to the Firewall Overview menu. You will now find a list of all the rules and be able to filter by rule and type.

Cloud Firewall Essentials and Standard

Google made a number of network security announcements at its fall 2022 in-house Google Next show – including new Cloud Firewall Essentials and Cloud Firewall Standard products. They include and supplement the previous VPC firewall rules.

Tag integration is one interesting additional feature. However, these tags are not the network tags I described previously (used with VPC firewall rules), but resource manager tags. These tags offer the advantage of being able to authorize by Identity and Access Management (IAM). For example, you can create a tag with the vm-function key and then create a list of possible values for the tag (e.g., database , app-client , or app-server ). You then assign authorizations to these tags. For example, database administrators could be assigned the Tag User role for the tag with the value database , thus allowing the admin in question to start a VM with the tag and allow database traffic.

By default, firewall rules are stateful, which means that if the connection is open in one direction, return network traffic is automatically allowed. At this point, finding out whether any network traffic is returned and whether it can be analyzed is of interest for troubleshooting and is generally possible in the case of the firewall logs.

Address groups are new and a big help if you have a number of hosts, IP addresses, or whole network ranges that you use multiple times. In this case, you will want to avoid, if at all possible, having to keep these elements up to date in every rule in case of a change. Address groups can be updated in a one-off process and referenced in firewall rules.

Some of the features mentioned here are not available in the Cloud Firewall Standard product, which could mean additional costs for your company. This is true, for example, of the Threat intelligence module, which lets you block traffic by category. The categories include such things as known malicious IP addresses and domains. Extended protection comes thanks to FQDN objects, which support dynamic updating of firewall rules, even if the underlying IP addresses have changed. Also possible now is location detection for firewall rules, which means you can manage network traffic by its country of origin. This feature was previously only supported by web application firewalls.