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 third and final part, we describe how to protect serverless workloads, use Private Service Connect, and perform efficient monitoring and logging.
Protecting serverless workloads
In addition to virtual machines, serverless workloads (Cloud Functions, Cloud Run, or App Engine) also need access to a VPC from time to time. This often goes hand in hand with the desire to isolate all network traffic from the internet. The former can be achieved with ‘VPC Serverless Access’ and the latter requirement can be implemented for Cloud Functions and Cloud Run at least. To do this, you must first reserve a /28 subnet in the corresponding VPC.
Then, based on this, you deploy the ‘Serverless VPC Access Connector’. With its help, you can finally access VPC resources, managed Google resources such as Cloud SQL or Memory with private IP addresses, or local networks if hybrid connectivity is available. Once the Serverless VPC Access Connector is in place, you can tighten up security. This is because it is now possible to ensure that all incoming and outgoing network traffic can only run via the connector, thus preventing access via public IP addresses.
Use Private Service Connect
Another exciting development is Private Service Connect (PSC). In short, this involves creating an endpoint in a VPC that abstracts a service outside the VPC. Access is via internal IP addresses and is therefore easy to control. There are a number of use cases for this.
First, Private Service Connect for accessing Google APIs: This approach is similar to Private Google Access, but with the difference that all network traffic in the VPC is private and no route to the Internet gateway needs to be configured to access Google APIs. Accordingly, you create a ‘Private Service Connect Endpoint’ for the Google API bundles described above. In addition, you store meaningful names for the individual services in the DNS, such as ‘storage-vialink1.p.googleapis.com’.
PSC endpoints go one step further with HTTP(S) user service controls. In this configuration, an HTTP(S) load balancer is also created. For this, you can granularly control which URLs are to be mapped and how they are to be published. In addition, you can import your own certificates to access Google Services and make local services available via the load balancer.
The third option is to use PSC endpoints to provide your own services or make them available for others to use. This is also possible across VPCs, projects, regions and organisations. Technically, this works in the same way as the other variants, with network address translation (NAT) taking place in the background. On the provider side (Producer VPC), you create an HTTPS(S) load balancer including the backend and publish it using a service attachment. The consumer can now use this service.
Monitoring and logging
Network security also includes monitoring, for which Google provides a range of on-board tools. At this point, we will take a closer look at ‘VPC Flow Logs’ and ‘Firewall Logs’. VPC Flow Logs record a sample of network data generated by virtual machines. This information is helpful for network monitoring, forensics, real-time security analysis and cost optimisation.
You must enable VPC Flow Logs for each subnet in a VPC. VPC Flow Logs records always include a number of attributes:
- Information about the IP connection, such as the protocol used, the source IP address, the destination IP address, and the source and destination ports.
- Information about the virtual machine (instance details).
- Data about the VPC (VpcDetails)
Depending on the service used, there are additional fields – in the case of GKE for the cluster, the service, and the pod. Since VPC Flow Logs generate a lot of data on a case-by-case basis, there is the option of filtering – you can even use expressions. The following example limits log collection to a VM named ‘my-vm’ where either the destination or the source is ‘my
gcloud compute networks subnets update my-subnet \
–logging-filter-expr=“(src_instance.vm_name == ‚my-vm‘ && reporter==’SRC‘) || (dest_instance.vm_name == ‚my-vm‘ && reporter==’DEST‘)“
The analysis is then performed in Cloud Logging. The firewall logs are useful for troubleshooting. For example, you can determine whether a firewall rule that is supposed to reject traffic is working as intended or which connections are affected by a firewall rule. Similar to VPC flow logs, you must first enable the firewall logs. This can be done for all firewalls in a VPC or for individual firewall rules. Once this is done, you have access to the generated log data in Cloud Logging. For example, you can use the following query to display the firewall logs for a VM on your screen:
resource.type=“gce_subnetwork“
logName=“projects/PROJECT_ID/logs/ compute.googleapis.com%2Ffirewall“
jsonPayload.instance.vm_name=“INSTANCE_ID“
Conclusion
Network security is a top priority in Google Cloud. We took a detailed look at the use of VPCs and showed how you can use the appropriate on-board tools to create security in your cloud environment. For example, VMs can access the Internet without any worries, while the administrator has parallel access to important monitoring data that is valuable not only in terms of security.
