Controlling access to websites and apps

To secure your web resources in a simple-to-manage, scalable, and granular way, Google Cloud offers context-aware access via Identity-Aware Proxy (IAP). IAP is designed to enforce the BeyondCorp security model, which establishes a zero-trust perimeter on the public internet for secure, remote work without the need for a traditional VPN.

You can allow secure access to your websites or web apps for users located anywhere or on any device by using IAP to control granular restrictions. Access control can be configured based on the user's identity and context of their request without making additional site changes. You can also centrally define and enforce access policies across multiple apps and sites, including IAM policies with conditional binding. IAP works with other Google Cloud offerings including App Engine standard environment, Compute Engine, and Google Kubernetes Engine.

Configuring your access levels

When accessing web resources that IAP knows about, users need to log in with their Google identity service credentials (for example, their Gmail or Google Workspace email address) or an LDAP registered with an LDAP directory service that’s synchronized with the Google identity service. If the user is authorized, IAP forwards their request to the web server along with header data that includes the user’s identity.

Image shows IAP routing requests from authenticated users to a web server.

Figure 1. Controlling user access to web resources behind IAP.

In the Cloud console, you can configure IAP to simply block unauthorized users from accessing a given resource.

To do so for a resource on App Engine:

  1. Open the Identity-Aware Proxy page in your active project.
  2. Select the resource you want to modify.

  3. Click Add Principal and add the email addresses of groups or individuals to whom you want to grant the IAP-secured Web App User role for the project.

    The table below lists some common access scenarios and the principal to grant access to for each scenario.

    Access Level Example Web Resource Example Principal
    Open, public access Company public website. allUsers
    User-authenticated access Site to submit support tickets. allAuthenticatedUsers
    Employee-restricted access App running on the company intranet. bigcorpltd.com, contractors@bigcorpltd.com
    Highly-sensitive, device and employee-restricted access App with access to customer private information. customer.support@bigcorpltd.com

    Note: This access level requires adding restriction information through the Access Context Manager, such as device policy attributes or allowed IP subnetworks. Users also need to have work profiles on their mobile device or a Chrome extension set up on their browser.
  4. Click Add to save your changes.

Next steps