Virtual private clouds in the Google Cloud Platform allow even complex network infrastructures to be created quickly and easily. But as any IT manager will confirm, fast does not always mean right – and that is a problem in the cloud, especially when it comes to security. In this workshop, we will therefore show you which on-board tools ensure security. In the first part, we will explain the concept of shared VPCs and how you can secure virtual private clouds with firewalls.
With virtual private clouds (VPCs), Google and other hyperscalers have revolutionised network management (in the cloud). While it is still somewhat cumbersome to dynamically create and manage networks in local IT, despite new developments such as software-defined networking (SDN), cloud providers offer an API that allows network constructs such as VPCs to be created in no time at all.
However, it is not uncommon for the management of cloud networks to be in the hands of DevOps teams. And their level of knowledge is not always sufficient to ensure that all security concerns are properly addressed. In addition, the field of network security is relatively large and requires expertise in creating VPCs and their subnets, routing, firewalls, flow log analysis and threat detection. We therefore present these key security techniques in the Google Cloud Platform (GCP) below.
Greater security with shared VPCs
Shared VPCs are a further development of VPCs. The latter can be easily created by administrators – with all conceivable misconfigurations. The approach of shared VPCs is to delegate the creation and management of VPCs to a dedicated team. This relieves application teams of the burden of ‘network security’ and allows them to focus on their application.
Figure 1 illustrates the use of shared VPCs and simple VPCs. The lower part of the image shows a VPC that spans two regions. There is one subnet per region. The VPC and the virtual machines belong to one project, and at the top of the image you can see a dedicated host project. This is where the shared VPC is configured and released. Service projects A and B are permitted to use the shared VPC. This means that the projects operate the virtual machines themselves and the interfaces of the VMs are docked to the shared VPC.
Figure 1: The architecture of a shared VPC (top) compared to a classic VPC (bottom).
This approach offers greater security, but also increases the configuration effort. This begins with the initial setup, which involves a series of steps. First, the rights ‘Administrator for shared VPC’ (compute.xpnAdmin) and ‘Project IAM Administrator’ (resourcemanager.projectIamAdmin) are required at the organisational level. These permissions are assigned by an organisation administrator.
Once these permissions are in place, you can upgrade the corresponding project to a HubHost project by setting up a Shared VPC. To do this, click on ‘Setup Shared VPC’ in the ‘VPC Network / Shared VPC’ menu in the GCP console. This launches a wizard in which you first upgrade the project to a host project. You then select whether you want to share all subnets of the VPCs or only specific individual subnets. In the third step, you select the users you want to authorise for the subnets. Specifically, this means assigning the role ‘network user’ (compute.network.User). The projects in which these users or service accounts are located then become service projects through the sharing process.
Secure VPCs with firewalls
Once you have created your VPCs, you need to secure them. Firewall rules are an important component of this. Google has made massive upgrades in this area in recent years, resulting in different types of firewalls:
VPC firewall rules apply to a specific project and network.
Firewall policies group multiple firewall rules so that they can be updated simultaneously. These rules end up in a policy object that you can apply in different ways: globally, regionally, or to organisational elements such as folders.
Cloud firewalls are relatively new and offer additional features such as stateful inspection, address groups, or rules at the FQDN level.
Firewall rules can also be used in combination. The sequence in which these rules are resolved is important: First, network communication is checked to see if there is a rule at the organisational level. If this is the case, network traffic is either allowed or denied. This is followed by a check at the folder level. If there are no rules there, the VPC firewall rules come into effect. Next, the global rules come into play. If these do not exist either, the regional rules are applied. Finally, the implicit rules apply, which state that outgoing traffic is allowed by default and all incoming traffic is prohibited.
