Securing resources with certificate-based access

Certificate-based access works to protect access to many Google resources by identifying devices through their X.509 certificates. This feature builds on top of the existing context-aware access features of BeyondCorp Enterprise (Endpoint Verification, Access Context Manager, VPC Service Controls, and Identity-Aware Proxy TCP forwarding) and ensures that only those users on a trusted device with a Google-generated certificate are able to have administrative access through IAP TCP forwarding, or access the Google Cloud APIs using the Google Cloud Console or the Google Cloud Client Library for Go.

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.

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 additionaly 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 tool 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 tool 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 tool example) to include it in your service perimeter.

Enabling user access to protected resources

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

  • Have your users install or update the gcloud tool to ensure they have a version that works with certificate-based access.

    Users who already have the gcloud tool 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
  • Users must run the following command to begin using certificate-based access:

    gcloud config set context_aware/use_client_certificate true
  • They can then log in to the gcloud tool as usual:

    gcloud auth login

Once those steps are complete, your users can return to using the gcloud tool for administrative access to VM instances and for access to the Google Cloud APIs.