Securing resources with certificate-based access

Stay organized with collections Save and categorize content based on your preferences.

Certificate-based access works to protect access to many Google resources by identifying devices through their X.509 certificates. Certificate-based access ensures that only users on a trusted device with a Google-generated certificate have administrative access through Identity-Aware Proxy TCP forwarding, or access to the Google Cloud APIs through a VPC Service Controls service perimeter.

This provides a stronger signal of device identity and, most importantly, helps to protect users from credential theft or accidental loss by only granting access when both credentials and the original device certificate are presented.

For a list of VPC Service Controls services, tools, and client libraries supported by certificate-based access, see Certificate-based access supported services, tools, and client libraries.

This feature can be set up with the following steps:

  1. Deploy Endpoint Verification to devices in your organization.
  2. Create an access level in Access Context Manager that requires matching device certificates for access.
  3. Enforce access restrictions by applying the access level through IAP TCP forwarding or a VPC Service Controls service perimeter.
  4. Your users enable access to VM instances or the Google Cloud APIs that are now protected by certificate-based access.

Deploying Endpoint Verification

Endpoint Verification allows you to build an inventory of devices that are accessing your organization's data. As part of a BeyondCorp Enterprise solution, it also provides critical device trust and security-based access control, and can help enforce fine-grained access control on your Google Cloud resources. For certificate-based access, Endpoint Verification is additionally responsible for generating, registering, and presenting a Google-verified X.509 certificate for each trusted device.

Endpoint Verification runs as a Chrome extension on desktops and laptops for users of Mac, Windows, and Linux. An admin can deploy it to the organization's company-owned devices from the Google Workspace Admin Console or members of the organization can install it themselves.

Users installing for the first time should have the latest version, but the following versions of Endpoint Verification are required to support certificate-based access:

  • Endpoint Verification Chrome Extension: 1.0.38 or later
  • Native helper: or later for Mac, or later for Windows, and 20191007 or later for Linux

Creating an access level

You'll need to define an access level that requires certificates when determining access to resources by creating a custom access level in Access Context Manager.

The values you use for access level name, description, user-friendly title, and so on can be whatever make sense for you, but the expression for the custom access level must be:

certificateBindingState(origin, device) == CertificateBindingState.CERT_MATCHES_EXISTING_DEVICE

For example, if you were to use the gcloud CLI to create your custom access level, you could use the following command:

gcloud access-context-manager levels create LEVEL_NAME \
  --title=TITLE \
  --custom-level-spec=FILE \
  --description=DESCRIPTION \

The content of the .yaml file referenced by FILE is simply the custom expression:

expression: "certificateBindingState(origin, device) == CertificateBindingState.CERT_MATCHES_EXISTING_DEVICE"

Applying the access level

Now that an access level has been created, the final administrative step is to enforce its restrictions by applying it.

Enforcing restrictions on administrative access to VMs

You can apply the access level for administrative access to VM instances (through SSH and RDP) with IAP TCP forwarding:

  • For users or groups that are granted the IAP-Secured Tunnel User role, edit the permissions to add a condition.
  • Use the name of the access level you defined earlier (that would be the value for TITLE in the gcloud CLI example) to restrict access by access level.

Enforcing access restrictions to the Google Cloud APIs

You can enforce certificate-based access whenever users attempt to access certain management APIs by creating a VPC Service Controls service perimeter. When you create (or modify a service perimeter, the option to specify an access level for requests from outside the perimeter is required for certificate-based access.

Use the name of the custom access level you created earlier (the value for TITLE in the gcloud CLI example) to include it in your service perimeter.

Enabling user access to protected resources

When certificate-based access restrictions are in effect, your users must enable their own access to protected resources.


Have your users go to the secure Google Cloud console and verify that they can access services that are protected by certificate-based access for VPC Service Controls.

Go to the secure Google Cloud console

When a user attempts to access a service in the Google Cloud console that is protected by certificate-based access and they are not included in the policy, the following error message is displayed:

VPC Service Controls: Request is prohibited by organization's policy. vpcServiceControlsUniqueIdentifier


  1. Have your users install or update the gcloud CLI to ensure they have a version that works with certificate-based access, version 264.0.0 or later.

    Users who already have the gcloud CLI installed can confirm they have version 264.0.0 or later with the command gcloud --version. If needed, they can update their version with the command:

    gcloud components update
  2. Users must run the following command to begin using certificate-based access:

    gcloud config set context_aware/use_client_certificate true
  3. Users can then log in to the gcloud CLI as usual:

    gcloud auth login

    When the previous steps are complete, your users can return to using the gcloud CLI for administrative access to VM instances and for access to the Google Cloud APIs.