Deploy Connectors

Last updated
Save as PDF

Download and deploy connectors alongside the private applications. You can deploy multiple connectors for redundancy and scaling. When you add an application, you can associate it with several connector groups for high availability. For example, If the VM running a connector fails, your application is still secured and accessible by the other running connector.

NOTE:

Connectors use snap for installation of microk8s and snap packages use the squashfs file system. So do not disable the squashfs file system.
You do not need to install the CWPP Agent or CI/ CD service on the connector host.

Prerequisites

Skyhigh Security strongly recommends using a Virtual Machine (VM) for deploying connectors with the following prerequisites:

Ubuntu on both IPv4 and IPv6 (version 18, 20, and 22 only)
4 CPU
8 GB RAM
50 GB HDD (reserve around 25 GB for var partition ('/var'))
Execution permission on the /var directory

You can also deploy connectors on Red Hat Enterprise Linux version 8.5, 8.6, 8.7, and 9.1 on both IPv4 and IPv6.

The hostname of a VM is used to update the POP name in the Skyhigh CASB UI, so it is a good practice to make the hostname length less than 64 characters.

NOTE: Each connector is associated with a connector group. When you create a connector group, remember to copy the provisioning key it generates. A connector is identified with a connector group through this provisioning key. To achieve optimal performance, Skyhigh recommends that you deploy the connectors to the closest PoP.

When you are using a firewall, you must set up your firewall to allow the following domains and HTTP(S) ports:

Domains	Port	Purpose
myshn.net	443	Updates the PoP status in Skyhigh CASB UI
index.docker.io	443	Docker hub container image library to pull an image and token authentication
registry-1.docker.io
auth.docker.io
production.cloudflare.docker.com
storage.googleapis.com	443	Storage that keeps information on the latest Kubernetes release
k8s.gcr.io	443	Main Kubernetes image-serving system that stores images
cdn.fwupd.org		Open-source daemon to manage the installation of firmware updates on the Linux systems
api.snapcraft.io	443	Snap daemon installation
canonical-lgw01.cdn.snapcraftcontent.com
canonical-bos01.cdn.snapcraftcontent.com
security.ubuntu.com	443	Download and install packages on the host (Ubuntu) as a part of connector deployment
azure.archive.ubuntu.com
packages.microsoft.com
changelogs.ubuntu.com
motd.ubuntu.com
iam.mcafee-cloud.com	443	Register token or get access for the user accounts from the IAM service
us-east.pa-wgcs.skyhigh.cloud	443	Create an OpenVPN tunnel with the Private Access Gateway
us-west.pa-wgcs.skyhigh.cloud
de.pa-wgcs.skyhigh.cloud
sg.pa-wgcs.skyhigh.cloud
gb.pa-wgcs.skyhigh.cloud
br.pa-wgcs.skyhigh.cloud
jp.pa-wgcs.skyhigh.cloud
hk.pa-wgcs.skyhigh.cloud
hk.pa-wgcs.skyhigh.cloud
fr.pa-wgcs.skyhigh.cloud
se.pa-wgcs.skyhigh.cloud
wgcs.skyhigh.cloud:8080
wgcs.skyhigh.cloud:8080	8080	Endpoint for registering connector

Deploy Connectors

Complete the following steps to deploy connectors:

In Skyhigh SSE go to Settings > Service Management.
Click Add Service Instance.
Select VMware vCenter.
In the Instance Name field, enter the service instance name.
Click Done.
Adds the selected service instance.
Under Services, select the name of the service instance.
Click Setup.
Click Download Deployment Package.
Downloads thePoPPackage.tar.
Unzip the PoPPackage.tar file.
Unzip theInfrastructure.tar file, and extract theinfra.shfile from the vCenter folder.
Copy both PoPDeployment.tar and infra.shto the Ubuntu VM. E.g. by executing cp vCenter/infra.sh .

NOTE: Make sure that the VM is set to the UTC timezone.

Configure Domain Name System (DNS) in the host for name resolution. On AWS, Azure, and Google Cloud Platform, the DNS is configured dynamically.

NOTE: You can configure a maximum of three DNS name servers in a host.

Executeinfra.shon the VM and provide the following parameters:

sudo bash infra.sh --provision_key="<PROV_KEY>" --gateway="<GATEWAY_IP>" --proxy="<PROXY>" --no_proxy="<NO_PROXY>"

NOTE: The provisioning key is generated when you create a connector group. The provisioning key is a text string that identifies a connector with a connector group. The maximum number of connectors you specify while creating a connector group is the number of times you can use a provisioning key.

infra.sh invokes the deployment of a connector
GATEWAY_IP is the nearest Private Access Gateway deployed in the following PoPs:
- US PoP - us-west.pa-wgcs.skyhigh.cloud
- Ohio PoP - us-east.pa-wgcs.skyhigh.cloud
- Germany PoP - de.pa-wgcs.skyhigh.cloud
- Singapore PoP - sg.pa-wgcs.skyhigh.cloud
- London PoP - gb.pa-wgcs.skyhigh.cloud
- Brazil PoP - br.pa-wgcs.skyhigh.cloud
- Osaka PoP - jp.pa-wgcs.skyhigh.cloud
- Hongkong PoP - hk.pa-wgcs.skyhigh.cloud
- Paris PoP - fr.pa-wgcs.skyhigh.cloud
- Stockholm PoP - se.pa-wgcs.skyhigh.cloud

NOTE: We recommend that you select a PoP location that is nearest to the location where you deploy the connectors to achieve optimal performance.

<proxy> is the address of the proxy server
<no_proxy> is the list of domains you can add to bypass the proxy

NOTE: Set the <proxy> and <no_proxy> parameters only when your connector uses the proxy server. When you use a proxy, make sure to add corp.nai.org, .internalzone.com, .scur.com, and .corp.mcafee.com to the <no_proxy> parameter.

The following is an example of a sudo command:

sudo bash infra.sh --provision_key="ey.....LTUwRTVCOUE2NTFFNCJ9" --gateway="us-west.pa-wgcs.skyhigh.cloud" 

Example with proxy between connector the Internet
sudo bash infra.sh --provision_key="ey.....LTUwRTVCOUE2NTFFNCJ9" --gateway="us-west.pa-wgcs.skyhigh.cloud" \
     --proxy="http://10.212.24.192:9090" --no_proxy="localhost,.corp.trellix.com,172.17.0.1,<hostname>,127.0.0.1, 10.0.0.0/8"


sudo bash ./infra.sh --provision_key="<PROV_KEY>" --gateway="<GATEWAY>"
Where:
<PROV_KEY> = eyJjb25uZWN0b3JOYW1lIjoiWlROQWFscGhhIiwiY3VzdG9tZXJJZCI6IjEjcyLTUwRTVCOUE2NTFFNCJ9
<GATEWAY> = us-west.pa-wgcs.skyhigh.cloud
<PROXY> = http://10.212.24.192:9090
<NO_PROXY> = localhost,corp.nai.org,.internalzone.com,.scur.com,.corp.mcafee.com,172.17.0.1,<hostname>,127.0.0.1, 10.0.0.0/8

Execute the pa_connector.sh script, and enter 1 to check the status of the services running on POP.
The following is a sample output you get when you enter 1:

The below following lists the purpose of the services running on POP:

Service Name on POPs	Purpose
CWPP logging	Centralized logging for all services running on POP
CWPP connector	Internal load balancer and communicates with Skyhigh SSE
CWPP update	Automatically updates services running on POP
CWPP pop manager	Periodically sends the POP health status to the Skyhigh SSE via CWPP connector

After completing the deployment successfully, the connector and a POP Manager image is created on the VM and your docker instance runs as a container. You can check the POP status on the POP Management page. For more information about POP Management, see About POP Management.

Once the connector is deployed, it automatically registers with Skyhigh SSE, generates the certificate, and get it signed by Skyhigh SSE. The connector establishes a tunnel with the Private Access Gateway by using this signed certificate. The connector provides secure access to the requested private application through the tunnel.

Connector Workflow

The following steps are automatically executed once a connector is deployed with the right parameters.

The connector:

Registers itself with Skyhigh Security.
Receives a signed certificate for authentication while establishing the OpenVPN tunnel with the Private Access Gateway.
Periodically refreshes the access tokens.
Periodically checks to verify that the OpenVPN tunnel with the Private Access Gateway is up. If the tunnel is down, it brings up the tunnel.
Establishes two tunnels with the Private Access Gateway.
Two OpenVPN connection requests from the connector are load-balanced and send traffic to two different gateways, which results in two tunnels.
Periodically downloads the list of Private Applications from Skyhigh Security, checks connectivity with those applications, creates a health-update, and sends it to the Private Access Gateway.
Sends health-updates to both the OpenVPN tunnels.
The Cloud chooses one of the OpenVPN tunnels in a round-robin fashion  when a request for a private application is received (from an end-user device).
Acts as a proxy for the private applications and forwards traffic received through the OpenVPN tunnel to the corresponding servers of the private applications.

Connector Upgrades

The connectors are automatically upgraded to the latest available version. This feature is supported only on the functional connectors with version v1.0.0.3 and later.

To check the connector version, execute the pa_connector.sh script and enter 2: