Intertwined

Deploying Private Service Connect

Private Service Connect (PSC) is another exciting advancement with a number of possible use cases. In short, this product creates an endpoint in a VPC that abstracts a service outside the VPC. Access is by internal IP addresses and is therefore easily controlled.

The first use case is for access to Google APIs. This approach is similar to Private Google Access, but it differs in that all network traffic in the VPC is private, and you do not need to configure a route to the Internet gateway to access Google APIs. You would create a PSC endpoint for the Google API bundles described earlier. It is also a good idea to create mnemonic names for the individual services in the DNS (e.g., storage-vialink1.p.googleapis.com ).

PSC endpoints take this one step further with HTTP(S) user service controls. An HTTP(S) load balancer is also created in the process. You can control granularly which URLs you want to assign to the balancer and how they will be published. Additionally, 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 consumable by others – which is also possible across VPCs, projects, regions, and organizations. Technically, this method works like the other variants with NAT, which is set up in the background during the process. On the provider side (Producer VPC), you create an HTTP(S) load balancer, including a back end, and publish it with a service attachment. Consumers can then use this service.

Monitoring and Logging

Network security also involves monitoring, for which Google provides a number of on-board tools. At this point, I'll look at VPC Flow Logs and Firewall Logs, in particular. VPC Flow Logs record a sample of the network data generated by VMs. This information is useful in network monitoring, forensics, real-time security analysis, and cost optimization.

You need to enable VPC Flow Logs for each subnet in a VPC. The set of attributes every VPC Flow Log records include:

• Information relating to the IP connection, such as the protocol, the source IP address, the target IP address, and the source and target ports
• Information relating to the VM (instance details)
• VPC data (VpcDetails field format)

Depending on the service used, additional fields are available (e.g., in the case of GKE for the cluster, the Service and the Pod). Because VPC Flow Logs generates a high volume of data from case to case, you can filter and even use expressions. The following example restricts log collection to a VM named my-vm for which either the target or the source is my-vm :

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')"

Cloud Logging is then used for the analysis.

The Firewall Logs are of interest for troubleshooting. For example, you can determine whether a firewall rule that is intended to deny traffic is doing its job or determine which connections are affected by a firewall rule. Like VPC Flow Logs, you need to enable Firewall Logs first, either for all firewalls in a VPC or for individual firewall rules.

Once done, you can access the generated log data in Cloud Logging. For example, the query

resource.type="gce_subnetwork"
logName="projects/PROJECT_ID/logs/compute.googleapis.com%2Ffirewall"
jsonPayload.instance.vm_name="INSTANCE_ID"

displays the Firewall Logs for a VM onscreen.

Conclusions

Network security should be one of your top priorities on the Google Cloud Platform. In this article, I took an in-depth look at how to use VPCs and how to secure your cloud environment with the appropriate on-boarding tools.