VAST on Cloud Requirements for GCP

Introduction

This document assumes the reader is familiar with the VAST platform and GCP Cloud and is intended for cloud architects, DevOps engineers, and infrastructure teams involved in the planning and execution of a VAST on Cloud installation in GCP.

It outlines the prerequisites for deploying and validating VAST on Cloud in GCP, providing guidance on preparing the cloud environment for a successful deployment. This includes configuring the network and setting the required roles/permissions. To keep these documents shorter, we will link other supporting documents where appropriate. T

VAST on Cloud clusters in GCP are created using Polaris, our cloud-based control plane and life cycle management service.

The Polaris service consists of three primary components:

1. Polaris Cloud Service
   A cloud-based control plane that manages configuration, state, and day 2 operations for VAST clusters.

2. vastcloud CLI / SDK
   A command-line interface used to perform cluster lifecycle operations such as create, delete, and list (the focus of this document).

3. Polaris Agent
   A lightweight agent installed on VAST cluster nodes that establishes an outbound, NAT’d SSL connection to the Polaris service. This agent is responsible for securely transmitting telemetry and exchanging tokens required for ongoing management and orchestration.

This guide assumes the Polaris Cloud Service has been subscribed to and a Tenant/User provisioned. If this hasn’t been done, please refer to this guide [link].

Enterprise Governance & Cloud Architecture

Deploying infrastructure into a tightly controlled private subnet requires careful planning. The security, networking, and access configurations detailed in this guide may appear complex, but they reflect standard, industry-accepted design patterns for deploying any enterprise-grade IaaS solution under Zero Trust governance. We have documented the granular IAM permissions, firewall tags, and routing options explicitly so your Cloud Architecture and InfoSec teams can facilitate a secure deployment without compromising corporate security postures.

VAST understands the complexities of operating in regulated or policy-driven environments. Our tools and documentation are built with flexibility in mind, and we are prepared to adapt our deployment process to align with your organization’s specific requirements.

Should any policy-related issues arise, they are typically part of standard governance practices - not blockers. Our team is experienced in collaborating with cloud and security teams to ensure a smooth and compliant deployment.

Required: Dedicated Landing Zone in your GCP Project:

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

IaaS Resources Created by the Installer:

• Compute Resources

  • Allocates - Internal IP Addresses: google_compute_address

  • Resource Policies: google_compute_resource_policy

  • Instance Templates: google_compute_instance_template

  • Instance Group Managers: google_compute_instance_group_manager

  • Health Checks: google_compute_health_check

• Networking

  • Subnetwork Configuration: IP allocation and alias ranges

  • Network Performance: High-bandwidth settings for optimal performance

• Disks

  • Persistent Disks: Boot disk, installation disk, and user data disk

  • Local NVMe SSDs: For high-speed data storage

• Virtual Machines:

  • The VAST cluster on GCP is deployed in an Ebox configuration with a dedicated node for the VMS so we are creating (num_nodes+1) VMs.

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.

Note: VAST does not use Public IPs, create or modify GCP Projects, nor create or modify VPCs and subnets during deployment. These resources must be prepared in advance.

Required APIs:

In a mature Project, most of these will already be enabled, but you should check the list to be sure. In a new Project, none of these will be enabled, and you should use the command below to enable the list of APIs.

• Compute Engine API – Required for creating and managing compute instances, instance groups, and health checks.

  • API: compute.googleapis.com

• Cloud Storage API – Needed for managing Cloud Storage resources, including recovery buckets.

  • API: storage.googleapis.com

• Secret Manager API – We are storing keys and secrets in Google Cloud Secret Manager.

  • API: secretmanager.googleapis.com

• Identity and Access Management (IAM) API – Required to manage IAM roles and permissions.

  • API: iam.googleapis.com

• Cloud Monitoring API – Used for monitoring and logging health checks and VM status.

  • API: monitoring.googleapis.com

• Cloud Logging API – Required for logging related to your instances and other resources.

  • API: logging.googleapis.com

• Cloud Resource Manager API – Used for managing projects, organization policies, and other resources at the project level.

  • API: cloudresourcemanager.googleapis.com

• Cloud Health Checks API – For creating and managing health checks for instances.

  • API: compute.googleapis.com (also required for health checks)

• Cloud Functions API – Required because we are using Functions to manage cleanup for static routes added when VIP pools are created.

  • API: cloudfunctions.googleapis.com

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:

The VAST cluster is installed in a private subnet but does require access to resources outside of the subnet/VPC during the installation.

Enabling access can be done in a few ways depending on your security and governance policies. In many mature cloud environments, access to the services needed is already enabled as a standard part of VPC and subnet configuration, but in a new Project they will need to be enabled.

NOTE: After configuring the network but before attempting to deploy a cluster, you should run vastcloud cluster preflight. (See Appendix B)

Firewall rules:

Required Network Ports (Detailed list)

Network port requirements for the VAST cluster are grouped into three distinct use cases:

• Protocol & Access Ports (Ingress): These well-known IP ports are used for standard storage protocols, REST API access, and SSH management. They must be open for inbound traffic (ingress) from end-users, administrators, and any client applications (such as Spark, Kafka, or Trino) that need to consume cluster resources.

• Internal Cluster Ports (Local Only): These ports are only required for internal communication and orchestration between the cluster nodes. They only require local routing within the subnet and should not be exposed outside the cluster itself.

• Replication Ports (Ingress & Egress): These ports handle data replication and must be open for both inbound and outbound traffic at the cluster level. Crucially, if you are replicating data globally, you must ensure these ports are also explicitly allowed through all intermediate border routers and firewalls bridging your on-premises data center and your cloud network.

Firewall Configuration Best Practices

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 to Restrict Target Scope: Instead of applying firewall rules broadly to an entire VPC, use Network Tags to isolate your rules. VAST clusters are deployed with specific, predefined network tags that cannot be changed after installation.

By configuring your GCP ingress rules to target these specific tags, you ensure that open ports are strictly limited to the VAST infrastructure.

• Apply VAST firewall rules to the following target tag(s): [INSERT_VAST_CLUSTER_TAG_HERE]

2. Restrict Ingress by Source CIDR: In addition to restricting which VMs the rules apply to, you must strictly limit where the inbound traffic is allowed to originate from by defining narrow Source IPv4 ranges:

• Client Subnet CIDRs: Only allow ingress traffic from the specific VPC subnet CIDRs or on-premises networks where your client applications (e.g., Spark, Kafka, Trino) and administrative workstations reside. Avoid using 0.0.0.0/0 unless explicitly required for public-facing replication.

• Required GCP Service CIDRs: Certain internal Google Cloud services (such as Load Balancer Health Checks) must be able to reach the cluster for it to function correctly. The specific Google-managed CIDR blocks required for these services are documented in the [INSERT SECTION NAME/LINK]: section below.

• Incoming Replication Traffic: Enable access for any CIDR blocks being routed from an on-premise Data Center.

VPC:

• Shared/Peered VPCs are supported for client access

Subnet:

VAST Cluster IP Subnet Prerequisites

• CRITICAL CONSTRAINT: Every VAST cluster requires its own dedicated subnet. Clusters cannot share subnets.

• GCP Requirement: The subnet must have "Google Private Access" enabled (see Appendix A for details).

• Standard Recommendation: Provide a /24 private subnet (252 usable IPs) per cluster.

• Minimum IP Calculation: 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

Subnet CIDR Recommendations:

In the case where CIDR blocks are not assigned by the customer’s Network Operations Team.

Use RFC 1918 blocks:

• 10.0.0.0/8(Large)

• 172.16.0.0/12 (Medium - often used for "Lab" or "Dev" environments)

• 192.168.0.0/16 (Small - common in home/small office, high risk of conflict with VPN users)

VIP Pool Addressing

For VAST on Cloud we recommend 2 VIP per CNode - so an 8 node cluster would need a range of 16 sequential addresses.

In GCP, we use Cloud Routing to manage VIP failover. When a Prototol VIP pool is created, a static /32 VPC route is generated via API for each IP address, pointing to the owning CNode. The Replication Pool is allocated from the cluster subnet CIDR.

Avoid subnet overlap: GCP automatically creates routes for every subnet CIDR. A /32 host route cannot exist if its IP address falls within an existing Subnet CIDR. * You must choose a routable IP range that is not defined as a subnet in any VPC.

• If an overlap occurs, the route add API commands will fail, and the VIPs will be unreachable.

Verification:  

If you aren’t sure if you have overlapping CIDR you can run a gcloud command like this to see all of the subnets in the VPC:

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

And then run to see  the routes - you will see a route for every subnet:

gcloud compute routes list

Network - Enabling Outbound Internet 0.0.0.0/0

NAT GW or Equivalent

• Purpose: Enable external access for VMs on private subnets. Because Google services are on public endpoints, they are enabled by a NAT GW as well.

• It is a simple and secure service but often prohibited in environments with strict governance or who route all external traffic through their own routers.

• If you are restricted from using a NAT GW, you will need to enable the Instance Metadata Service and add routes and whitelist the VAST public endpoints for Polaris, Call Home, and Uplink to your Internet Gateways.

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

Private Google Access (PGA)

• Purpose: Let VMs without external IPs reach Google APIs & services (Storage, Pub/Sub, BigQuery, etc.).

• How: Enable Private Google Access on the subnet.

Required GCP End Point CIDRs

If you are using ingress and egress filters in the VPC firewall rules, these are the Google services that need to be allowed:

Network Connectivity – Global Namespace/Replication

To use Global Namespace or snapshot replication, you will need a dedicated link with routing between your Data Center hosting the origin VAST cluster and GCP VPC networks utilizing one of the following:

• Performance POC: Google Cloud Interconnect (Dedicated or Partner) is required for consistent high-throughput replication.

• Functional POC: GCP Cloud VPN (HA VPN recommended) is acceptable for initial testing and lower bandwidth requirements.

• Firewall Exceptions (Replication): Open the following ports on the on-premises firewall and in the GCP firewall rules:

  • TCP 49001: VAST Replication Service.

  • TCP 49002: VAST Replication Service.

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

• MTU Settings: Confirm MTU consistency (typically 1460 or 1500) across the VPN/Interconnect to avoid packet fragmentation, which can significantly degrade replication performance.

Network Connectivity – VAST Internet Gateway Whitelist.

Requesting Quota Increases for Z3 Instances and Local SSD

If you plan to deploy a cluster with more than three nodes or operate multiple clusters simultaneously, you must request a quota increase in advance.

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 your 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. Your list may be different based on the regions your Project has been authorized to access.

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

+------------------------+------------------------+
|          ZONE          |          NAME          |
+------------------------+------------------------+
| northamerica-south1-b  | z3-highmem-88-highlssd |
| us-central1-a          | z3-highmem-88-highlssd |
| us-central1-c          | z3-highmem-88-highlssd |
| us-central1-f          | z3-highmem-88-highlssd |
| us-central1-d          | z3-highmem-88-highlssd |
| us-west1-a             | z3-highmem-88-highlssd |
| us-west1-b             | z3-highmem-88-highlssd |
| us-west1-c             | z3-highmem-88-highlssd |
| us-east1-b             | z3-highmem-88-highlssd |
| us-east1-c             | z3-highmem-88-highlssd |
| us-east1-d             | z3-highmem-88-highlssd |
| us-east4-a             | z3-highmem-88-highlssd |
| us-east4-b             | z3-highmem-88-highlssd |
| us-east4-c             | z3-highmem-88-highlssd |
| us-east7-b             | z3-highmem-88-highlssd |
| us-east5-c             | z3-highmem-88-highlssd |
| us-east5-b             | z3-highmem-88-highlssd |
| us-east5-a             | z3-highmem-88-highlssd |
| us-south1-c            | z3-highmem-88-highlssd |
| us-south1-a            | z3-highmem-88-highlssd |
| asia-northeast1-a      | z3-highmem-88-highlssd |
| asia-northeast1-b      | z3-highmem-88-highlssd |
| asia-northeast1-c      | z3-highmem-88-highlssd |
| asia-southeast1-a      | z3-highmem-88-highlssd |
| asia-southeast1-b      | z3-highmem-88-highlssd |
| asia-southeast1-c      | z3-highmem-88-highlssd |
| asia-south1-b          | z3-highmem-88-highlssd |
| asia-south1-c          | z3-highmem-88-highlssd |
| australia-southeast1-c | z3-highmem-88-highlssd |
| australia-southeast1-b | z3-highmem-88-highlssd |
| europe-west1-b         | z3-highmem-88-highlssd |
| europe-west1-c         | z3-highmem-88-highlssd |
| europe-west1-d         | z3-highmem-88-highlssd |
| europe-west2-a         | z3-highmem-88-highlssd |
| europe-west2-b         | z3-highmem-88-highlssd |
| europe-west2-c         | z3-highmem-88-highlssd |
| europe-west3-c         | z3-highmem-88-highlssd |
| europe-west3-a         | z3-highmem-88-highlssd |
| europe-west4-c         | z3-highmem-88-highlssd |
| europe-west4-b         | z3-highmem-88-highlssd |
| europe-west4-a         | z3-highmem-88-highlssd |
| europe-north2-a        | z3-highmem-88-highlssd |
| europe-north2-b        | z3-highmem-88-highlssd |
+------------------------+------------------------+

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 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:

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 apprprisae 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,

Before you begin – replace these placeholders:

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, 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 HowTo 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.