Secure Web Proxy Deployment and Policy Enforcement

Manage Proxy Operations, Logging, and Threat Intelligence Integration is the operational practice of keeping outbound web proxy traffic healthy, visible, and protected from malicious destinations. In Google Cloud, Secure Web Proxy (opens in a new tab) and related Envoy-based proxies depend on Cloud NAT, Cloud Logging, Cloud Monitoring, and Google Security Operations (opens in a new tab) to detect failures, record policy decisions, and block known threats. Traffic flows from clients to the proxies, from the proxies through Cloud NAT to the internet, while logs and metrics flow to monitoring and security analytics for detection and response.

1.1Monitoring Proxy Health and Policy Violations

Proxy health monitoring tracks whether the managed proxy infrastructure has enough network capacity to reach the internet. Traffic flows from clients to Envoy proxies running in a proxy-only subnet, then through a Cloud NAT gateway that maps the proxy-only subnet range to external IP addresses. The gateway depends on its NAT IP pool, so if fewer addresses are provisioned than the number of assigned Envoy proxies, requests can fail with HTTP 5xx errors.

Cloud Monitoring watches this dependency with the nat_allocation_failed gateway metric. An alert on that metric tells operators that NAT port exhaustion is dropping outbound traffic, which is distinct from a policy deny that intentionally blocks a domain. To use assigned addresses fully, the gateway is updated to enable dynamic port allocation, with a recommended minimum of 2048 ports and maximum of 4096 ports per VM. Operators choose the address strategy based on destination requirements:

Load balancer and proxy logs complement metrics by recording request outcomes, including rejected early-data requests with HTTP 425 Too Early. Together, metrics show capacity health while logs show which policy or protocol check allowed or denied each request.

1.2Logging Outbound Traffic and Exporting to SIEM

Proxy logging captures detailed records of every HTTP and HTTPS session processed by the web proxy, including user identity, application, URL category, and threat verdicts. For Netskope web transaction (WebTx) logs, data flows from the Netskope tenant to a Cloud Storage bucket as compressed .gzip files, then from the bucket to Google Security Operations through a Cloud Storage V2 feed. Google Security Operations then converts raw logs to Unified Data Model (UDM) events for detection and investigation.

The ingestion path depends on the bucket, identity, and feed being configured in order:

1. Bucket creation: A Cloud Storage bucket, such as netskope-webtx-logs, stores incoming log files with Standard storage class and Uniform access control.
2. Authenticated push: A Google Cloud service account with the Storage Object Creator role authenticates the push, using a JSON key pasted into Netskope Log Streaming.
3. Scheduled delivery: Netskope Log Streaming pushes WebTx files to the bucket at a fixed interval of 240 seconds.
4. SIEM ingestion: Google Security Operations reads the bucket through a Cloud Storage V2 feed and parses the files for analysis.

This model separates responsibilities across trust boundaries: Netskope owns log generation and delivery, Cloud Storage owns durable retention, and Google Security Operations owns parsing, detection, and response. Prerequisites for the flow are a Google Security Operations instance, a Google Cloud project with the Cloud Storage API enabled, permissions to create buckets and manage IAM policies, and administrator access to the Netskope tenant.

1.3Integrating Threat Intelligence for Dynamic Blocking

Threat intelligence integration lets the proxy dynamically block access to malicious domains and IPs instead of relying only on static URL lists. Google Threat Intelligence (GTI) provides current indicators that partner and Google security products consume through OEM integration or a Bring Your Own License (BYOL) pathway. When a feed identifies a malicious domain or address, proxy policy can deny the outbound session and the deny is recorded in logs for later hunting.

Mature operations extend this integration beyond a single feed into Google Security Operations and Security Command Center (SCC). The partner integration must meet related requirements that connect intelligence to enforcement and response:

• Ingestion feed or webhook integration: The product must provide a supported data feed through the ingestion API or webhook integrations, with raw logs converted to UDM events.
• UDM-only pre-parsed feeds: The partner must provide or be ready to provide a UDM feed for its most commonly used Google Security Operations feed type and own parser updates.
• Response integrations: The product must publish at least one response integration that connects to the partner product and takes action from detections.
• Playbooks: The solution must provide at least one starter playbook that uses a response integration for automated response.
• SCC findings exchange: Partner products must ingest SCC findings for unified posture and create findings in SCC for their own product findings.

In this design, threat intelligence flows into detection, detection flows into proxy enforcement and SIEM alerts, and enforcement results flow back into SCC and Google Security Operations as findings. The proxy depends on current intelligence for blocking, the SIEM depends on proxy and SCC logs for context, and playbooks close the loop by acting on behalf of the customer when a malicious destination is observed.

Architect Proxy Deployments for Security and Scalability is the design of a managed outbound path that isolates workloads from the internet while scaling egress capacity. Traffic flows from clients to Secure Web Proxy (opens in a new tab) Envoy proxies, from the proxies through a Cloud NAT (Network Address Translation) gateway, and then to the external destination, while policy and TLS inspection control what is allowed. This design separates internal workloads from direct internet access and lets Google Cloud scale the proxy layer without exposing internal addresses.

2.1Managed Proxy Traffic Path and Trust Boundaries

The managed proxy traffic path keeps private workloads behind two boundaries: the proxy termination point and the NAT translation point. Envoy proxies running in a Google Cloud-managed proxy-only subnet terminate connections from the client and create new connections toward the backend or internet destination, so the client never connects directly to the external endpoint. The Cloud NAT gateway then maps the proxy-only subnet range to external IP addresses, so the internet sees only NAT addresses and never sees internal subnet addresses. The deployment depends on a Cloud Router in the same Virtual Private Cloud (VPC) network and region, because the NAT configuration is attached to the router and scoped to the proxy-only subnet.

2.2Proxy-Only Subnet Foundation

A proxy-only subnet is a reserved subnet that provides IP addresses for Google Cloud to run Envoy proxies on behalf of the customer. The proxy-only subnet is used by all Envoy-based regional load balancers in the same region of the same VPC network, and there can be only one active proxy-only subnet for a given purpose, per region, per network. For regional architectures the subnet is created with purpose REGIONAL_MANAGED_PROXY and role ACTIVE, while cross-region and global patterns use GLOBAL_MANAGED_PROXY with role ACTIVE. Do not assign the load balancer forwarding rule IP address or backend instance IP addresses from the proxy-only subnet, because Google Cloud reserves that range for managed proxies and those addresses must come from a different subnet range.

2.3Cloud NAT Gateway Integration

A Cloud NAT gateway for managed proxies is a regional gateway that translates the proxy-only subnet to the internet for outbound flows. The gateway is configured with source endpoint type Managed proxy load balancers and a custom source limited to the proxy-only subnet name, which is expressed in gcloud as --endpoint-types=ENDPOINT_TYPE_MANAGED_PROXY_LB with --nat-custom-subnet-ip-ranges. Building the integration follows an explicit order:

1. Create the proxy-only subnet first in the target VPC network and region, so Envoy capacity has addresses to use.
2. Create the Cloud Router next in the same network and region, because the NAT configuration must attach to a router.
3. Create the Cloud NAT gateway then on that router with the managed-proxy endpoint type and the proxy-only subnet as the custom source.
4. Enable dynamic port allocation only after the gateway exists, so the assigned addresses are fully used under load.

The gateway can allocate addresses from Premium Tier or Standard Tier Network Service Tiers, and the choice controls the tier of the external NAT addresses used for outbound proxy traffic.

2.4Choosing Automatic Versus Manual NAT Address Allocation

NAT address allocation is the decision between operational simplicity and deterministic egress identity for allowlists. Cloud NAT supports automatic allocation based on demand and manual allocation from pre-reserved static external addresses, and the gateway performs one-to-one NAT translation so the pool must be large enough for expected proxy traffic.

If fewer manual NAT addresses are provisioned than the number of assigned Envoy proxies, requests to the internet destination can fail with HTTP 5xx errors and traffic can be lost. Because of that risk, manual pools must be sized to proxy scale, and the nat_allocation_failed gateway metric should have an alert so allocation failures are detected before they become sustained outages.

2.5Scaling, High Availability, and TLS Inspection

Scaling and fault tolerance for proxy egress depend on regional isolation, dynamic ports, and monitoring rather than a single large gateway. Cloud NAT with dynamic port allocation reuses the assigned IP addresses more efficiently by adjusting ports per proxy endpoint, with a recommended minimum of 2048 ports and maximum of 4096 ports set through --enable-dynamic-port-allocation. Deploying a proxy-only subnet, Cloud Router, and Cloud NAT gateway in each active region keeps failure and scaling domains regional, while Envoy proxies scale within the proxy-only subnet range without changing workload subnets. Monitoring nat_allocation_failed and contacting support for address sizing preserves availability when proxy count grows faster than NAT capacity.

A TLS inspection policy (Transport Layer Security inspection policy) adds the security control that lets Secure Web Proxy decrypt and inspect outbound web traffic against policy. The policy references a Certificate Authority Service (CA) pool in the same region, expressed as projects/PROJECT_ID/locations/REGION/caPools/CA_POOL, and supports a certificate issuance mode for how replacement certificates are created. Inspection depends on a Google-managed service account named service-[PROJECT_NUMBER]@gcp-sa-networksecurity.iam.gserviceaccount.com that is granted roles/privateca.certificateManager on the CA pool, so certificate generation does not use user credentials. Together, the regional proxy plus NAT path provides scalable egress and the TLS inspection policy provides content-level enforcement before traffic leaves the boundary.

Configure and Enforce Granular Access and Inspection Policies is the implementation of detailed allow, deny, and inspection rules for outbound web traffic. In Secure Web Proxy (opens in a new tab), the GatewaySecurityPolicy holds the rules that allow or deny traffic, and the Secure Web Proxy gateway instance attaches to that policy and inspects traffic routed to it. When the gateway uses NEXT_HOP_ROUTING_MODE, enforcement becomes transparent because VPC routes steer client traffic to the proxy without per-client proxy configuration.

3.1Policy Foundation and Inspection Attachment

The GatewaySecurityPolicy is the control point where granular access rules are defined and then enforced on every matching request. The workflow to establish enforcement depends on three ordered objects: the policy, the rules inside the policy, and the gateway that references the policy. Traffic flows from the workload to the gateway IP, the gateway evaluates the traffic against the attached GatewaySecurityPolicy, and only allowed HTTP(S) and TCP proxy traffic continues toward the internet destination.

1. Complete prerequisites: Prepare the network, subnetwork, certificate, and permissions required for the proxy deployment.
2. Create the Secure Web Proxy policy: Create the gatewaySecurityPolicies resource that will contain the access and inspection rules.
3. Create Secure Web Proxy rules: Add rules to the policy that define which traffic is allowed, denied, or inspected.

The gateway depends on both the policy and a certificate, because the certificate enables the gateway to terminate and inspect encrypted sessions while the policy decides the outcome.

3.2Next-Hop Gateway Deployment

A next-hop Secure Web Proxy gateway is a SECURE_WEB_GATEWAY resource deployed with routingMode: NEXT_HOP_ROUTING_MODE in a specific VPC network, subnetwork, and region. By default gateways use EXPLICIT_ROUTING_MODE, which requires each workload to explicitly send HTTP(S) traffic to the proxy, while NEXT_HOP_ROUTING_MODE lets VPC routes direct traffic to the proxy automatically. The gateway definition binds the network location to the inspection policy through fields for addresses, network, subnetwork, and gatewaySecurityPolicy, so routing and policy enforcement share one lifecycle.

The gateway listens on ports 80 and 443 by default, and it can optionally listen on all ports from 1 to 65535 with all_ports: true for dynamic environments that use many ports. The all_ports option applies only when type is SECURE_WEB_GATEWAY and routingMode is NEXT_HOP_ROUTING_MODE, and a gateway cannot combine all_ports: true with an explicit ports list. Global reach is controlled by allow_global_access, which permits clients from other Google Cloud regions to connect to the proxy, but this setting can be enabled only at creation time and cannot be added later.

3.3Directing Traffic with Static and Policy-Based Routes

Routes are the mechanism that forces outbound traffic through the next-hop Secure Web Proxy gateway for inspection. Both route types use the gateway IP as an internal load balancer next hop, with traffic flowing from the source VM to the SWP_IP address and then onward if the policy allows it. The choice between them depends on how traffic must be selected and what additional routing is required.

A static route is created with gcloud compute routes create using --next-hop-ilb=SWP_IP, --destination-range, --priority, and --tags. Use 0.0.0.0/0 as the destination range to send all internet traffic to the proxy, and set the priority numerically lower than the default internet route, which is typically 1000, because higher numbers denote lower priority. A policy-based route is created with gcloud network-connectivity policy-based-routes create using --next-hop-ilb-ip=SWP_IP, --source-range, --destination-range, and --priority, which enables filtering by source IP range that static routes do not support.

3.4Validation and Service Limits

Validation confirms that the next-hop path, priorities, and regional placement actually deliver traffic to the Secure Web Proxy gateway. The deployment depends on a default route to the internet gateway, correct network tags on static routes, appropriate route priorities, and same-region placement because Secure Web Proxy is a regional service. If any of these dependencies is missing, matching traffic will not reach the proxy or will bypass inspection.

Next-hop operation carries strict limits that shape granular policy design:

• Next-hop gateways support HTTP(S) and TCP proxy traffic only; other traffic, including cross-region traffic without global access, is dropped without notification.
• Internal passthrough Network Load Balancer next-hop limitations apply when next-hop-ilb points to a Secure Web Proxy instance.
• All VM traffic matched by the next-hop route, including background traffic and updates, is sent to the Secure Web Proxy instance.
• Only one Secure Web Proxy as next hop instance can be deployed per VPC network in a region.
• Within a given network and region, an all_ports: true next-hop gateway cannot coexist with another Secure Web Proxy instance in any other mode.

Key Facts

• Secure Web Proxy outbound traffic flows from clients to Envoy proxies in a proxy-only subnet, then through a Cloud NAT gateway to the internet, with the NAT configuration attached to a Cloud Router in the same VPC network and region.
• An alert on the Cloud Monitoring nat_allocation_failed metric detects NAT port exhaustion, and dynamic port allocation with 2048 minimum and 4096 maximum ports per VM helps use assigned NAT addresses fully.
• Netskope WebTx logs flow from the Netskope tenant to a Cloud Storage bucket every 240 seconds, then to Google Security Operations through a Cloud Storage V2 feed for conversion to Unified Data Model events.
• A Secure Web Proxy next-hop gateway uses NEXT_HOP_ROUTING_MODE with VPC routes pointing to the gateway IP as next-hop-ilb, while explicit mode requires per-workload proxy configuration.
• Only one Secure Web Proxy as next hop instance can exist per VPC network per region, and an all_ports: true gateway cannot coexist with another Secure Web Proxy instance in the same network and region.