Secure Web Proxy policies overview
Stay organized with collections Save and categorize content based on your preferences.

This page describes the source attributes and destination attributes for Secure Web Proxy policies. In addition, this page explains Transmission Control Protocol (TCP) rule-based proxying and how to configure TCP proxy rules for your application.

Secure Web Proxy policies are based on the following two parameters:

Traffic source: to identify the traffic source, Secure Web Proxy uses attributes such as service accounts, secure tags, and IP addresses.
Allowed destination: to determine the allowed destinations, Secure Web Proxy uses a destination domain, a full URL path (if TLS inspection is enabled), URL lists, or the destination port.

By default, Secure Web Proxy is set in a manner to deny any outbound web traffic (HTTP or HTTPS) through the proxy unless you include a specific rule in the policy of your Secure Web Proxy instance.

Source attributes for policies

Use the following attributes to let your Secure Web Proxy instance identify the source of the traffic:

Service accounts: use service accounts to identify the traffic source and configure Secure Web Proxy policies.
Secure tags: use Resource Manager tags to control the access to your Google Cloud resources.
IP addresses: assign your enterprise IP addresses (or static Google Cloud IP addresses) that Secure Web Proxy uses for outbound traffic.

Supported identities

You can use source identity-based security policies (service accounts and secure tags) to secure web traffic for several Google Cloud services. The following table shows whether various Google Cloud services are supported when using source identity-based security policies.

Google Cloud services	Service account support	Secure tag support
VM
GKE node
GKE container	¹	¹
Direct VPC for Cloud Run		¹
Serverless VPC Access connector	²	²
Cloud VPN	¹	¹
Cloud Interconnect on premises	¹	¹
Application Load Balancer
Network Load Balancer

¹ Not supported by Google Cloud.
² Source IP address is unique and can be used instead.

The following table shows whether various Virtual Private Cloud (VPC) architectures are supported when using source identity-based security policies:

VPC	VPC architecture	Support
Within VPC	Cross project (Shared VPC)
Within VPC	Cross region
Cross VPC	Cross peering link (peer VPC)
Cross VPC	Cross Private Service Connect
Cross VPC	Cross Network Connectivity Center spokes

Destination attributes for policies

With Secure Web Proxy, you can configure policies for your application based on destination domains and full URL paths (if TLS inspection is enabled).

Use the following attributes to let your Secure Web Proxy instance determine the allowed traffic destination:

Destination port: upstream port to which your Secure Web Proxy instance sends traffic. For more information, see Attributes available to SessionMatcher and ApplicationMatcher.
URL lists: use URL lists to define URLs that your users can access. For more information, see URL lists.

For HTTP-based destination traffic, you can use the host() destination attribute for your application.

And for HTTPS-based destination traffic, you can use various request.* destination-related attributes (such as request.method) for your application.

For more information about the destination attributes that you can use for HTTP and HTTPS traffic, see Attributes.

TCP proxy rules

With your Secure Web Proxy instance, you can configure proxy rules for Transmission Control Protocol (TCP) traffic, including traffic that is not associated with web protocols. For example, you can choose to either allow or block the traffic of websites or applications that send traffic from any ports other than 80 (HTTP) or 443 (HTTPS).

If your workload (such as your applications and services) uses Secure Web Proxy as next hop, then applying TCP proxy rules is beneficial. This is because using a route-based redirection process points non-HTTP(S) and non-web traffic to your Secure Web Proxy instance. By doing so, you can block malicious traffic from reaching your application and control which applications or websites can access your network.

Configure TCP proxy rules for your application

To implement TCP proxy rules and create an allow or block traffic rule for your application, you must specify the destination port. Optionally, you can include any of the following SessionMatcher attributes to refine the criteria of the allow or block rule.

Attribute	Attribute type	Description
`source.ip`	string	IP address of the client that sent the request.
`source.port`	string	Client port that sent the request.
`destination.port`	string	Upstream port to which your Secure Web Proxy instance sends the traffic.
`source.matchTag(SECURE_TAG)`	boolean	`True`, if the source is associated with `SECURE_TAG`. The argument is the permanent ID of the secure tag, such as `source.matchTag('tagValues/123456')`.
`source.matchServiceAccount(SERVICE_ACCOUNT)`	boolean	`True`, if the source is associated with `SERVICE_ACCOUNT`, such as `source.matchServiceAccount('x@my-project.iam.gserviceaccount.com')`.
`inIpRange(IP_ADDRESS, IP_RANGE)`	boolean	`True`, if `IP_ADDRESS` is contained within the `IP_RANGE`, such as `inIpRange(source.ip, '1.2.3.0/24')`. Subnet masks for IPv6 addresses can't be larger than `/64`.

Limitations

Secure Web Proxy doesn't support the ability to configure TCP proxy rules for User Datagram Protocol (UDP) applications. As a result, Secure Web Proxy blocks the traffic of UDP-based applications.

Host matching rules

When configuring egress rules for your Secure Web Proxy instance, make sure to define the rules depending on the destination host of outbound requests. You should also consider how host matching works based on the deployment mode of your Secure Web Proxy instance.

Explicit proxy mode

For unencrypted HTTP requests, you can use the host() == "myownpersonaldomain.com" rule in the SessionMatcher. Secure Web Proxy validates this rule against the host field in the CONNECT header of the HTTP request.
If you want to enable TLS inspection and set rules based on the Application Matcher, then you must set a SessionMatcher rule that evaluates to TRUE. For example, you can use the host() == "myownpersonaldomain.com" rule in the SessionMatcher, and then add the request.host() == "myownpersonaldomain.com" rule in the ApplicationMatcher.

Secure Web Proxy first validates the SessionMatcher against the host field in the CONNECT header of the HTTP request. And only if the SessionMatcher rule is valid, Secure Web Proxy then examines the ApplicationMatcher rules.

Important: You can also use other ApplicationMatcher attributes as required.

Next hop mode

For unencrypted HTTP requests, you can use the host() == "myownpersonaldomain.com" rule in the SessionMatcher. Secure Web Proxy validates this rule against the host field in the standard HTTP request header.

However, if the request is TLS-encrypted, then Secure Web Proxy validates the same rule against the Server Name Indication (SNI) header in the outbound request.
If you want to enable TLS inspection and set rules based on the ApplicationMatcher, then you must set a SessionMatcher rule that evaluates to TRUE. For example, you can use the host() == "myownpersonaldomain.com" rule in the SessionMatcher, and then add the request.host() == "myownpersonaldomain.com" rule in the ApplicationMatcher.

Secure Web Proxy first validates the SessionMatcher against the SNI header in the outbound request. And only if the SessionMatcher rule is valid, Secure Web Proxy then examines the ApplicationMatcher rules.

Important: You can also use other ApplicationMatcher attributes as required.