Application workload traffic management and the way it needs to be controlled so that it talks to the right destination in a secure way is increasing predominantly. This is precisely in short where Google Cloud wants enterprises to do it securely and without having to manage or maintain their own proxy. The out-of-the-box solution that Google offers in a native way is “Cloud Secure Web Proxy”
In this document we discuss what this solution offers and how it can be a best fit where organizations are looking for native forward proxy which has built-in secure features for enterprises.
There are two parts of this series and the PART -1 which we are going through provides us with below :
In the PART-2 ( will be published in some time) you will see the details related to:
This document aims to provide an overview of GCP’s native proxy offering for the enterprise customers who are looking at securing their applications, workloads related to its egress traffic.
It is easy to configure and maintain, also it is a simple, scalable cloud-native web proxy for cloud workload protection.
Secure web proxy is one of the recent additions to the network security space, It is a scalable solution, provides control points for egress traffic. Also the web filtering capabilities helps secure the traffic and ensure any API calls that the workloads are making are hitting the intended destination. With cloud secure web proxy you have the flexibility to design policies aligned to your cloud environment which simplifies your setup and management of web egress.
In this document we will see how the secure web proxy helps determine customers who want to deeply secure their egress traffic. The solution here is the cloud-native which is easy to configure and maintain and also that delivers a world class access control mechanism, it provides protection in a high performance, scale SaaS model without configurability requirements.
However in recent times In general we have seen normal secure web proxies that are more tailored towards user traffic and are more inclined in terms of manageability, operational overhead and other challenging factors. The secure web proxy comes in-place where organizations consider to secure and migrate workloads alongside its protection layer(webproxy) onto the cloud. The only difference is now we have this capability as a cloud native way. And this will not intend to launch / use the VM's to host the old way of using cloud web gateway.
Cloud Secure Web Proxy’s policy construction uses objects with a cloud context like secure tags or service accounts, moreover cloud secure web proxy also supports TLS inspection that lets you inspect the encrypted web traffic and enforce security policies down to the full URL and destination path.
Granular policies help control and secure workloads; it also involves providing ways like using service accounts, secure tags and IP's. Also on the destination traffic it looks for FQDN, IP's and with TLS inspection it can inspect the full url path and helps provide a very granular way of settings rules for what traffic is allowed and blocked from egressing
Tracking egress traffic is one of the key requirement to get a complete view of the traffic flow and this will help log incidents based on the details it is logging, also it is useful for capturing forensics information which is tracked.
Driving factor for cloud migration
Egress Control
Incident Forensics
Cloud secure proxy is a regional service and is specifically built for web traffic (http/s).Provides deeper web inspection, policy and protection. Primary focus being internet perimeter protection.
It is a explicit proxy - From source of the account you will need to point this traffic to the secure web proxy and this is easily done in most cases by setting OS level environment variable <HTTP proxy = {full url of the secure web proxy}
By default it has automatic cloud NAT integration and it requires public IP that lets you customize network address translation for resources in your cloud environment making outbound connections. It can co-exist to function with the existing connectivity path from workload to cloud secure web proxy. Also it lets you customize network address translation for resources in your cloud environment making outbound connections over:
GCP will provide the public IP for the cloud secure web proxy (cloud nat) however organizations can possibly use / overwrite it with their own IP space they want to.
Cloud secure web proxy works out of the box for the majority of use cases with no vms to set up, no software updates to make manually and scales with your workloads and traffic saving time in both setup and day to day operations.
These are some of the most commonly adapted use cases typically any enterprise might onboard a cloud web proxy to secure the egress traffic. However this solution can also be used for different other aspects of securing the egress workloads
Use Cloud secure web proxy as an egress proxy for cloud workload protection that enables monitoring and granular policy control of egress web(http/s) for internet destinations. Works with shared VPC, VPC peering and through multi-NIC VMs.
Use cloud secure web proxy to provide access to any destination from on-prem. This is useful for customers who don't want to manage their own egress proxy and want to have a central fully managed egress proxy with filtering capabilities.
The above solution depicts a multi-region, typical hub and spoke model where traffic is segregated across the type of workload(Prod / nonprod) across different regions and also segregating proxy usage for different environments.
In this article we reviewed the cloud secure web proxy offering and it's various use cases for integrating with enterprise security requirements for outbound traffic from application workloads.
In the next set of series of this article we'll see how this can be implemented and protect outbound workload traffic using secure tags, identity (service account) based controls and TLS inspection.
CWP seems like a valuable and comprehensive solution for organizations seeking to secure their application workloads' outbound traffic. The breakdown of its features, including granular policy control, traffic monitoring, and TLS inspection, is insightful.
Here are some questions that might be helpful for future readers:
Overall, this blog post effectively introduces CWP's core functionalities and use cases. I look forward to Part 2 for a deeper dive into implementation and configuration!
Best regards,
FESCO Online Bill (assuming this is your website)