Preparation
Pre-deployment checklist for GCP vSensor install, including connectivity, SSH keys, sizing, and required service accounts and roles.
SSH Key Pair
An RSA SSH key pair will need to be created, or reuse an existing pair, for the Sensor to allow an administrator to login to the CLI as the vectra user. These can be generated using any standard tool. Google has some options documented:
The public key will need to be copied for later use during deployment so that it can be assigned to the Sensor. After the Sensor is deployed, you can login to the Sensor CLI via SSH:
You may need to make the key readable to you using a command such as:
chmod 400 vectra.pem
Example login command:
ssh -i <private key path> vectra@SensorHostnameOrIP
Brain and Sensor Communications
A Sensor (or Stream appliance) can pair with any Vectra Brain type. For example, the Brain can be a physical appliance, a Brain deployed in a IaaS cloud, or a Brain deployed in a traditional hypervisor environment on customer premises.
Sensors must be able to reach the Brain over the below ports. It is recommended to enable these ports bidirectionally to aid in troubleshooting.
TCP/443 (HTTPS) - Used for Sensor discovery and initial pairing connection.
TCP/22 (SSH) - Used for Paired Sensor connections.
Additionally, for online pairing (physical Sensors only), both the Sensor and Brain must be able to communicate with:
update2.vectranetworks.com or 54.200.156.238 over TCP/443 (HTTPS)
Please work with your security and networking contacts to ensure that the Sensor will be able to initiate a connection to the Brain. Sensors only communicate with the Vectra Brain and do not need to communicate to Vectra directly. Software updates for the Sensor will come from the Brain.
For full details on all potential firewall requirements in Vectra deployments, please see firewall requirements.
Sensor Sizing
The Vectra Sensor for GCP is currently available in 4 sizes:
VM Type
CPU Cores
Memory
Interfaces
Approximate Throughput
e2-standard-2
2
8 GB
2 (Management and Traffic)
~ 1 Gbps
e2-standard-4
4
16 GB
2 (Management and Traffic)
~ 2 Gbps
e2-standard-16
16
64 GB
2 (Management and Traffic)
~ 5 Gbps
e2-standard-32
32
128 GB
2 (Management and Traffic)
~ 10 Gbps
Information to Gather Before Proceeding With Deployment
Infrastructure Manager Service Account – Used by the GCP Infrastructure Manager to create your resources during initial deployment.
This service account needs the Cloud Infrastructure Manager Agent and Compute Admin roles.
Instructions to create this service account are included in Creating GCP service accounts.
Brain IP or Hostname – IP address or hostname of the Brain for the Sensor to register and pair with.
Vectra Sensors can pair by IP or hostname. Hostname based pairing may be desirable in some failover scenarios. Please refer to the Respond UX deployment guide or Quadrant UX deployment guide for additional information about pairing by IP or hostname.
Registration Token – This token must be copied from the Configuration → Data Sources → Network → Sensors → Sensor Configuration → Sensor Registration and Pairing page of the Brain UI.
The token is valid for 24 hours and can be regenerated on-demand.
A valid registration token must be presented by the Sensor in order to register with the Brain so that the Sensor will become Available for pairing.
Instructions to generate a Sensor registration token are included in the below section titled Cloud Sensor Registration Token
Public SSH Key – The public key you created in the above section.
You may reuse an existing key if you prefer.
Project – The GCP Project ID (not the project name or project number).
This can be seen in the GCP console dashboard for your project.
Region – The GCP region in which to deploy.
Example:
us-east4
Zone – The GCP zone is which to deploy.
Example:
us-east4-a
Size – Size of Sensor VM to deploy.
Options are e2-standard-2, e2-standard-4, e2-standard-16, e2-standard-32
Brain Image – GCP identifier for the Brain image to be used to build the VM.
This will be provided by Vectra.
Management Subnetwork – selfLink of GCP subnet to provision the management (MGT) interface into.
Example syntax:
projects/PROJ/regions/REG/subnetworks/SUBNET
Traffic Subnetwork – selfLink of the subnet to provision the traffic capture interface into.
Example syntax:
projects/PROJ/regions/REG/subnetworks/SUBNET
Traffic Network – selfLink of the VPC network we will be deploying a load balancer into.
Example syntax:
projects/PROJ/global/networks/NETThe template will deploy into this network a load balancer and an instance group containing one instance which is the Vectra Sensor.
Please note:
Traffic and management interfaces must be in separate VPC networks.
VPC packet mirroring requires a load balancer (created automatically by the deployment script) which requires an instance group, but Vectra does NOT support multiple Sensors in the group.
Vectra supports only one Sensor in the instance group.
Changing the autoscale configuration to allow for multiple Sensors in the same group will lead to incorrect parsing of network traffic by the Sensors, which will lead to false and/or missed Detections.
Do NOT change the autoscale configuration.
The instance group in GCP will flag the Sensor as unhealthy.
This does NOT in any way mean that the Sensor is unhealthy.
Sensor health will be determined as usual through Vectra’s tooling.
Cloud Sensor Registration Token
During Sensor deployment a valid Sensor registration token must be presented to the Brain so that the Sensor can become Available to pair. This token can be created in the Vectra UI. It is valid for 24 hours and can be regenerated at any time. Full details will be provided in Pairing GCP vSensors.
Navigate to Configuration → Data Sources → Network → Sensors → Sensor Configuration → Sensor Registration and Pairing.
If you have a valid token, you can Copy it here for later use using the link
Otherwise, click the Generate New Sensor Registration Token link
Upon saving the page a new token will be generated that can be copied
Use this token for Sensor deployment (tokens expire 24 hours after generation)
Retrieving selfLink for GCP Network Objects
The selfLink can be retrieved from the GCP Console GUI by selecting your VPC network, clicking on EQUIVALENT REST and then copying the selflink:
Copy the
projects/…portion from the highlighted area (do not include the quote marks).In our example below the selfLink for the traffic network would be:
projects/vectra-tme-dev/global/networks/tme-sensor-trf
The same basic steps can be used to retrieve the selflink for mangement subnetwork and traffic subnetwork.
selfLinks can also be retrieved via the GCP CLI using the
gcloud compute networks describecommand:Copy the
projects/…part as in the highlighted section below for the network or subnet as required.In our example below the selfLink for the management subnetwork would be:
projects/vectra-tme-dev/regions/us-east4/subnetworks/mgt
Creating GCP Service Accounts
GCP service accounts are required for two parts of the overall deployment process:
Infrastructure Manager Service Account – Used by the GCP Infrastructure Manager to create your resources during the initial Brain image deployment.
This Infrastructure Manager Service Account should typically be different from the service account you use for HostID integration, as HostID service account do not need the Infrastructure Manager Agent or Compute Admin roles which are more privileged.
This service account requires the Cloud Infrastructure Manager Agent and Compute Admin roles.
HostID Integration Service Account - Used by the Brain to query GCP to gather additional information about hosts running in GCP. This information contributes to Vectra’s automated Host identification (Host ID) and adds information to the Host details screen.
The HostID Service Account requires only the Compute Viewer permission.
Please Note:
If your organization is organized in a manner requiring more than one service account for your Vectra GCP deployment, multiple sets of credentials can be added to your Vectra configuration for the HostID integration.
For the HostID integration, if your monitoring needs span multiple projects, Vectra requires a service account per project. Existing service accounts can be re-used, or you may add new ones specific to this use case.
Resources
Basic Steps
After signing into the GCP console, navigate to IAM and Admin → Service Accounts and click + CREATE SERVICE ACCOUNT.
Give the account a name and optionally a description and then click CREATE AND CONTINUE.
In the below example, we are creating a service account for the HostID service account used by the Brain to retrieve artifacts that help with Vectra's automated HostID. When creating other service accounts, choose the appropriate role for the service account you are creating.
Choose a role that has read access to the compute v1 endpoints on GCP API to list zones, instances, and networks and click CONTINUE. The predefined Compute Viewer role provides the required permissions:
Optionally grant users access to the service account and then click DONE.
Now select your newly created service account and navigate to the KEYS tab, click on ADD KEY, and then Create new key.
Select JSON format and click CREATE.
This key will download to your computer when created.
Please note:
Save the key for later use.
On the DETAILS tab for your service account, also make note of the Unique ID for later use.
Infrastructure Manager Service Account
Creating the Infrastructure Manager Service Account
Follow the same basic steps as above but make sure you grant the following roles to this service account:
Cloud Infrastructure Manager Agent
Compute Admin
Under the Principals with Access tab, grant your user the Service Account User role on the service.
Last updated
Was this helpful?