Set up authorization policies for Secure Web Proxy

This page describes how to set up authorization policies for Secure Web Proxy.

Before you begin

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:

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.

  1. Create the authorization policy YAML file.

    The following example creates an authz-policy.yaml file. The policy allows traffic to the specified host and path only if the client presents a certificate that matches the defined SPIFFE ID principal.

    $ 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
    EOF
    

    Replace the following:

    • PROJECT_ID: ID of your Google Cloud project
    • LOCATION: region of your Secure Web Proxy instance
  2. Create an authorization policy and import the YAML file by using the gcloud network-security authz-policies import command.

    gcloud beta network-security authz-policies import my-authz-policy-allow
        --source=authz-policy.yaml
        --location= LOCATION 
    

    Replace LOCATION with 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:

Service account

  1. Create an authorization policy YAML file to allow certain requests.

    The following example creates an authz-policy.yaml file for the Secure Web Proxy instance named swp1. The policy is configured to allow requests from a Compute Engine virtual machine (VM) instance with the service account my-sa-123@56788.iam.gserviceaccount.com to 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
    EOF
    

    Replace the following:

    • PROJECT_ID: ID of your Google Cloud project
    • LOCATION: region of your Secure Web Proxy instance
  2. Create an authorization policy and import the YAML file by using the gcloud network-security authz-policies import command.

    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= LOCATION 
    

    Replace LOCATION with the region of your Secure Web Proxy instance.

Tag

  1. Create an authorization policy YAML file to allow certain requests.

    The following example creates an authz-policy-tag.yaml file for the Secure Web Proxy instance named swp1. The policy allows only the requests that originate from a Google Cloud resource with a tag value of TAG_VALUE_PERMANENT_ID to 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
    EOF
    

    Replace the following:

    • PROJECT_ID: ID of your Google Cloud project
    • LOCATION: region of your Secure Web Proxy instance
    • GATEWAY_NAME: name of your Secure Web Proxy gateway
    • TAG_VALUE_PERMANENT_ID: permanent ID of a tag value, such as tagValues/123456789012
  2. Create an authorization policy and import the YAML file by using the gcloud network-security authz-policies import command.

    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= LOCATION 
    

    Replace LOCATION with 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 CUSTOM action and a REQUEST_AUTHZ profile 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 CUSTOM action and a CONTENT_AUTHZ profile 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.

What's next