This page describes how to set up authorization policies for Secure Web Proxy.
Before you begin
Review the Secure Web Proxy overview and Authorization policy overview pages.
-
- Network Security API
- Network Services API
- Certificate Manager API
Make sure that you have the appropriate roles and permissions.
You must have an active Secure Web Proxy instance deployed and associated with a
GatewaySecurityPolicy. For more information, see Deploy a Secure Web Proxy instance.To configure Secure Web Proxy authorization policies, you must enable a TLS inspection policy.
Create an authorization policy
This section explains how to create different types of authorization policies that are attached to a Secure Web Proxy instance.
To create an authorization policy for Secure Web Proxy, do the following:
- Configure a YAML file that defines the target and rules.
- Import the file by using the
gcloud network-security authz-policies importcommand.
Authorization policy based on mTLS identity
Secure Web Proxy supports enforcing security rules based on identities derived from mutual TLS (mTLS) certificates. Enforcing rules based on these identities is particularly useful in zero-trust environments, where the traffic between clients and the proxy is secured by mTLS. For more information, see Authorization policy based on principals.
The following example shows an authorization policy for a
Secure Web Proxy instance named swp1. This example assumes that the
traffic to the proxy uses HTTPS protocol.
The policy with the REQUEST_AUTHZ profile enforces that all traffic to
example.com/mcp requires mTLS authentication from a
specific principal before the traffic is allowed to pass through. The policy
also denies all outbound traffic that isn't intended to go to
example.com/mcp.
Create the authorization policy YAML file.
The following example creates an
authz-policy.yamlfile. The policy allows traffic to the specified host and path only if the client presents a certificate that matches the definedSPIFFE IDprincipal.$ cat >authz-policy.yaml <<EOF name: test-authz-policy-mtls target: resources: - "projects/ PROJECT_ID /locations/ LOCATION /gateways/swp1" policyProfile: REQUEST_AUTHZ httpRules: - to: operations: - hosts: - exact: "example.com" paths: - exact: "/mcp" from: sources: - principals: - principalSelector: CLIENT_CERT_URI_SAN principal: exact: "spiffe:// PROJECT_ID .global.123.workload.id.goog/ns/ns1/sa/hellomcp" action: ALLOW EOFReplace the following:
PROJECT_ID: ID of your Google Cloud projectLOCATION: region of your Secure Web Proxy instance
Create an authorization policy and import the YAML file by using the
gcloud network-security authz-policies importcommand.gcloud beta network-security authz-policies import my-authz-policy-allow --source=authz-policy.yaml --location= LOCATIONReplace
LOCATIONwith the region of your Secure Web Proxy instance.
Authorization policy based on service accounts or tags
You can apply an authorization policy based on service accounts or tags attached to various Google Cloud resources.
This example assumes that you have completed the following:
Created a service account and attached it to a Google Cloud resource.
Created a tag and attached it to a Google Cloud resource as a key-value pair. When you create a tag, set its
--purposeflag toGCE_FIREWALL. Authorization policies require theGCE_FIREWALLpurpose to apply the tag.
Service account
Create an authorization policy YAML file to allow certain requests.
The following example creates an
authz-policy.yamlfile for the Secure Web Proxy instance namedswp1. The policy is configured to allow requests from a Compute Engine virtual machine (VM) instance with the service accountmy-sa-123@56788.iam.gserviceaccount.comto reach the example1.com/url1 path.$ cat >authz-policy.yaml <<EOF name: my-authz-policy-allow target: resources: - "projects/PROJECT_ID/locations/ LOCATION /gateways/swp1" policyProfile: REQUEST_AUTHZ httpRules: - from: sources: - resources: - iamServiceAccount: exact: "my-sa-123@56788.iam.gserviceaccount.com" to: operations: - hosts: - exact: "example1.com" paths: - prefix: "/url1" action: ALLOW EOFReplace the following:
PROJECT_ID: ID of your Google Cloud projectLOCATION: region of your Secure Web Proxy instance
Create an authorization policy and import the YAML file by using the
gcloud network-security authz-policies importcommand.The following example command shows how to import the previously created policy file and create an authorization policy:
gcloud network-security authz-policies import my-authz-policy-allow --source=authz-policy.yaml --location= LOCATIONReplace
LOCATIONwith the region of your Secure Web Proxy instance.
Tag
Create an authorization policy YAML file to allow certain requests.
The following example creates an
authz-policy-tag.yamlfile for the Secure Web Proxy instance namedswp1. The policy allows only the requests that originate from a Google Cloud resource with a tag value ofTAG_VALUE_PERMANENT_IDto access the example1.com/url1 URL path.$ cat >authz-policy-tag.yaml <<EOF name: my-authz-policy-tag-allow target: resources: - "projects/PROJECT_ID/locations/ LOCATION /gateways/ GATEWAY_NAME " policyProfile: REQUEST_AUTHZ httpRules: - from: sources: - resources: - tagValueIdSet: ids: ["TAG_VALUE_PERMANENT_ID"] to: operations: - hosts: - exact: "example1.com" paths: - exact: "/url1" action: ALLOW EOFReplace the following:
PROJECT_ID: ID of your Google Cloud projectLOCATION: region of your Secure Web Proxy instanceGATEWAY_NAME: name of your Secure Web Proxy gatewayTAG_VALUE_PERMANENT_ID: permanent ID of a tag value, such astagValues/123456789012
Create an authorization policy and import the YAML file by using the
gcloud network-security authz-policies importcommand.The following example command imports the previously created policy file and creates an authorization policy in the specified Google Cloud region:
gcloud network-security authz-policies import my-authz-policy-tag-allow --source=authz-policy-tag.yaml --location= LOCATIONReplace
LOCATIONwith the region of your Secure Web Proxy instance.
Authorization policy to delegate authorization decisions
For complex authorization decisions that can't be expressed by using standard
ALLOW or DENY rules, you can create an authorization
policy with a CUSTOM action. You can then delegate your authorization
decisions to authorization
extensions
(Service Extensions).
When you configure a policy with a CUSTOM action, Secure Web Proxy offloads
the request metadata or payload to Service Extensions. Depending
on the response from Service Extensions, the proxy either allows
or rejects the traffic.
Secure Web Proxy supports the following types of delegations:
Delegate request authorization decisions to Service Extensions: you can use an authorization policy that's configured with a
CUSTOMaction and aREQUEST_AUTHZprofile to delegate decisions based on request metadata and headers. In this mode, the access decision is delegated to an authorization extension. You can use this mode to verify identities and permissions.Delegate content authorization decisions to Service Extensions: you can use an authorization policy with a
CUSTOMaction and aCONTENT_AUTHZprofile to delegate decisions to an authorization extension based on the actual data payload of the request. This mode lets you enable deep content inspection and security enforcement, letting you scan for sensitive information or malicious patterns by integrating with services like Model Armor.
Limitations
When you implement authorization policies for Secure Web Proxy, the following limitations apply:
Target and connectivity constraints: authorization extensions for Secure Web Proxy don't support Identity-Aware Proxy (IAP) as a direct target.
Policy conflict and compatibility: if you have a gateway security policy with existing security rules, then you don't need to remove them. Secure Web Proxy ignores these rules when you apply an authorization policy to your instance.
Protocol and inspection requirements: to configure Secure Web Proxy authorization policies, you must enable TLS inspection.