Code360 powered by Coding Ninjas X Code360 powered by Coding Ninjas X
Table of contents
Apply BeyondCorp Enterprise to cloud resources
Before you start
Securing your apps and resources with IAP
Virtual machine resources
Creating an access level with Access Context Manager
Applying access levels
Enabling device trust and security with Endpoint Verification
BeyondCorp Enterprise
Benefits to users
Common use cases
Common signals
BeyondCorp Enterprise compared with Google Cloud
Securing the Google Cloud console and the Google Cloud APIs
Deploying Endpoint Verification [Optional]
Creating an access level
Creating a group of users
Granting the required IAM permissions
Creating an access binding
Verifying success
Securing non-Google Cloud applications using the On-Prem Connector
Deploy a connector for an on-premises app
Manage a connector for an on-premises app
Securing App Engine apps with IAP
Starting Cloud Shell
Getting the sample code
Deploying the application
Enabling IAP
Selecting a project
Configuring the OAuth consent screen
Setting up IAP access
Turning on IAP
Test Access
Audit logging
Audit log record content
Accessing the audit log
Using hostname and path conditions 
String normalization
Subdomain endings
Frequently Asked Questions
What is remote access with BeyondCorp?
How does Google BCE work?
What are the three key ideas behind zero trust?
Last Updated: Mar 27, 2024

BeyondCorp Enterprise

Author Aditi
0 upvote
Leveraging ChatGPT - GenAI as a Microsoft Data Expert
Prerita Agarwal
Data Specialist @
23 Jul, 2024 @ 01:30 PM


With the help of BeyondCorp Enterprise, a cutting-edge zero-trust platform, your employees and extended workforce may access apps both on- and off-premises and operate remotely without needing a conventional remote-access VPN. Google's BeyondCorp Enterprise is a platform designed to help enterprises adopt this novel strategy. An organization can make sophisticated access decisions and enforce security policy by connecting a user's information with device and location context.

For more information about BeyondCorp Enterprise, let's dive into the article.

Apply BeyondCorp Enterprise to cloud resources

This section outlines the fundamental procedures for integrating BeyondCorp Enterprise with your on-premises and Google Cloud resources.

Before you start

You must do the following before making your apps and resources context-aware:

  • Create a few Cloud Identity accounts in your company if you don't already have any user accounts.
  • Choose a resource that you want to keep safe. If you don't have a resource, configure one of the following.
    • A web application is running on Google Cloud behind an HTTPS load balancer. This includes on-premises and cloud-based and online apps like App Engine apps.
    • a Google Cloud virtual machine
  • Choose the principals to whom you wish to limit and allow access.
before you start

Securing your apps and resources with IAP

An Identity-Aware Proxy (IAP) creates a central identity awareness layer for apps and services accessed over HTTPS and TCP. This implies that you may manage access to each app and resource rather than employing network-level firewalls.

By choosing one of the following guides, you can secure your Google Cloud app and all of its resources:

  • App Engine standard and flexible environment
  • Compute Engine
  • Google Kubernetes Engine

IAP can be expanded to contexts outside the Google Cloud, including on-premises and other clouds.

Virtual machine resources

You can restrict access to administrative services like SSH and RDP on your backends by constructing tunnels that direct TCP traffic through IAP to virtual machine instances.

Creating an access level with Access Context Manager

It's time to implement richer access controls using access levels after you've protected your resources and apps with IAP. Access levels are made via the Access Context Manager. Access levels can use the following characteristics to restrict access:

  • IP subnetworks
  • Regions
  • Access level dependency
  • Principals
  • Device policy 

Follow the instructions in the Creating an access Level guide to creating an access level.

Applying access levels

An access level is ineffective until it is applied to the Identity and Access Management (IAM) policy for a resource that IAP protects. The IAP role being utilized to allow access to your resource must now have an IAM Condition added to it. Your resources are now secured with BeyondCorp Enterprise after applying your access level.

Enabling device trust and security with Endpoint Verification

You can use device-based trust and security access control attributes with access levels to further reinforce the security of your BeyondCorp Enterprise secured resources. This control can be enabled by endpoint verification.

For Windows, Mac, and Chrome OS devices, there is a Chrome extension called Endpoint Verification. Access Context Manager uses the device attributes obtained by Endpoint Verification to enforce fine-grained access control user access levels.

Get the tech career you deserve, faster!
Connect with our expert counsellors to understand how to hack your way to success
User rating 4.7/5
1:1 doubt support
95% placement record
Akash Pal
Senior Software Engineer
326% Hike After Job Bootcamp
Himanshu Gusain
Programmer Analyst
32 LPA After Job Bootcamp
After Job

BeyondCorp Enterprise

Enterprises today are transitioning to a security model where guarded networks are insufficient. The most secure assets of a firm must be appropriately protected, and personnel must be given the best conditions to be productive.

Google's BeyondCorp Enterprise is a platform designed to help enterprises adopt this novel strategy. An organization can make sophisticated access decisions and enforce security policy by connecting a user's information with device and location context.

BeyondCorp Enterprise's main objectives are:

  • Threat and data protection protects users from exfiltration threats like copy and paste, extends DLP safeguards into the browser, and aids in preventing malware from entering corporate-managed devices, bringing security to your enterprise devices.
  • By utilizing an end-request user's context to ensure each request is authenticated, approved, and as secure as feasible, richer access controls protect access to protected systems (applications, virtual machines, APIs, and so on).

Benefits to users

In addition to offering end users a better user experience regardless of where they access from or what kind of device they use to do so, BeyondCorp Enterprise offers a security paradigm that enables improved security posture and policy for both applications and devices:

  • Administrators should:
    • To consider dynamic changes in a user's context, strengthen the security posture.
    • Limit the resources an end user should access inside the access boundary.
    • No matter who administers the devices, enforce device security postures for access by workers, contractors, partners, and customers.
    • Security standards can be expanded by using multifactor authentication and per-user session management.
  • For customers:
    • Enable productivity for all end users everywhere without jeopardizing security.
    • Depending on the context, grant appropriate access to work applications.
    • Using granular access policies enables access to privately owned devices.
    • Access internal applications without segmented networks are throttling you down.

Common use cases

Enterprises have common security concepts they want to extend to all people, devices, and apps as end users operate outside the office more frequently and from a variety of devices:

  • Non-employees should be able to use a single web application installed on Google Cloud or another cloud services platform without needing a VPN.
  • If they adhere to a basic security standard, permit non-employees to access data via personal or mobile devices.
  • Ensure staff members are not permitted to copy and paste sensitive information into emails or save data to personal storage services like Google Drive.
  • Give access to some essential systems only to devices maintained by the enterprise.
  • Protect company data with DLP.
  • Using a user's location to control gate access.
  • Hybrid deployments, which include Google Cloud, other cloud service platforms, and on-premises resources, protect the applications.

Common signals

BeyondCorp Enterprise provides standard signals that businesses might consider while deciding on a course of action, such as:

  • User or group information
  • Location (IP or geographic region)
  • Device
    • Enterprise-managed devices
    • Personally-owned devices
    • Mobile devices
  • Third-party device signals from collaborators in the BeyondCorp Alliance.
    • Check Point
    • CrowdStrike
    • Lookout
    • Tanium
    • VMware

BeyondCorp Enterprise compared with Google Cloud

BeyondCorp Enterprise offers enterprise security capabilities in addition to Google Cloud's standard security measures, focusing on safeguarding applications through authentication and authorization. With end-user protections and rich access policy controls, BeyondCorp Enterprise expands those protections to programs and data running everywhere.

The following table compares the standard features offered to Google Cloud clients with those provided by BeyondCorp Enterprise.

BeyondCorp Enterprise comparison 1
BeyondCorp Enterprise comparison 2
BeyondCorp Enterprise comparison 3

Securing the Google Cloud console and the Google Cloud APIs

Thanks to context-aware access, access to the console and the Google Cloud APIs is restricted using context-based constraints. It enhances the currently available BeyondCorp Enterprise suite (Endpoint Verification and Access Context Manager), making it easier to guarantee that members of your business who meet the specified access requirements can access the console and Google Cloud APIs (including via the Google Cloud CLI).

The steps listed below can be used to configure this feature:

  • [Optional] Install Endpoint Verification on the devices in your company.
  • In the Access Context Manager, create an access level.
  • Create a set of users to whom the limitations of BeyondCorp Enterprise will apply.
  • Get the Identity and Access Management rights you need.
  • Make a context-aware access binding that lays rules for the console and the Google Cloud APIs.
cloud image

Deploying Endpoint Verification [Optional]

By using endpoint verification, you can compile a list of the gadgets that are gaining access to the data belonging to your company. It also offers crucial device trust and security-based access control as a component of a BeyondCorp Enterprise solution. It can aid in enforcing fine-grained access control on your Google Cloud services.

Mac, Windows, and Linux users can run Endpoint Verification as a Chrome extension on desktop computers and laptops. Members of the organization can install it on their own devices, or administrators can do it using the Google Workspace Admin Console.

Creating an access level

By defining a fundamental access level in Access Context Manager, you must specify an access level that will be considered for determining access to the console and the Google Cloud APIs.

Creating a group of users

Make a list of users who must adhere to context-sensitive limitations. To access the console and the Google Cloud APIs, any users in this group who are also employees of your company must meet the access level you previously defined.

Granting the required IAM permissions

Give IAM permissions needed to construct Access Context Manager access bindings at the organizational level.


  • Navigate to the console's IAM & Admin page.
  • To configure the following, click Add.
    • New members: Name the user or group to which the permissions should be granted.
    • Select a role: Choose Cloud Access Binding Admin > Access Context Manager.
  • Press Save.


  • Make sure you have access to add IAM permissions at the organization level. You must have the Organization Admin job, at the very least.
  • After making sure you have the necessary rights, use the following to log in:
    gcloud auth login
  • Run the following command to assign the GcpAccessAdmin role:
gcloud organizations add-iam-policy-binding ORG_ID \
  --member=user:EMAIL \
  • The ID for your organization is ORG_ID. The command below can be used to locate your organization ID if you don't already have it:
gcloud organizations list
  • EMAIL is the email address of the individual or organization to which the job is to be granted.

Creating an access binding

The group of users you previously created and the access level you specified for the Access Context Manager to access the console and Google Cloud APIs may now be mapped by creating an access binding.


  • Navigate to the console's BeyondCorp Enterprise page.
    Go to BeyondCorp Enterprise
  • Click Select after selecting an organization.
  • To select which user groups should have access, click Manage access.
  • To configure the following, click Add.
  • Members groups: Indicate the group to whom access should be granted. Only groups have not already been linked to an access level that can be chosen.
  • Choose degrees of access Select the access level to be used for the group.
  • Press Save.


For further details on this and other gcloud access-context-manager cloud-bindings commands, including extra flag options, consult the Google Cloud CLI.

gcloud access-context-manager cloud-bindings create \
    --group-key GROUP_ID \
    --level ACCESS_LEVEL \
    --organization ORG_ID


  • Make the request body:
    • GROUP_ID should be changed to the Group ID for the user group you previously created.
    • The accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME format for access levels. When you create the access level, Access Context Manager contains the information for POLICY_ID and ACCESS_LEVEL_NAME.
  "groupKey": "GROUP_ID",
  "accessLevels": [ "ACCESS_LEVEL" ]
  • Call the gcpUserAccessBindings API to create the access binding, replacing the ORG ID with the organization ID you used to create the GcpAccessAdmin role:
  • A GcpUserAccessBinding resource is returned in the response, structured as follows:
  // Unique name for the access binding, in the form
  // "organizations/ORG_ID/gcpUserAccessBindings/BINDING_ID"
  name: string,

  // Unique Group ID.
  group_key: string,

  // The access level that users of the group must satisfy, in the form
  // "accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME"
  access_levels: [ string ]

Verifying success

Access to the console and Google Cloud APIs should be restricted once the access bindings have been configured for a group of users following the bound access level. The binding can be edited, deleted, or checked to see if it was made correctly.


All-access bindings for the organization are visible after establishing one and can be changed or deleted as necessary.


  • To see all of an organization's access bindings:
gcloud access-context-manager cloud-bindings list \
    --organization ORG_ID
  • To alter a binding on access, such as changing the access level:
gcloud access-context-manager cloud-bindings update \
    --binding ACCESS_BINDING \
    --level ACCESS_LEVEL
  • To eliminate a specific access binding:
gcloud access-context-manager cloud-bindings delete \
    --binding ACCESS_BINDING


  • To see all of an organization's access bindings:
  • A list of GcpUserAccessBinding resources is returned.
  • Create a request body that outlines the modification, then contact the endpoint with the resource's name to adjust an access binding, such as changing the access level:
  "accessLevels": [ "ACCESS_LEVEL" ]
  • Call the endpoint with the resource name to remove a specific GcpUserAccessBinding resource:

Securing non-Google Cloud applications using the On-Prem Connector

This section describes establishing an IAP connector to secure an on-premises, HTTP, or HTTPS-based app that Google Cloud does not host.

Deploy a connector for an on-premises app

  • Visit the IAP admin page
    Go to the IAP admin page
  • By selecting On-prem connectors setup, you can start configuring your connector deployment for an on-premises app.
  • By selecting Enable APIs, make sure the necessary APIs are loaded.
  • Select the network and subnet for the deployment (or opt to build a new one), decide whether the deployment should use a Google-managed certificate or one you manage, and then click Next.
  • The information for the on-premises app you want to add is as follows:
    • A request's external URL is sent to Google Cloud. Traffic enters the environment at this URL.
    • The app's name. It will also be the name of a brand-new backend service that sits in front of the load balancer.
    • The specifics of the on-premise endpoint type:
      • Names that are fully qualified (FQDN): the website to which the connection should send traffic.
      • IP address: One or more zones (such as us-central1-a) for the deployment of the IAP connector and, for each, the IPv4 address of the internal destination for the on-premises app to which IAP sends traffic following user authorization and authentication.
    • The on-premise endpoint's protocol.
    • The port number, such as 443 for HTTPS or 80 for HTTP, that the on-premises destination uses.
  • To save the information for that app, click Done. Then, if necessary, you can specify other on-premises apps for the deployment.
  • Click Submit when you're ready to start deploying the defined apps.

When the deployment is finished, your on-premise connector apps will be visible in the HTTP resources table, and IAP may then be turned on. It can take a few minutes for the certificates to provide if you allow Google to generate and handle them automatically. The detail page for Cloud Load Balancing enables you to verify the status.

Manage a connector for an on-premises app

  • Selecting an On-prem connections setup allows you to add more applications to your deployment anytime.
  • By erasing the deployment as a whole, you can remove the on-premises connector:
    • Visit the Deployment Manager page.
    • Go to the Deployment Manager page.
    • Select the checkbox next to the "on-prem-app-deployment" deployment in the list of deployments.
    • Click Delete in the page's header.
  • You can remove a specific app by selecting the delete option in the On-prem connections setup. At least one app must be present in the on-premises connector. Please delete the complete deployment if you want to remove all apps.

Securing App Engine apps with IAP

The deployment of an App Engine standard or flexible environment application and its security with Identity-Aware Proxy are covered in this section (IAP). The quickstart contains a sample code for a web application that checks the name of logged-in users in the App Engine standard environment.

Starting Cloud Shell

  • At the console window's top, select Activate Cloud Shell. A command-line prompt is shown when a Cloud Shell session launches in a new frame at the bottom of the console. The initialization of the shell session may take a few seconds.
  • To view the project IDs for your projects, enter the following in Cloud Shell:
gcloud projects list
  • To set the default project, enter the command below, replacing YOUR-PROJECT-ID with the project ID you want to use for this quickstart:
gcloud config set project YOUR-PROJECT-ID

Getting the sample code

  • To get the sample application, enter the upcoming command in Cloud Shell:
git clone
  • Go to the directory where the example code is located by changing:
cd python-docs-samples/appengine/standard_python3/hello_world/

Deploying the application

  • To deploy the application to App Engine, use gcloud:
    gcloud app deploy
  • The target URL is shown as https://YOUR PROJECT in its current format. Use your web browser to go to that URL to access your application.

Enabling IAP

Selecting a project

  • Navigate to Identity-Aware Proxy's page.
  • Go to the Identity-Aware Proxy page
  • You will be asked to choose the project you want to secure with IAP if you don't currently have one active. Choose the project where the example application was installed.

Configuring the OAuth consent screen

The OAuth consent screen for your project will prompt you to configure it if you haven't already. A product name and email address are necessary for the OAuth consent screen.

Setting up IAP access

  • Visit the OAuth consent page.
    Configure consent screen
  • Choose the email address you want to use as a public contact under the Support email. The email address must be linked to the account of the user who is currently signed in or to a Google Group to which the user is a member.
  • Enter the name of the application that you want to appear in.
  • Any more information is optional.
  • Press Save.

Repeat the previous configuration steps to modify information on the OAuth consent screen later, such as the product name or email address.

Turning on IAP

  • Navigate to Identity-Aware Proxy's page.
    Go to the Identity-Aware Proxy page
  • You can choose by checking the box to the left of the resource you want to change. Select Add Member from the side panel on the right.
  • Add the email addresses of the organizations or people you wish to grant the IAP-secured Web App User role to in the Add members dialogue.
  • Members of the following account types are permitted:
    • Account on Google:
    • Google Group:
    • Service account:
    • Domain for G Suite:

Make sure you include a Google Account that you have access to.

Grant the IAP-secured Web App User role to 'allUsers' or 'allAuthenticatedUsers' to make a resource public (while sibling resources are restricted). The Public access section explains how these two differ from one another.

  • Click Add once you have completed adding members.

Test Access

  • Locate the App Engine app you wish to limit access to under HTTPS Resources on the Identity-Aware Proxy page. The URL of the app is displayed in the Published column.Toggle the IAP column's on/off switch to enable IAP for the app.
    • The clientauthconfig.clients.create, clientauthconfig.clients.getWithSecret, and appengine.applications.update permissions are required to allow IAP. Roles, such as the Project Editor role, grant these permissions.
  • Click Turn On in the Turn on IAP window that displays to confirm that you want IAP to secure the application. IAP requires login information for all connections to your application when you turn it on.

Audit logging

This section explains how audit logging functions when BeyondCorp Enterprise is used to secure the console and the Google Cloud APIs.

All-access requests to the console and the Google Cloud APIs that are rejected due to security policy breaches are automatically logged to Cloud Logging by BeyondCorp Enterprise. The audit log records are available for future study and are safely saved in the Google infrastructure. The Google Cloud console provides access to the audit log's content per organization. The "Audited Resource" logging stream contains the BeyondCorp Enterprise audit log, which is accessible in Cloud Logging.

Audit log record content

Two main categories of information are included in each audit log record: information about the initial call and security policy violations. This is how it is filled:

Audit log record content

Accessing the audit log

The Google Cloud console provides access to the audit log's content per organization. The "Audited Resource" logging stream contains the BeyondCorp Enterprise audit log, which is accessible in Cloud Logging.

Using hostname and path conditions 

Identity and Access Management (IAM) hostname and path conditions are described in this section.

Identity-Aware Proxy (IAP) resources can be secured using a request URL's hostname and path. As an example, the request.path.starts IAM condition can be applied to restrict access to members of the Privileged Access group to URLs that begin with the string "/admin."

String normalization

A URL has a path and a hostname. For instance, the hostname and path /create are both present in the URL Different backends have different ways of interpreting hostnames and paths. When examining regulations, IAP normalizes hostname and path strings to eliminate ambiguity.

In cases where a request has a non-normalized path, IAP executes two policy checks. IAP normalizes the path and runs a second policy check if the non-normalized path passes the first. Access is given if the policy check is successful for both the non-normalized and normalized pathways.

For instance, IAP runs a policy check on the non-normalized path (/internal) of a request with the path /internal; some param/admin. If the first policy check is successful, IAP runs a second one on the normalized path (/internal/admin).


The following are involved in hostname normalization:

  • Getting rid of trailing dots
  • the lowering of characters
  • Transforming into ASCII

Using Punycode, hostnames with non-ASCII characters are further normalized. For a match to be established, your hostname string must be normalized using Punycode. Use a converter like Punycoder to normalize your hostname string with Punycode.

Examples of normalized  hostnames include the following:

Café.fr is normalized  to xn—, and is normalized  to


The following are involved in path normalization:

  • deleting path params
  • converting relative pathways to their equivalents in absolute terms

All characters from through either the following / or the path's conclusion are included in a path parameter. Requests containing path segments beginning with..; are regarded as invalid. /..;bar/ and /bar/..;/, for instance, produce the HTTP 400: Bad Request error.

Examples of normalized  pathways include the next:

  • /internal;some param/admin is normalized to /internal/admin
  • /a/../b is normalized to /b
  • /internal;some param/admin is normalized to /internal/admin

Subdomain endings and are compatible with a policy defined by the""). Set your policy to if you want to restrict it only, include subdomains that end in ("").

Frequently Asked Questions

What is remote access with BeyondCorp?

The BeyondCorp Remote Access software as a service (SaaS) solution offers responsive and user-friendly access to internal web apps for staff members and the extended workforce from nearly any device, anywhere using a web browser without a conventional VPN. Business Obstacle.

How does Google BCE work?

BeyondCorp Enterprise (BCE) provides integrated threat and data security while facilitating simple and safe access to applications and cloud resources by utilizing Google's extensive network. BCE is a secure, agentless platform with zero trust that is scalable.

What are the three key ideas behind zero trust?

A zero trust network comprises three essential elements: user/application authentication, device authentication, and trust.


In this article, we have extensively discussed BeyondCorp Enterprise. We have also explained how to apply beyondcorp enterprise to cloud resources, securing the google cloud console, securing app engines apps with IAP, audit logging, and more in detail.

We hope this blog has helped you enhance your beyondcorp enterprise knowledge. If you would like to learn more, check out our articles on introduction to cloud computingcloud computing technologiesall about GCP and AWS Vs. Azure Vs. Google Cloud. Practice makes a man perfect. To practice and improve yourself in the interview, you can check out Top 100 SQL problemsInterview experienceCoding interview questions, and the Ultimate guide path for interviews.

Do upvote our blog to help other ninjas grow. Happy Coding!

thank you cn
Live masterclass