Secure access to private web applications

This document describes how to set up a Chrome Enterprise Premium secure gateway for securing access to your private web applications.

A Chrome Enterprise Premium secure gateway functions as a forward proxy, enforcing a zero trust access framework and delivering granular, context-aware control over who accesses your private web applications.

How securing access to private web applications works

By establishing a secure tunnel and enforcing context-aware access policies, the secure gateway keeps private applications private and shielded from public internet exposure. A client-side browser configuration directs traffic for these applications through the secure gateway proxy endpoint. The secure gateway then applies the relevant access policy and, if permitted, routes the request to the destination application.

The secure gateway can protect private web applications hosted in the following environments:

• Google Cloud project: The secure gateway can direct access to applications running in your Google Cloud VPC network.

• Non-Google Cloud (on-premises data centers or other clouds): You must first establish a connection between your private VPC network on Google Cloud and the non-Google Cloud network. This is commonly done using Cloud VPN or Cloud Interconnect. The secure gateway then uses the connection to send the traffic to your private VPC network, which in turn routes it to the non-Google Cloud environment.

Before you begin

Before setting up the secure gateway, verify that you have the following:

• A Chrome Enterprise Premium license
• Access to the Google Admin console with an administrator account
• A Google Cloud project with an assigned billing account and the following API enabled: BeyondCorp API

• The following Identity and Access Management (IAM) role granted to the administrator setting things up: Project level: Cloud BeyondCorp Admin (beyondcorp.admin).

• For private applications in a non-Google Cloud environment, a Cloud VPN or Cloud Interconnect connection between your Google Cloud environment and the non-Google Cloud environment where your application resides. For more information about setting up network connections, see the following resources:

  • Cloud VPN documentation
  • Cloud Interconnect documentation

Set up your shell environment

To streamline the setup process and interact with the secure gateway APIs, define the following environment variables in your working shell.

• General parameters

  API="beyondcorp.googleapis.com"
  API_VERSION=v1
  PROJECT_ID=MY_PROJECT_ID
  APPLICATION_ID=MY_PRIVATE_APPLICATION
  APP_DISPLAY_NAME=MY_PRIVATE_APP_DISPLAY_NAME
  APP_HOSTNAME=MY_HOST_NAME
  PRIVATE_NETWORK_RESOURCE_NAME=MY_PRIVATE_NETWORK_RESOURCE_NAME
  

  Replace the following:

  • MY_PROJECT_ID: The ID of the project where the secure gateway is created.
  • MY_PRIVATE_APPLICATION: A unique ID for the application resource.
  • MY_PRIVATE_APP_DISPLAY_NAME: The human-readable name to display.
  • MY_HOST_NAME: The primary hostname that users access.
  • MY_PRIVATE_NETWORK_RESOURCE_NAME: The full resource name of the VPC network where your application is hosted or connected to your non-Google Cloud environment.

• Secure gateway parameters

  SECURITY_GATEWAY_ID=MY_SECURITY_GATEWAY_ID
  SECURITY_GATEWAY_DISPLAY_NAME=MY_SECURITY_GATEWAY_DISPLAY_NAME
  

  Replace the following:

  • MY_SECURITY_GATEWAY_ID: The ID of the secure gateway that you want to create. The ID can be a maximum of 63 characters and can contain lowercase letters, numbers, and hyphens. The first character must be a letter, and the last character can be a letter or a number.
  • MY_SECURITY_GATEWAY_DISPLAY_NAME: The human-readable name of the secure gateway. The name can be up to 63 characters long and include printable characters.

Create a secure gateway

A Chrome Enterprise Premium secure gateway is a fundamental building block for establishing secure connections to your applications. It allocates a dedicated project and network, providing isolation and security.

To create a secure gateway, complete the following steps.

1. Create a file named securityGateway.json using the following example.

   {
      "display_name": '${SECURITY_GATEWAY_DISPLAY_NAME}',
   }
   

2. Create a secure gateway resource by calling the Create API.

   curl \
   -H "Authorization: Bearer $(gcloud auth print-access-token)" \
   -H "Content-Type: application/json" \
   -X POST \
   -d @securityGateway.json \
   "https://${API}/${API_VERSION}/projects/${PROJECT_ID}/locations/global/securityGateways?security_gateway_id=${SECURITY_GATEWAY_ID}"
   

Configure a private web application

Before you can define specific application resources in the secure gateway, you must configure the necessary permissions and network settings to enable connectivity and proper routing.

Grant permissions to the service account

For the secure gateway to successfully send traffic to your VPC network, it needs certain IAM permissions granted to its delegating service account. This allows the secure gateway to reach your private applications, whether they are hosted within a Google Cloud VPC or in a non-Google Cloud environment connected through Cloud VPN or Cloud Interconnect.

1. Identify the delegating service account email. This email is in the delegatingServiceAccount field of your security gateway resource.

   {
      "name": "projects/${PROJECT_ID}/locations/global/securityGateways/${SECURITY_GATEWAY_ID}",
      "createTime": "2024-10-28T20:46:50.949740776Z",
      "updateTime": "2024-10-29T18:41:18.520661431Z",
      "state": "RUNNING",
      "delegatingServiceAccount": "security-gateway@my-gateway-service-account.iam.gserviceaccount.com"
   }
   

2. Set environment variables for the service account and your target VPC project.

   DELEGATING_SERVICE_ACCOUNT="security-gateway@my-gateway-service-account.iam.gserviceaccount.com" # Replace with actual value
   

3. Grant the roles/beyondcorp.upstreamAccess IAM role to the delegating service account on your private VPC project.

   gcloud projects add-iam-policy-binding ${PRIVATE_NETWORK_RESOURCE_NAME} \
       --role=roles/beyondcorp.upstreamAccess \
       --member=serviceAccount:${DELEGATING_SERVICE_ACCOUNT}>
   

Allow approximately two minutes for the Identity and Access Management policy to take effect after you grant the role.

Configure network routing and firewall rules

To allow traffic from the secure gateway to reach your private web applications, configure firewall rules, network routing, and DNS settings.

Firewall rules for applications in Google Cloud

If your private web application is hosted within your Google Cloud VPC network, such as on a Compute Engine VM, a Google Kubernetes Engine service with an internal IP, or behind an internal TCP/UDP load balancer, configure Google Cloud VPC firewall rules. This allows ingress TCP traffic from the secure gateway IP ranges: 34.158.8.0/21 and 136.124.16.0/20.

Firewall rules for applications in non-Google Cloud environments

If your private web application resides on an on-premises data center or on another cloud provider's network, and is connected to your Google Cloud VPC using Cloud VPN or Cloud Interconnect, configure firewall rules on your on-premises firewall or the equivalent network security controls, such as security groups and network ACLs, in the other cloud environment. This allows ingress TCP traffic from the secure gateway IP ranges.

Configure routing from non-Google Cloud environments to a secure gateway

For two-way communication when protecting private applications hosted in non-Google Cloud environments, such as on-premises or other clouds, your external network must create a return path to the following secure gateway IP addresses: 34.158.8.0/21 and 136.124.16.0/20.

Verify that your private network can reach the secure gateway IP ranges through your Cloud VPN or Cloud Interconnect:

• Dynamic routing: If you're using dynamic routing, such as Border Gateway Protocol (BGP) with Cloud Router, verify that your Cloud Router in Google Cloud explicitly advertises secure gateway IP ranges to your on-premises BGP device. Although BGP dynamically exchanges many routes, the secure gateway IP ranges require explicit advertisement.

• Static routing: If you're using static routes, you must manually add routes for each of the secure gateway IP ranges on your on-premises network equipment, such as your router or firewall. These static routes must specify that traffic destined for the secure gateway IP ranges must be sent over the Cloud VPN or Cloud Interconnect connection.

DNS configuration for secure gateway private hostname resolution

For the secure gateway to resolve your private application hostnames, your Google Cloud VPC network must be able to resolve the hostnames using Cloud DNS. The specific Cloud DNS configuration depends on where your private DNS records are authoritatively hosted:

• Applications within Google Cloud using Cloud DNS private zones: If your private applications are hosted in Google Cloud and their DNS records are managed within Cloud DNS private zones associated with your VPC network, verify that the zones are correctly configured and accessible. The secure gateway uses your VPC's existing Cloud DNS resolution capabilities.

• Applications in non-Google Cloud environments or using external DNS servers: If your private applications are in non-Google Cloud environments (on-premises or other clouds) or if their DNS records are managed by DNS servers external to your VPC's Cloud DNS private zones, you must configure Cloud DNS to forward queries for these private domains. This typically involves creating Cloud DNS forwarding zones within your VPC. These zones will direct DNS queries for your specified private domains to your authoritative private DNS servers, such as on-premises or other clouds.

For detailed instructions on DNS configuration, see Create a forwarding zone.

Create an application resource

To provide access to a private web application, you must establish it within the secure gateway framework by creating an application resource. This resource defines how the secure gateway identifies traffic for your application (based on the hostname) and where to route that traffic.

1. Create a JSON file named application.json using the following example.

   {
   "name": "${APP_DISPLAY_NAME}",
   "endpoint_matchers": [
    {"hostname": "${APP_HOSTNAME}"}
   ],
   "upstreams": [{
    "network": {
       "name": "${PRIVATE_NETWORK_RESOURCE_NAME}"
    }
   }]
   }
   

2. Optional: Specify an egress region.

   In some network configurations, you might need to control the Google Cloud region where the secure gateway traffic exits to your private application. For example, this applies if you're using static routes over your Cloud VPN or Cloud Interconnect. For these configurations, you can add an egress policy to the upstream configuration for your application. This egress policy directs the secure gateway to route traffic for the application from the specified Google Cloud region to your private network.

   Following is an example JSON file that includes an egress_policy.

   {
   "name": "${APP_DISPLAY_NAME}",
   "endpoint_matchers": [
    {"hostname": "${APP_HOSTNAME}"}
   ],
   "upstreams": [{
    "network": {
       "name": "${PRIVATE_NETWORK_RESOURCE_NAME}"
    },
    "egress_policy": {
        "regions": [
           "us-central1"
        ]
     }
   }]
   }
   

   Replace us-central1 with the Google Cloud region (such as europe-west1 or asia-northeast1) that aligns with your regional static routing setup. If you don't have specific regional static routing requirements, you can omit the egress policy from your configuration.

3. Create the application resource by calling the Create API.

   curl \
   -H "Authorization: Bearer $(gcloud auth print-access-token)" \
   -H "Content-Type: application/json" \
   -X POST \
   -d @application.json \
   "https://${API}/${API_VERSION}/projects/${PROJECT_ID}/locations/global/securityGateways/${SECURITY_GATEWAY_ID}/applications?application_id=${APPLICATION_ID}"
   

Configure Google Chrome proxy mode

To route traffic for the application resource through the secure gateway, configure Chrome by applying a PAC file in the Chrome settings in the Google Admin console.

1. Create or update a PAC file.

   • If you're creating your first application, create a pac_config.js file using the following example PAC file.

   • If you are creating a second or subsequent application, update your existing pac_config.js file and add the domains of your new application to the sites array, as shown in the following example PAC file.

   function FindProxyForURL(url, host) {
    const PROXY = "HTTPS ingress.cloudproxy.app:443";
    const sites = ["MY_HOST_NAME"]; // add URLs to match all of your CAG app domains
   
    or (const site of sites) {
      if (shExpMatch(url, 'https://' + site + '/*') || shExpMatch(url, '*.' + site + '/*')) {
        return PROXY;
      }
    }
   return 'DIRECT';
   }
   

   If you are using an existing PAC file that is not specific to a secure gateway, merge the PAC files by adding the domains of your application to the sites array.

2. Upload the file so that it is publicly downloadable. For example, you can upload the file to Cloud Storage, and make the file publicly downloadable by granting all users the Storage Object User role on the bucket.

3. To verify that the uploaded file is always the latest version, you can adjust its caching behavior by setting the Cache-Control header to no-cache. This setting prevents browsers and intermediate servers from storing a copy of the file, so that Chrome always downloads the most recent version.

   For more information about Cache-Control and how it affects browser caching, see Cache-Control header.

4. Copy the public URL of the uploaded file.

Update the proxy mode settings

1. Go to the Google Admin console.
2. Click Devices -> Chrome -> Settings.
3. Select an organization unit or group, and then click Proxy mode.
4. In the Proxy mode page, select Always use the proxy auto-config specified below and enter the URL of the PAC file from Cloud Storage.

Configure an access policy

You can apply an access policy at the secure gateway level or application level:

• Secure gateway resource: Apply a policy at the secure gateway level to control access to all associated applications.
• Individual application: For more granular control, you can apply an access policy to an individual application.

1. Create a JSON format file named setIamPolicy.json and add the following.

   {
    "policy": {
      object (POLICY)
    }
   }
   

   Replace POLICY with an IAM allow policy. The etag in the policy must be the same as the etag in the active policy, which you can get by calling the getIamPolicy method.

2. To allow a specific group to use the secure gateway, grant the roles/beyondcorp.securityGatewayUser role to the group.

   {
    "policy": {
      "version": 3,
      "bindings": [
        {
          "role": "roles/beyondcorp.securityGatewayUser",
          "members": [
                  "group:"
          ]
        }
      ],
      "etag": "AA1jlb"
    }
   }
   

   For more identifiers, such as serviceAccount, user, group, principal, and principalSet, in policy bindings, see IAM principal.

3. Enforce the access policy on the secure gateway specified in the JSON file by calling the setIamPolicy API.

   curl \
   -H "Authorization: Bearer $(gcloud auth print-access-token)" \
   -H "Content-Type: application/json" \
   -X POST \
   -d @setIamPolicy.json \
   "https://${API}/${API_VERSION}/projects/${PROJECT_ID}/locations/global/securityGateways/${SECURITY_GATEWAY_ID}:setIamPolicy"
   

   To enforce the access policy on an application, use the following command:

   curl \
   -H "Authorization: Bearer $(gcloud auth print-access-token)" \
   -H "Content-Type: application/json" \
   -X POST \
   -d @setIamPolicy.json \
   "https://${API}/${API_VERSION}/projects/${PROJECT_ID}/locations/global/securityGateways/${SECURITY_GATEWAY_ID}/applications/${APPLICATION_NAME}:setIamPolicy"
   

You can also set access policies with access levels as a condition, as shown in the following example.

{
  "policy": {
    "version": 3,
    "bindings": [
      {
        "role": "roles/beyondcorp.securityGatewayUser",
        "members": [
                "group:"
        ],
        "condition": {
                "expression": "'accessPolicies/1234567890/accessLevels/in_us' in request.auth.access_levels",
                "title": "Source IP must be in US"
        }
      }
    ],
    "etag": "A1jlb"
  }
}'

Install the Chrome Enterprise Premium extension

The Chrome Enterprise Premium extension is an integral part of a secure gateway and helps with authentication. Install the extension for all of the users of the secure gateway. For information about deploying the extension, see View and configure apps and extensions.

1. Go to the Google Admin console.
2. Click Chrome browser -> Apps & Extensions.
3. Click the Users & browsers tab.
4. To add a Chrome extension, click the + button.
5. Search for ekajlcmdfcigmdbphhifahdfjbkciflj, and then force install to all users in the organization unit or group.

6. Click the installed extension, and then go to the Policy for extensions field and provide the following JSON value:

   {
    "securityGateway": {
      "Value": {
        "authentication": {},
        "context": { "resource": "projects/MY_PROJECT_ID/locations/global/securityGateways/MY_SECURITY_GATEWAY_ID" }
      }
    }
   }
   

End user experience

When the setup is complete, end users accessing the protected SaaS application are granted or denied access based on the access policy applied to the application.

Accessing the application in Chrome

The Chrome Enterprise Premium extension is required to direct traffic through the secure gateway. The extension handles the authentication between the user and the secure gateway. The extension is automatically installed through the domain policy.

When users access the SaaS application that you configured, their traffic goes through the secure gateway, which checks if they satisfy the access policy. If the users pass the access policy checks, they are granted access to the application.

When browser access to the application is rejected by the authorization policy, users receive an Access denied message.

What's next

• Troubleshoot secure gateway issues
• Manage a secure gateway