Skip to main content

Welcome to Skyhigh Security!

Skyhigh Security

Deploy Secure App Connector

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.


  • 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. 


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

  • We support both Ubuntu (version 18,20 and 22 only) and Red Hat Enterprise Linux (version 8.5,8.6,8.7,9.0 and 9.1 only) on IPV4 and IPV6.
    • Note: We support AWS, Azure and VCenter vendors for connector deployment.
  • 4 CPU 
  • 8 GB RAM
  • 50 GB HDD
  • /var has 25 GB 
  • Execution permission on the /var directory

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

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. 

Firewall settings

When you are using a firewall, you must set up your firewall to allow certain domains and HTTP(S) ports. For information, see Firewall settings.

Deploy Connectors

Complete the following steps to deploy connectors:

  1. In Skyhigh CASB navigation bar, go to Settings > Service Management.
  2. Click Add Service Instance.
  3. Select VMware vCenter.
  4. In the Instance Name field, enter the service instance name.
  5. Click Done.
    Adds the selected service instance.
  6. Under Services, select the name of the service instance.
  7. Click Setup.
  8. Click Download Deployment Package which will download thePoPPackage.tar.
  9. Transfer the PoPPackage.tarfile to the machine where you wish to install the connector.
  10. Open a shell on the machine where you will install the connector, and change directory to where you transferred the PoPPackage.tar.
  11. Extract the PoPPackage.tar file:
    tar -xvf PoPPackage.tar
  12. Extract theInfrastructure.tar file:
    tar -xvf Infrastructure.tar
  13. Copy to the /usr/local/bin/ directory and infra.shto the present directory:
    cp vCenter/ /usr/local/bin/
    cp vCenter/ .

Make sure that the VM is set to the UTC timezone. On Ubuntu variants, execute sudo dpkg-reconfigure tzdata to set to the UTC time zone.

  1. Ensure your system is configured properly for Domain Name System (DNS) so that it can resolve both Internet hostnames and the hosts that you will want to access on the local network through the connector. Note: On AWS, Azure, and Google Cloud Platform, the DNS is configured dynamically.
  2. Execute the , replacing <VALUES> using those found below and including quotation marks in your command:
    sudo bash --provision_key="<PROV_KEY>" --gateway="<GATEWAY_HOST>" --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. 

  • <GATEWAY_HOST> is the nearest Private Access Gateway deployed in the following regions:
    • US West PoP -
    • US East PoP -
    • Germany PoP -
    • Singapore PoP -
    • England PoP -
    • Brazil PoP -
    • Japan PoP -
    • Hongkong PoP -
    • France PoP -
    • Sweden PoP -

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>: Address of the proxy server (optional)
  • <NO_PROXY> :  List of domains that can be added to bypass the proxy (optional). This parameter can be ignored if you don't have any domains that need to bypass the proxy, even when a proxy is used.

 NOTE: Set the <PROXY> and <NO_PROXY> parameters only when your connector uses a proxy server to reach the Internet.

The following is an example of the installation command without a proxy:

sudo bash --provision_key="ey.....LTUwRTVCOUE2NTFFNCJ9" --gateway="" 

The following is an example of the installation command with a proxy server and proxy exception list (--no_proxy):

sudo bash --provision_key="ey.....LTUwRTVCOUE2NTFFNCJ9" --gateway="" \
     --proxy="" --no_proxy=""
  1. Execute the script, and enter to check the status of the services running on POP.



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:

  1. Registers itself with Skyhigh Security. 
  2. Receives a signed certificate for authentication while establishing the OpenVPN tunnel with the Private Access Gateway.
  3. Periodically refreshes the access tokens.
  4. 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. 
  5. Establishes two tunnels with the Private Access Gateway.
  6. Two OpenVPN connection requests from the connector are load-balanced and send traffic to two different gateways, which results in two tunnels.
  7. 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.
  8. Sends health-updates to both the OpenVPN tunnels.
  9. 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).
  10. 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 script and enter 1


  • Was this article helpful?