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:
- Deploy Endpoint Verification to devices in your organization.
- Create an access level in Access Context Manager that requires matching device certificates for access.
- Enforce access restrictions by applying the access level through IAP TCP forwarding or a VPC Service Controls service perimeter.
- 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: 0.4.40.0 or later for Mac, 0.4.36.0 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 \ --policy=POLICY_NAME
The content of the .yaml file referenced by
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
gcloudtool 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
gcloudtool to ensure they have a version that works with certificate-based access.
Users who already have the
gcloudtool 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
gcloudtool 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.