Cloud Exchange FAQs

Review these sections for Cloud Exchange FAQ information.

General

What versions are supported in Cloud Exchange?

The following versions of Cloud Exchange are supported:

CE 4.2.x
CE 5.0.0
CE 5.0.1 and above

Can I add a proxy directly from the UI?

Yes, you can. However, after adding the proxy in the UI, you need to run the ./setup script.

Can the plugin version and Cloud Exchange version be reverted to a previous version?

No, Cloud Exchange does not support reverting to a previous version.

What is the OS update procedure and how are updates maintained?

Starting from v5.0.1, Cloud Exchange is built on top of an NS PSIRT-hardened/reviewed Ubuntu OS and therefore does not receive notifications for OS updates. The underlying OS for Cloud Exchange as a VM will be updated to the latest version, hardened, and reviewed by NS PSIRT, with every new release.

What data does Cloud Exchange store on the host machine?

For Log Shipper: Cloud Exchange does not store any data permanently. It pulls logs from Netskope tenants, transforms them, and then shares them with the SIEM platform. Data is stored temporarily on the machine’s disk only between pulling and sharing.
For Ticket Orchestrator: Cloud Exchange stores alerts in the database.
For Threat Exchange: Cloud Exchange stores indicators in the database.
For User Risk Exchange: Cloud Exchange stores user and host risk scores.
For Application Risk Exchange: Cloud Exchange stores the application risk score.

Installation

What should be installed in the Analytics Token and JWT Token in K8S installation? What is this for?

The JWT Token secures communication between the UI and Core containers, while the Analytics Token is used to exchange analytics results with Netskope. The JWT Token is added during Cloud Exchange configuration, and the Analytics Token is hardcoded into the docker-compose.yml file.

What is AVX, and is it necessary for Cloud Exchange?

AVX stands for Advanced Vector Extensions. Yes, AVX support is required for your machine when deploying Cloud Exchange.

What are the steps for Proxy configuration in Cloud Exchange if it wasn’t configured during installation?

Follow these steps to configure the proxy:

Stop the running Cloud Exchange containers.
Execute the setup script with the command: sudo python3 ./setup.
When prompted during script execution, enter your proxy details (proxy server and port). Complete the rest of the setup as during installation.
Validate the proxy in the .env file by running: cat .env.
- Check the variables CORE_HTTP_PROXY and CORE_HTTPS_PROXY for proxy details.
Start the Cloud Exchange container using: sudo ./start.

What is the supported architecture for machines to install Cloud Exchange?

Cloud Exchange v4.0.x and older versions support the x86 architecture. Machines with x86 architecture and AVX support are recommended. Further details and system requirements can be found in the Cloud Exchange System Requirements article.

What are the steps to edit/update proxy details in Cloud Exchange?

You can update proxy details by executing the setup script on the machine where CE is deployed. You can also update proxy details from the Cloud Exchange UI, but make sure to run the setup script afterward to apply the changes on the machine.

What are the steps to regenerate self-signed certificates for Cloud Exchange?

Follow these steps to regenerate self-signed certificates:

Go to the ta_cloud_exchange directory (or /opt/cloudexchange/cloudexchange for CE as a VM).
Stop Cloud Exchange services: sudo ./stop.
Go to the data/ssl_certs directory.
Remove the old certificates with: rm -rf cte_cert.crt cte_cert_key.key.
Return to the ta_cloud_exchange directory and run the setup script: sudo python3 ./setup.
Start Cloud Exchange services: sudo ./start.

Why does Cloud Exchange use user ID 1001?

Cloud Exchange uses user ID 1001 for its internal worker processes to enhance security. This ensures the least privilege, improved resource management, and a more secure containerized environment. This process is automatic, so manual intervention is not required.

What should be done when the REST API v2 token expires, and how can I tell when it is expired?

You will see this warning in Cloud Exchange when the v2 token expires.

Follow these steps to change the expiration and reissue the v2 token:

Log in to Netskope Tenant and select Settings.
Go to Tools and then REST API v2.
Find your v2 token used in Cloud Exchange, click the three dots, and select Change Expiration. Set the expiration as desired.
Reissue the token by selecting Reissue from the same menu.
Update the new token in Cloud Exchange under Settings > Netskope Tenants.

HA Deployment/General

Does the HA feature work for both VM and non-VM Cloud Exchange deployments?

Yes, High Availability (HA) works with standalone deployments on Linux machines running Ubuntu or RHEL, as well as with Cloud Exchange deployed as a virtual machine.

Is Cloud Exchange High Availability supported with three Cloud Exchange instances running in different data centers, or do they all need to be in the same data center?

Cloud Exchange HA supports instances running across multiple data centers.

High Availability (HA) Setup Guide for Cloud Exchange on Linux Nodes with Azure Blob Storage

This section explains how to configure a High Availability (HA) environment for Cloud Exchange on Linux nodes using Azure Blob Storage as the NFS (Network File System) for shared storage.

Cloud Exchange System Requirements are present at:

https://docs.netskope.com/en/cloud-exchange-system-requirements/

https://docs.netskope.com/en/cloud-exchange-high-availability-1/#prerequisite-for-ha-deployment-on-linux

Prerequisites

System Requirements for HA Nodes

16 CPU CORES (Compute Intensive F16s series)

32 GB RAM

120 GB Available free disk space where CE will be installed; for example: /home/root/

20 GB free space at /var/lib for container storages.

NFS Setup with Azure Blob Storage

Go to: https://learn.microsoft.com/en-us/azure/storage/files/storage-files-quick-create-use-linux#create-an-nfs-azure-file-share

Network Configuration

Linux machines will be treated as HA nodes, and all nodes along with Storage accounts should be in the same Virtual network/subnet and same Azure region/zone.After configuring NFS File shares, refer to the steps below for Mount the NFS share.

Configure Cloud Exchange High Availability (HA)Validate Prerequisites

Check Required Ports: Ensure the following ports are open and available on each node:

4369	RabbitMQ Communication Port
5672	AMQP Communication PORT
15672	RABBITMQ Administration Console
25672	RabbitMQ Internal Port
35672	Used FOR CLI Communications
27017	MongoDB Port
443	Service Health Check

Network Configuration: The Virtual Network should be one across all Nodes.

Validate RAM, Disk space, and CPU.

sudo df -h
sudo free -h
sudo nproc

Git package, curl, and zip package:

sudo yum install -y git curl zip

Install nfs-utils.

sudo yum install -y nfs-utils

Python3 along with pip.

sudo yum install -y python3 python3-pip python3-devel

Podman and podman-compose (Ref: https://podman.io/docs/installation#rhel8 )

sudo yum module enable -y container-tools:rhel8
sudo yum module install -y container-tools:rhel8
sudo yum install -y podman-plugins
sudo pip3 install podman-compose
sudo chmod +x /usr/local/bin/podman-compose
sudo ln -s /usr/local/bin/podman-compose /usr/bin/podman-compose

Check Podman and podman-compose version:

podman-compose —-version
podman –-version

Required python packages:

pip3 install "pyyaml>=6.0.0"
pip3 install "python-dotenv>=0.20.0,<=1.0.0"
pip3 install "pymongo>=4.1.1,<=4.3.3

Configure NFS In Azure Blob Storage

Go to: https://learn.microsoft.com/en-us/azure/storage/files/storage-files-quick-create-use-linux#create-an-nfs-azure-file-share

Mount NFS Storage in Each Nodes

Go to NFS File Share Overview.

Create a mounting directory as mentioned in mount Path (Also obtained from NFS FIle share overview guide) using this command:
```
sudo mkdir -p <mount_path>
```

Edit the /etc/fstab file and mentioned mounted configuration as mentioned below:
cestorageha.file.core.windows.net:/cestorageha/shared-storage-nfs /mount/cestorageha/shared-storage-nfs nfs default 0 0
- cestorageha.file.core.windows.net:/cestorageha/shared-storage-nfs will be the source NFS directory present at the Azure Blob Storage NFS File share which will be obtained from sample command presents at Home > Respective Storage account > File shares > Newly created NFS File share > Overview.
- /mount/cestorageha/shared-storage-nfs will be the mount path and created directory.
- The other remaining part is NFS Configuration.

Run this command:
```
sudo mount -a
```

Download the Installation Package

On each node, download the Cloud Exchange installation package using this command:

git clone https://github.com/netskopeoss/ta_cloud_exchange

Run the Setup Script on the Primary Node

Go to the Cloud Exchange directory. On the primary node, run the setup script with this command:

sudo ./setup

Run the Setup Script in the Secondary Nodes

On each secondary node, go to the Cloud Exchange directory. Run the setup script using the following command, replacing <mounting_dir> with the path to your NFS mounting directory:

sudo ./setup --location <mounting_dir>

Enable the CSV index

On each node, edit the Podman Compose HA configuration file to enable CSV indexing:
```
$ vi podman-compose-ha.yml
```

Locate the core section and add the following environment variable to enable network event streaming:
```
ITERATOR_EVENT_NETWORK=stream_network_events_rollsroyce
```

Update the RabbitMQ and MongoDB Tags

For each node, open the podman-compose-ha.yml file.
```
$ vi podman-compose-ha.yml
```

Update the RabbitMQ and MongoDB service image tags as follows:

RabbitMQ:

index.docker.io/crestsystems/cloudexchange:rabbitmq-5.0.1-csv-hotfixx

MongoDB:

index.docker.io/crestsystems/cloudexchange:mongo-5.0.1-csv-hotfix

Update the Core and UI Tags

Go to NFS storage.

Edit the .env file:
```
$ vi config/.env
```

Update the CORE_TAG and UI_TAG variables as follows.

CORE_TAG=crestsystems/cloudexchange:core-5.0.1-csv-hotfix
UI_TAG=crestsystems/cloudexchange:ui-5.0.1-csv-hotfix

Backup `podman-compose-ha.yml`

On each node, create a backup of the podman-compose-ha.yml file:

$ cp podman-compose-ha.yml podman-compose-ha.yml.backup

Start Cloud Exchange on the Primary Node

Run the start script on the primary node:
```
$ sudo ./start
```

Wait for the Migration completed message before proceeding to the next step.

Start Cloud Exchange on Secondary Nodes

After you receive the Migration completed message in the primary node, then execute the start script in the remaining nodes.

$ sudo ./start

Upload and Configure the Azure Sentinel Plugin

Go to Settings > Plugin Repository in CE and click on upload plugin (⬆) button.

Select the Zip file which is shared through the Support Case and click on the upload button.

After the plugin is uploaded successfully, go to Settings > plugins to configure the uploaded plugin with the version 3.0.2.

Cloud Exchange as a VM (Virtual Machine)

Which platforms does Cloud Exchange support for a VM?

VMWare (OVA), Google Cloud Platform (OVA), AWS (AMI), Azure (VHDX)

What is the limitation of OVA?

Users do not get the root access in the OVA. This is the only limitation.

Why is it necessary to eliminate the root for cteadmin user in OVA apart from certain commands that are required for Cloud Exchange operations?

To enhance security and prevent accidental alterations, starting from version 5.0.1, we have adopted a more restrictive approach. The cteadmin user now has limited privileges tailored specifically for managing Cloud Exchange. These privileges are designed to ensure a smooth operation while minimizing the risk of inadvertent modifications.

The sudo privileges are now restricted to essential commands required for Cloud Exchange management within the VM (OVA):

Assigning IP Addresses:

If the DHCP server is disabled, the following commands are permitted:

sudo systemctl restart systemd-networkd
sudo netplan apply

Setup, Start, Stop, and Diagnose CE:
For setting up Cloud Exchange, as well as starting, stopping, and diagnosing Cloud Exchange containers or collecting logs, the following commands are allowed:
- sudo ./setup
- sudo ./start
- sudo ./stop
- sudo ./diagnose

By limiting privileges to these specific commands, we ensure that cteadmin users can perform necessary tasks related to Cloud Exchange management without risking unintended changes that could disrupt operations. This focused approach enhances security and stability within the Cloud Exchange environment.

How can I reboot or shut down Cloud Exchange as a VM (OVA)?

In order to reboot or shutdown the Cloud Exchange (OVA) machine, you can utilize the Actions provided in the VMware vSphere Client.

How do I upgrade to the next latest version of Cloud Exchange in Cloud Exchange as a VM Deployment?

In order to upgrade to the latest version of Cloud Exchange, you would have to set up a new Cloud Exchange instance (OVA VM) using the latest OVA file, mentioned in the documentation here.

After a new Cloud Exchange instance is created, you can migrate your configured Cloud Exchange data from your current Cloud Exchange instance to the new Cloud Exchange instance, following Migration Procedure in the documentation here.
Note that the upgrade of Cloud Exchange version in the same machine for Cloud Exchange as a VM deployment is not possible. Use the steps for the Migration Procedure.

Cloud Exchange Platform Logs Error Notification Setup for Slack

This section is designed to guide you through the process of setting up notifications in Slack for Cloud Exchange errors. This will allow customers to be promptly informed about any critical issues or errors encountered during the Cloud Exchange operations. Follow the steps below to configure notifications for various Cloud Exchange modules, ensuring you get notified whenever an error occurs.

Overview

To keep customers informed of critical errors in Cloud Exchange, we have implemented a Slack notifier plugin. This allows you to receive real-time alerts directly to your Slack channel whenever an error occurs in any of the Cloud Exchange modules. By setting up business rules tailored to specific modules, you can ensure that only relevant errors trigger notifications, making it easier to monitor and address issues quickly.

Notifier for Slack Configuration

If you are freshly installing the plugin, configure the Slack Notifier Plugin by following the steps outlined in the Notifier Plugin for Ticket Orchestrator document. Once done, refer to this document to configure the business rules. If you have already configured Notifier, you can directly follow this document to edit the existing business rules. Below is how to configure the business rule for each Cloud Exchange module:

Cloud Exchange Platform Errors

This section covers general Cloud Exchange Platform errors that are not tied to any specific module. These errors may include system-wide issues.