VAST on Cloud Requirements for GCP

Introduction

Required: Dedicated Landing Zone in your GCP Project:

Dedicated Landing Zone in your GCP Organization/Project - IaaS Resources Required for VAST Cluster:

Required Resources in the Target GCP Project

Before deploying the VAST on Cloud Platform, the following resources must already be provisioned within the target GCP Project.

Required APIs:

These APIs authorize the installer to provision compute instances, configure VPC routing and health checks, assign IAM roles, and manage secret keys for the cluster.

Enable them using the gcloud SDK:

PROJECT_ID="your-project-id"
gcloud services enable \
  compute.googleapis.com \
  storage.googleapis.com \
  iam.googleapis.com \
  cloudresourcemanager.googleapis.com \
  servicenetworking.googleapis.com \
  cloudfunctions.googleapis.com \
  artifactregistry.googleapis.com \
  cloudbuild.googleapis.com \
  networkmanagement.googleapis.com \
  networksecurity.googleapis.com \
  monitoring.googleapis.com \
  logging.googleapis.com \
  secretmanager.googleapis.com \
  --project $PROJECT_ID

Networking:

While the VAST cluster is installed in a private subnet, it requires outbound routing to Google APIs and external Polaris services during installation and operation.

Please enable outbound access using one of the following methods based on your corporate governance:

Firewall rules:

Required Network Ports (Detailed list)

Firewall Configuration Limit access to your cluster by adhering to the principle of least privilege:

While detailed instructions for configuring firewall rules on Google Cloud Platform (GCP) are beyond the scope of this document, we strongly recommend adhering to the principle of least privilege when applying firewall rules to your VAST cluster.

1. Use Network Tags: Apply VAST firewall rules exclusively to the following predefined VAST cluster network tag to restrict access:.

• voc-internal

2. Restrict Ingress by Source CIDR: Strictly limit where inbound traffic is allowed to originate from by defining narrow Source IPv4 ranges:

• Client Subnet CIDRs: Allow ingress only from the specific VPC subnets or on-premises networks hosting your client applications and workstations.

• Required GCP Service CIDRs: Allow ingress from the Google-managed CIDR blocks required for Load Balancer Health Checks (detailed in the section below).

• Incoming Replication Traffic: Allow access from any on-premises Data Center CIDR blocks routing replication traffic.

VPC and Subnet Requirements:

VPC Configuration: Use custom VPC. Shared/Peered VPCs are supported

Subnet:

VAST Cluster IP Subnet Prerequisites

• Dedicated Subnet: Provision a dedicated private subnet for each VAST cluster - recommended.

• Google Private Access: Enable "Google Private Access" on the subnet (see Appendix A).

• Subnet Sizing: Provide a /24 subnet per cluster.

• Minimum Subnet Sizing: If a /24 is not permitted, calculate the absolute minimum usable IPs required using N (Total Nodes) and V (VIPs per Node):

  • Total = N + 4 + (N * V)  (GCP requires fewer primary IPs because Protocol VIPs use a separate routing CIDR).

  • Minimum allowable subnet mask for single node - /26

VIP Pool Addressing

VIP Pool Sizing: Allocate 2 sequential VIPs per CNode (e.g., an 8-node cluster requires a range of 16 sequential addresses).

Replication VIPs: The Replication VIP pool is allocated directly from the cluster subnet CIDR during installation.

Protocol VIPs (Critical Constraint): Allocate the Protocol VIP pool from a routable IP range that does not overlap with any existing subnet in your VPC.

Verification:  

To view your VPC subnets and routes to ensure Protocol VIP range does not overlap, use the following gcloud commands:

gcloud compute networks subnets list --filter="network:YOUR_VPC_NAME"

gcloud compute routes list

Enabling Outbound Access

Routing & DNS

Standard Routing: Use a NAT Gateway (or equivalent) for outbound internet access.

Restricted Routing: If NAT Gateways are prohibited by your governance policies, enable the Instance Metadata Service, add routes, and whitelist the VAST public endpoints (Polaris, Call Home, and Uplink) on your internal Internet Gateways.

DNS: VAST cluster nodes use Google Cloud DNS for name resolution.

Private Google Access (PGA): Ensure PGA is enabled on the cluster subnet.

Required GCP End Point CIDRs: If you are using ingress and egress filters in your VPC firewall rules, you must allow the following Google services

Global Namespace/Replication

For VAST Global Namespace or snapshot replication, establish a dedicated routing link between your on-premises Data Center and the GCP VPC using one of the following methods:

• High-Throughput: Google Cloud Interconnect (Dedicated or Partner).

• Testing / Low-Bandwidth: GCP Cloud VPN (HA VPN recommended).

Replication Configuration Requirements

• Firewall Ports: Open TCP 49001 and TCP 49002 (VAST Replication Service) on both your on-premises firewall and GCP firewall rules.

• Routing: Verify bidirectional routing between your on-premises storage nodes and the GCP Subnet CIDR.

• MTU Settings: Confirm MTU consistency (typically 1460 or 1500) across the VPN/Interconnect.

VAST External Services Whitelist.

To enable cluster installation, Polaris management, and Call Home telemetry, add the following Fully Qualified Domain Names (FQDNs) to your outbound firewall allowlist:

▼ Expand to view required FQDNs and Ports

Requesting Quota Increases for Z3 Instances and Local SSD

Important Planning Note: Quota approvals require manual review by Google Cloud support and may take several business days. Do not wait until the day of deployment to submit these requests.

You will need to request increases for two specific quotas in your target region:

1. Z3 vCPUs (vm_family=Z3)

2. Local SSD per VM (local_ssd_total_storage_per_vm_family)

Calculating the required quota

Each z3-highmem-88 instance requires 88 vCPUs and 36 TB (36,000 GB) of Local SSD. We highly recommend requesting enough quota to support multiple clusters to avoid deployment delays later.

Formula:

• vCPU: (Total Nodes) × 88

• Local SSD: (Total Nodes) × 36 TB

Examples:

• 8-Node Cluster: Requires 704 vCPUs and 288 TB of Local SSD.

• 11-Node Cluster: Requires 968 vCPUs and 396 TB of Local SSD.

• Recommended Request (Buffer for multiple clusters): Request 1,500 vCPUs and 1,000 TB (1,000,000 GB) of Local SSD.

How to Request (Choose CLI or Console)

Historically, quota requests could only be submitted via the GCP Console. However, Google now supports quota management via gcloud alpha commands, making automation possible.

Method A: Using the gcloud CLI (Recommended)

You can request these increases directly from your terminal. Ensure you update the PROJECT_ID and REGION variables for your environment.

Note: GCP API metrics for Local SSD are calculated in Gigabytes (GB). Therefore, requesting 1,000 TB requires an input of 1,000,000.

# Set your environment variables
export PROJECT_ID="your-project-id-here"
export REGION="us-central1"

# Request 1,500 vCPUs for the Z3 Family
gcloud alpha quotas preferences create \
  --project=$PROJECT_ID \
  --service=compute.googleapis.com \
  --metric=compute.googleapis.com/cpus_per_vm_family \
  --dimensions=vm_family=Z3,location=$REGION \
  --preferred-value=1500

# Request 1,000 TB (1,000,000 GB) of Local SSD for the Z3 Family
gcloud alpha quotas preferences create \
  --project=$PROJECT_ID \
  --service=compute.googleapis.com \
  --metric=compute.googleapis.com/local_ssd_total_storage_per_vm_family \
  --dimensions=vm_family=Z3,location=$REGION \
  --preferred-value=1000000

Method B: Using the Google Cloud Console

If you prefer the graphical interface, follow these steps:

1. Navigate to Quotas: Go to IAM & Admin → Quotas & System Limits.

2. Filter the List: Use the search bar to find Local SSD per VM and CPUs per VM family.

3. Locate your Region: Find the quota line for the region where your cluster will run (e.g., us-central1).

4. Edit Quota: Click the three vertical dots on the right side of the row and select Edit Quota.

5. Enter Details: * Input your calculated values (e.g., 1000000 for Local SSD GB, 1500 for vCPUs).

   • In the description field, provide a justification, such as: "Required for testing and deploying a multi-node storage cluster."

6. Submit: Click Next to proceed, review your request, and click Submit Request.

Z3 Instance Regional Availability

Use this command to find regions with the z3-highmem-88-highlssd. Your list may differ based on the regions your Project is authorized to access.

gcloud compute machine-types list --filter="name:z3-highmem-88-highlssd" --format="table[box](zone, name)"

IAM Authentication & Access Models

To deploy a VAST Data cluster in GCP using our Polaris deployment engine, specific administrative and resource-level permissions are required within your GCP Project. These permissions authorize the user account utilized by the vastcloud utility to execute Terraform to cleanly spin up, orchestrate, and dismantle the VAST Data Cluster infrastructure on demand. The vastcloud CLI includes a built-in validation mechanism to verify your security settings before provisioning infrastructure. It is highly recommended to execute the following command in your terminal before attempting a deployment to validate your chosen option:

The vastcloud CLI includes a built-in validation mechanism to verify your active security posture before provisioning infrastructure. It is highly recommended to execute the following command in your terminal before attempting a deployment to validate your chosen option:

vastcloud cluster --check-permissions

To accommodate different enterprise compliance frameworks, select one of the three permission models below to configure the GCP Identity (User or Role) executing the deployment.

Option 1: Project Owner / Editor (Easiest, but least secure)

The easiest way to ensure vastcluster create runs without permission errors is to grant the Service Account both the Owner and Editor roles at the Project level.’

⚠️ Security Warning: While it may be appropriate for POCs in fenced Projects, this configuration breaks the principle of least privilege. It grants unrestricted, destructive capabilities across all GCP services within the target Project and should never be used in production environments.

Option 2: Predefined GCP Roles (Balanced)

If you prefer not to manage highly fine-grained permissions, you can assign the following predefined Google Cloud roles to the Service Account running Terraform.

• roles/iam.securityAdmin: Allows creating and binding IAM roles (Note: highly privileged).

• roles/iam.roleAdmin: Allows creating and managing custom roles.

• roles/iam.serviceAccountAdmin: Allows creating and managing service accounts.

• roles/resourcemanager.projectIamAdmin: Manages IAM policy bindings at the project level.

• roles/compute.networkAdmin: (Optional) Required if your deployment creates compute-related networking roles.

• roles/secretmanager.secretAccessor: Required if secret access is validated or tested during deployment.

Option 3: Custom Role / Least Privilege

For strict enterprise compliance, a dedicated Custom IAM Policy should be compiled containing only the fine-grained micro-permissions required by the underlying Terraform state machine.

To satisfy corporate least-privilege standards, this configuration implements a strict Enterprise Security Guardrail. The attached custom policy heavily restricts identity mutation using path-scoped constraints - locking IAM, Policy, and Instance Profile creation exclusively to the /voc/* path namespace. This guarantees that the automation framework can create, modify, and pass the temporary lab runner roles it needs without the ability to touch, view, or alter any existing corporate production fabrics or infrastructure identities.

(Note: The full detailed micro-permission YAML mapping for this custom policy can be found in Appendix A for reference by your DevSecOps / Cloud Security team).

Appendix A: Detailed IAM Policy (YAML Format)

This custom role grants all least privilege permissions needed to create, manage, and delete VastCloud clusters. Copy this YAML, replace the placeholder values,

title: VastCloudClusterCreation
description: All permissions needed to create, manage, and delete VastCloud clusters.
stage: GA
includedPermissions:
  # Resource Manager
  - resourcemanager.projects.get
  - resourcemanager.projects.getIamPolicy
  - resourcemanager.projects.setIamPolicy

  # Compute Engine -- Read
  - compute.regions.list
  - compute.zones.list
  - compute.networks.get
  - compute.networks.list
  - compute.subnetworks.get
  - compute.subnetworks.list
  - compute.subnetworks.use
  - compute.images.get
  - compute.images.useReadOnly
  - compute.instances.get
  - compute.instances.list
  - compute.instanceTemplates.get
  - compute.instanceTemplates.list
  - compute.instanceTemplates.useReadOnly
  - compute.instanceGroupManagers.get
  - compute.instanceGroupManagers.list
  - compute.instanceGroups.get
  - compute.instanceGroups.list
  - compute.healthChecks.get
  - compute.healthChecks.list
  - compute.healthChecks.use
  - compute.regionHealthChecks.list
  - compute.disks.get
  - compute.disks.list
  - compute.addresses.get
  - compute.addresses.list
  - compute.globalAddresses.list
  - compute.routes.get
  - compute.routes.list
  - compute.resourcePolicies.get
  - compute.zoneOperations.get
  - compute.zoneOperations.list
  - compute.globalOperations.get
  - compute.regionOperations.get

  # Compute Engine -- Write
  - compute.instances.create
  - compute.instances.delete
  - compute.instances.setLabels
  - compute.instances.setMetadata
  - compute.instances.setTags
  - compute.instances.updateNetworkInterface
  - compute.instances.getSerialPortOutput
  - compute.instanceTemplates.create
  - compute.instanceTemplates.delete
  - compute.instanceGroupManagers.create
  - compute.instanceGroupManagers.delete
  - compute.instanceGroupManagers.update
  - compute.instanceGroups.create
  - compute.instanceGroups.delete
  - compute.disks.create
  - compute.disks.delete
  - compute.disks.setLabels
  - compute.healthChecks.create
  - compute.healthChecks.delete
  - compute.addresses.createInternal
  - compute.addresses.deleteInternal
  - compute.addresses.useInternal
  - compute.addresses.setLabels
  - compute.routes.create
  - compute.routes.delete
  - compute.networks.updatePolicy
  - compute.resourcePolicies.create
  - compute.resourcePolicies.delete
  - compute.resourcePolicies.use

  # Cloud Storage
  - storage.buckets.create
  - storage.buckets.delete
  - storage.buckets.get
  - storage.buckets.list
  - storage.buckets.update
  - storage.objects.create
  - storage.objects.delete
  - storage.objects.get
  - storage.objects.list
  - storage.hmacKeys.create
  - storage.hmacKeys.delete
  - storage.hmacKeys.get

  # IAM
  - iam.serviceAccounts.create
  - iam.serviceAccounts.delete
  - iam.serviceAccounts.get
  - iam.serviceAccounts.actAs
  - iam.roles.create
  - iam.roles.delete
  - iam.roles.get
  - iam.roles.undelete
  - iam.roles.update
  - iam.roles.list

  # Secret Manager
  - secretmanager.secrets.create
  - secretmanager.secrets.delete
  - secretmanager.secrets.get
  - secretmanager.secrets.list
  - secretmanager.versions.add
  - secretmanager.versions.access
  - secretmanager.versions.get
  - secretmanager.versions.destroy
  - secretmanager.versions.enable

  # Cloud Functions (VoC)
  - cloudfunctions.functions.create
  - cloudfunctions.functions.delete
  - cloudfunctions.functions.get
  - cloudfunctions.functions.getIamPolicy
  - cloudfunctions.functions.setIamPolicy
  - cloudfunctions.operations.get

  # Cloud Logging
  - logging.logEntries.list
  - logging.privateLogEntries.list
  - logging.views.access

  # Artifact Registry (optional -- Polaris metadata)
  - artifactregistry.repositories.downloadArtifacts

Appendix B: Run the Pre-Flight Checker.

vastcloud cluster preflight is a single interactive wizard that validates Polaris login, cloud credentials, looks up the Polaris deployment, checks IAM permissions, required tools, runs a Terraform network pre-checker, and optional resource-name conflict checks before you run cluster create.

For a complete run, you will need to have a user in a Polaris tenant and be authenticated to the cloud you are going to deploy in. It can be run without being authenticated to the Polaris service, but several checks will fail; however, the core cloud checks for IAM permissions, quotas, and network configurations will run and give valid feedback. So if you are still waiting for your Polaris user login, you can still download the vastcloud binary and run the preflight checker tests with the caveat that some phases will fail.

For a complete How-To for GCP, please see this document.

Appendix C: GCP CIDR Range Quick Reference

The table below contains all GCP services that have unique reserved CIDR ranges associated with them. For additional information on the service and how to connect, see the corresponding section that can be found further on in the blog. Additionally, a complete list of all GCP public CIDR ranges split out by regions can be found here.