# Preparation ## 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: * [Creating an SSH key](https://cloud.google.com/compute/docs/instances/adding-removing-ssh-keys?_ga=2.189872046.-405308179.1628802162#createsshkeys) 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 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](https://docs.vectra.ai/deployment/getting-started/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](#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](https://docs.vectra.ai/deployment/getting-started/respond-ux-deployment) or [Quadrant UX deployment guide](https://docs.vectra.ai/deployment/getting-started/quadrant-ux-deployment) 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](#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/NET` * The template will deploy into this network a load balancer and an instance group containing one instance which is the Vectra Sensor. {% hint style="info" %} **Please note:** * Traffic and management interfaces must be in separate VPC networks. * [GCP requires that multiple interfaces on the same VM be in different VPC networks](https://cloud.google.com/vpc/docs/create-use-multiple-interfaces). * 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. {% endhint %} ### 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](https://docs.vectra.ai/deployment/ndr-virtual-cloud-appliances/gcp-vsensor/pairing-gcp-vsensors). * Navigate to *Configuration → Data Sources → Network → Sensors → Sensor Configuration → Sensor Registration and Pairing.* ![](https://4227135129-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHJ1ltuWFvsArFWtevnRn%2Fuploads%2Fgit-blob-ccc0169bc609943d644b0f30435bc1d66a65c9e3%2Fgcp-vsensor-preparation-1.png?alt=media) * 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. ![](https://4227135129-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHJ1ltuWFvsArFWtevnRn%2Fuploads%2Fgit-blob-207133e2fc84b83217979cce231bda6511c8bf1d%2Fgcp-vsensor-preparation-2.png?alt=media) * selfLinks can also be retrieved via the GCP CLI using the `gcloud compute networks describe` command: * 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` ``` ❯ gcloud compute networks describe tme-sensor-mgt autoCreateSubnetworks: false creationTimestamp: '2021-08-24T12:28:04.908-07:00' description: '' id: '579626880853407403' kind: compute#network mtu: 1460 name: tme-sensor-mgt . . . . REMOVED SOME OUTPUT FOR DISPLAY PURPOSES . . . routingConfig: routingMode: REGIONAL selfLink: https://www.googleapis.com/compute/v1/projects/vectra-tme-dev/global/networks/tme-sensor-mgt subnetworks: - https://www.googleapis.com/compute/v1/projects/vectra-tme-dev/regions/us-east4/subnetworks/mgt x_gcloud_bgp_routing_mode: REGIONAL ``` ## 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. {% hint style="info" %} 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. {% endhint %} * **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. {% hint style="info" %} The **HostID Service Account** requires only the **Compute Viewer** permission. {% endhint %} {% hint style="info" %} **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. {% endhint %} ### **Resources** * [Creating and Managing GCP Service Accounts](https://cloud.google.com/iam/docs/creating-managing-service-accounts) * [Understanding GCP Roles - Also details predefined roles](https://cloud.google.com/iam/docs/understanding-roles) ### **Basic Steps** * After signing into the GCP console, navigate to *IAM and Admin → Service Accounts* and click **+ CREATE SERVICE ACCOUNT.** ![](https://4227135129-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHJ1ltuWFvsArFWtevnRn%2Fuploads%2Fgit-blob-84e3939d9f0120218de6a05944089511cc33cec1%2Fgcp-hostid-extraction-2.png?alt=media) * Give the account a name and optionally a description and then click **CREATE AND CONTINUE.** ![](https://4227135129-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHJ1ltuWFvsArFWtevnRn%2Fuploads%2Fgit-blob-a0c21e16e7c22e2e70d16543392a7eda5237b232%2Fgcp-hostid-extraction-3.png?alt=media) {% hint style="info" %} 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. {% endhint %} * 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: ![](https://4227135129-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHJ1ltuWFvsArFWtevnRn%2Fuploads%2Fgit-blob-2a47cecf937a5c9da75ec5c9adc0e800bdd9fb36%2Fgcp-hostid-extraction-4.png?alt=media) * Optionally grant users access to the service account and then click **DONE.** ![](https://4227135129-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHJ1ltuWFvsArFWtevnRn%2Fuploads%2Fgit-blob-90fc46baebd744657c1d15c12f89095defc19bd6%2Fgcp-hostid-extraction-5.png?alt=media) * Now select your newly created service account and navigate to the **KEYS** tab, click on **ADD KEY**, and then **Create new key.** ![](https://4227135129-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHJ1ltuWFvsArFWtevnRn%2Fuploads%2Fgit-blob-fb7075c11aa8ea9b164c701c23f8c621b56f0c5a%2Fgcp-hostid-extraction-6.png?alt=media) * Select **JSON** format and click **CREATE.** ![](https://4227135129-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FHJ1ltuWFvsArFWtevnRn%2Fuploads%2Fgit-blob-7e406672ddbe4a478bcc73392f69bda9fa85f954%2Fgcp-hostid-extraction-7.png?alt=media) * This key will download to your computer when created. {% hint style="info" %} **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. {% endhint %} ### Infrastructure Manager Service Account #### Creating the Infrastructure Manager Service Account * Follow the same [basic steps](#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.