Set up security best practices

This page provides an overview of security best practices recommended to increase the security and data protection posture around your Cloud Workstations. This list is not a comprehensive checklist ensuring security guarantees, or a replacement to your existing security postures.

The goal is to provide you with a guide to the security best practices made possible by Cloud Workstations. Add these recommendations to your portfolio of security solutions when applicable, as part of the efforts to build a layered security approach. A layered security approach is one of the core security principles for running secure and compliant services on Google Cloud.

Background

The Cloud Workstations service provides predefined base images for use with the service. The service rebuilds and republishes these images weekly to help ensure that the bundled software includes the latest security patches. In addition, the service uses a default running timeout value on your workstation configuration to help make sure that workstations are automatically updated and that unpatched images don't remain live.

However, Google Cloud does not own all the packages bundled into these images. Package managers might prioritize updates differently depending on how a bug or common vulnerabilities and exposures (CVE) impacts their product. If a product uses only a portion of a library, it might not be impacted by discoveries in other portions of the library. Because of this, although CVE findings from vulnerability scans of our images exist, Cloud Workstations is still able to provide a secure product.

Cloud Workstations can do this because it provides an authentication and authorization system that helps ensure that only the designated developer can access their workstation. As with any development environment, developers should apply best practices when using their workstation. To be as secure as possible, run only trusted code, operate only on trusted input, and access only trusted domains. Additionally, you are discouraged from using workstations to host production servers, or sharing a single workstation with multiple developers.

If you want to have more control over the security of your organization's workstation images, you can also create your own customized container images.

Restrict public network access

Disable public IP addresses on your workstations using your workstation configuration and configure firewall rules limiting access to public internet destinations not required for day-to-day work from within Cloud Workstations. If you disable public IP addresses, you must set up Private Google Access or Cloud NAT on your network. If you use Private Google Access and you use private.googleapis.com or restricted.googleapis.com for Artifact Registry (or Container Registry), make sure that you set up DNS records for domains *.pkg.dev and *.gcr.io.

Caution: Container Registry is deprecated and scheduled for shutdown. Organizations that haven't used Container Registry prior to January 8, 2024 have new gcr.io repositories hosted on Artifact Registry by default. Effective May 15, 2024, Google Cloud projects without previous usage of Container Registry will only support hosting and managing images for the gcr.io domain in Artifact Registry.

Container Registry is scheduled for shutdown on March 18, 2025. For details on the deprecation, see Container Registry deprecation.

Restrict direct SSH access

Make sure that you restrict direct SSH access to VMs in the project hosting your Cloud Workstations, so that access is only possible through the Cloud Workstations gateway, where Identity and Access Management (IAM)) policies are enforced and VPC Flow Logs can be enabled.

To disable direct SSH access to VM, run the following Google Cloud CLI command:

    gcloud workstations configs update CONFIG \
        --cluster=CLUSTER \
        --region=REGION \
        --project=PROJECT \
        --disable-ssh-to-vm

Limit access to sensitive resources

Set up a VPC Service Controls service perimeter to limit access to sensitive resources from your workstations, preventing source code and data exfiltration.

Follow the principle of least privilege

Follow the principle of least privilege for permissions and resource allocation.

IAM permissions

Use the default Identity and Access Management configuration, limiting workstation access to a single developer. This helps ensure that each developer is using a unique workstation instance with a distinct underlying VM, increasing the environment isolation. Cloud Workstations code editors and applications run inside a container running in privileged mode and with root access, for increased developer flexibility. This provides a unique workstation per developer and helps ensure that even if a user escapes from this container, they'd still be inside their VM, unable to gain access to any additional external resources.

Set up IAM permissions limiting non-admin access to modify workstation configurations and container images on Artifact Registry.

Additionally, Google recommends that you set up IAM permissions limiting non-admin access to any of the underlying Compute Engine resources in the project hosting your Cloud Workstations.

For more information, see using IAM securely.

Cloud KMS permissions

To better support the principle of least privilege, we recommend that you keep Cloud KMS resources and Cloud Workstations resources in separate Google Cloud projects. Create your Cloud KMS key project without an owner at the project level, and designate an Organization Admin granted at the organization-level. Unlike an owner, an Organization Admin can't manage or use keys directly. They are restricted to setting IAM policies, which restrict who can manage and use keys.

This is also referred to as separation of duties, which is the concept of making sure that one individual does not have all necessary permissions to be able to complete a malicious action. For more information, see separation of duties.

Enforce automatic image updates and patches

Make sure that your workstations are using the latest version of the Cloud Workstations base images, which contains the latest security patches and fixes. The running timeout value on your workstation configuration helps ensure that workstations created with this configuration automatically update on the next session, to match the latest version of the container image defined in the workstation configuration.

• If your organization uses one of the Cloud Workstations base images, the workstation automatically picks up any updates to the workstation configuration the next time the workstation is shutdown and restarted. Setting runningTimeout, or using the default, helps ensure that these workstations are shutdown.
• If your organization uses a custom image, be sure that you rebuild the image regularly. We recommend that you Create a secure image pipeline as described in the following section.

Create a secure image pipeline for custom images

You're responsible for maintaining and updating custom packages and dependencies added on custom images.

If you're creating custom images, we recommend the following:

• Help secure your image pipeline by automatically rebuilding these images when the Cloud Workstations base image is updated.

• Run a container scanning tool such as Artifact Analysis to inspect any additional dependencies you added.

• Schedule builds to rebuild images weekly, or learn how to automate container image rebuilds.

Set up VPC Flow Logs

When you create a workstation cluster, Cloud Workstations associates the cluster with a particular subnet and all workstations are placed in that subnet. To enable VPC Flow Logs, make sure that you turn on logging for that subnet. For more information, see Enable VPC Flow Logs for an existing subnet.