Configure ASC Worker Nodes and Deploy Versa Secure Lens

Last updated
Save as PDF

For supported software information, click here.

Versa Advanced Security Cloud (ASC) is a cloud-delivered security framework that provides enterprise security services as part of the broader Versa SASE architecture. Versa Secure Lens includes a streamlined subset of the ASC functionality that allows for deployment in an on-premise environment using Kubernetes control and worker nodes. This deployment model also supports running individual workloads on Versa Messaging Service (VMS) worker nodes.

Versa Secure Lens supports the deployment of a cluster, which includes at least one control plane node and three worker nodes:

A control plane node manages cluster operations.
A worker node runs Versa application workloads, such as the device risk score (DRS) service.

It supports on-premise deployment of EDR platforms by adding worker nodes to an existing VMS cluster, enabling endpoint intelligence for organizations with strict data residency requirements. To deploy multiple nodes in a cluster, you configure worker nodes to deploy scalable worker-based ASC. Worker nodes enable the separation of control and workload planes and efficient deployment of Versa Secure Lens and device risk score (DRS) services.

This articles covers the following:

Requirements—The basic infrastructure and hardware requirements for a Versa Secure Lens cluster.
Convert VMS nodes to worker nodes—Convert VMS nodes to worker nodes and add them to the control plane node.
Configure Versa Secure Lens and DRS—Prerequisites and steps to configure Versa Secure Lens and the DRS service.
Perform validation and maintenance—Steps to verify Kubernetes pods, worker nodes, and VMS cluster deployment.

Requirements

To configure a Versa Secure Lens cluster, make sure that your system meets the following infrastructure and hardware requirements:

Control plane node (VM)—One node with 32 cores CPU and 64 GB RAM (minimum)
Worker nodes (VM)—Minimum 3 nodes with 16 cores CPU and 32 GB RAM (minimum)
Two public IP addresses—One for the control plane and one for worker access (ingress)

Cloud environments such as AWS use elastic IP addresses for northbound communication.

Convert VMS Nodes to Worker Nodes

To convert a VMS node to a worker node:

Log in to the VMS node that you want to convert to a worker node as the root user.
Add the control plane node hostname entry in the /etc/hosts file of the worker node by issuing the sudo vi /etc/hosts CLI command.

Run the vsh convert-to-worker CLI command on the VMS node. For example:

[root@vms-3: worker-setup] $ vsh convert-to-worker
[SETUP] Ensuring backup directories exist...
------------------------------------------------------------
[INFO] Starting conversion of control-plane -> worker node
[INFO] Temporary backup directory: /opt/versa/masterbackup/k8s-backup-temp

Perform these steps on each VMS node that you want to convert to worker node.

Add Worker Nodes to the Control Plane Node

To add worker nodes to a control plane node:

Log in to the control plane where you want to add the worker nodes that you converted in Convert VMS Nodes to Worker Nodes, above.

Run the vsh add-node CLI command as the Linux root user. For example:

[root@vms-1]$ vsh add-node 
Disk Usage: 7%

------------------------------------------------------------
Current cluster nodes (with labels)
------------------------------------------------------------

NAME                         STATUS   ROLES            AGE   VERSION   INTERNAL-IP     EXTERNAL-IP   OS-IMAGE             KERNEL-VERSION   CONTAINER-RUNTIME   LABELS
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
vms-1.example.com            Ready    control-plane    14d   v1.33.x   <IP-Address>    <none>        Ubuntu 18.04.x LTS   4.15.x           containerd://x.x.x  beta.kubernetes.io/arch=amd64, beta.kubernetes.io/os=linux, node-role.kubernetes.io/control-plane=
                                                                                                                                                                          kubernetes.io/hostname=vms-1.example.com

vms-2.example.com            Ready    worker           19h   v1.33.x   <IP-Address>    <none>        Ubuntu 18.04.x LTS   4.15.x           containerd://x.x.x  beta.kubernetes.io/arch=amd64, beta.kubernetes.io/os=linux, node-role.kubernetes.io/worker=
                                                                                                                                                                          kubernetes.io/hostname=vms-2.example.com

vms-3.example.com            Ready    worker           51m   v1.33.x   <IP-Address>    <none>        Ubuntu 18.04.x LTS   4.15.x           containerd://x.x.x  beta.kubernetes.io/arch=amd64, beta.kubernetes.io/os=linux, node-role.kubernetes.io/worker=
                                                                                                                                                                          kubernetes.io/hostname=vms-3.example.com

Do you want to add a new worker node? (y/N):

Enter the worker hostname and primary interface IP address when prompted. For example:

Enter the Hostname of Worker VMS Node: vms-3.versa-networks.com
Enter Worker Server Management/Primary Interface IP Address: <IP-Address>
[INFO] Checking cluster for existing nodes...

Copy the join command and run it on the worker node with "sudo" root permissions, and press Enter in the current flow. For example:

======================================================================
 WORKER NODE JOIN COMMAND
======================================================================

Copy and run this command on the worker node (10.1xx.1x.1xx):

kubeadm join vms-1:6443 --token 7lz2ap.xts910eyj7z7iauk --discovery-token-ca-cert-hash sha256:8a55ec63f11ab46ee5123489407d7d4cdd259b82d0b7d8b6cfe64891ec90df09  --ignore-preflight-errors=all --v=5

======================================================================
Notes:
 1. Run 'convert_to_worker.sh' first on worker node if not already done.
 2. Do NOT run 'kubeadm reset' unless re-provisioning.
------------------------------------------------------------

Press Enter once you have executed the join command on worker node..

Enter the following information after you press Enter:

For a bare-metal deployment, enter Y when prompted "Is this a baremetal setup? (y/n)" and enter N for a cloud deployment (for example, AWS). The example below shows a cloud deployment.

------------------------------------------------------------------------
Certificate Generation
------------------------------------------------------------------------
Enter Ingress FQDN for workers (e.g. workers.example.com): workers-org.us-west-1.abc.com
[INFO] Running cert generation script...
[OK]   Created TLS secret 'worker-server-cert'
Is this a baremetal setup? (y/n): n
[OK]   Ingress manifest applied.
[INFO] Waiting for worker ingress controller to be available...
Waiting for daemon set "worker-nginx-controller" rollout to finish: 0 of 1 updated pods are available...
daemon set "worker-nginx-controller" successfully rolled out
[INFO] Waiting for admission webhook setup to complete...
job.batch/worker-nginx-admission-create condition met
[OK]   Worker ingress admission webhook is ready.
[OK]   Ingress resource for drs has been deployed in the apidp namespace.
[OK]   Worker vmsworker1 successfully added to cluster.

Enter the FQDN and elastic IP address of the worker node. For example:

------------------------------------------------------------------------
Certificate Generation
------------------------------------------------------------------------
Enter Ingress FQDN for workers (e.g. workers.example.com): workers.example5.com
[INFO] Running cert generation script...
[OK]   Created TLS secret 'worker-server-cert'

------------------------------------------------------------------------
Ingress Setup
------------------------------------------------------------------------
Enter Ingress VIP/LoadBalancer IP: x.x.x.x
[OK]   Ingress manifest applied.

[INFO] Node registered successfully.
[OK]   Node registered successfully.
[INFO] Verifying Node Readiness...
[INFO] "vms-3.versa-networks.com" to Ready.
[INFO] Applying Labels and taints to vms-3.versa-networks.com...
[INFO] TLS Secret 'worker-server-cert' already exists.
[INFO] Worker ingress controller already exists.
[OK]   Worker vms-3.versa-networks.com successfully added to cluster.

------------------------------------------------------------------------
Current cluster nodes (with labels)
------------------------------------------------------------------------
NAME                        STATUS  ROLES          AGE   VERSION  INTERNAL-IP   EXTERNAL-IP  OS-IMAGE             KERNEL-VERSION    CONTAINER-RUNTIME
vms-1.versa-networks.com    Ready   control-plane  24d   v1.33.2  x.x.x.x       <none>       Ubuntu 18.04.6 LTS   4.15.0-212-fips   containerd://1.6.12
vms-2.versa-networks.com    Ready   control-plane  15d   v1.33.2  x.x.x.x       <none>       Ubuntu 18.04.6 LTS   4.15.0-212-fips   containerd://1.6.12
vms-3.versa-networks.com    Ready   worker         15m   v1.33.2  x.x.x.x       <none>       Ubuntu 18.04.6 LTS   4.15.0-212-fips   containerd://1.6.12

To add more worker nodes, enter Y for the prompt "Do you want to add a new worker node?".


Do you want to add a new worker node? (y/N): y
Enter the Hostname of Worker VMS Node: vms-worker-2.versa-networks.com
Enter Worker Server Management/Primary Interface IP Address: 1x.1xx.1x.1xx
[INFO] Checking cluster for existing nodes...

------------------------------------------------------------
 Joining New Worker: vms-worker-2.versa-networks.com (1x.1xx.1x.1xx)
------------------------------------------------------------
[INFO] Generating join command...

======================================================================
 WORKER NODE JOIN COMMAND
======================================================================

Copy and run this command on the worker node (1x.1xx.1x.1xx):

kubeadm join vms-1:6443 --token 7lz2ap.xts910eyj7z7iauk --discovery-token-ca-cert-hash sha256:8a55ec63f11ab46ee5123489407d7d4cdd259b82d0b7d8b6cfe64891ec90df09  --ignore-preflight-errors=all --v=5

======================================================================
Notes:
 1. Run 'convert_to_worker.sh' first on worker node if not already done.
 2. Do NOT run 'kubeadm reset' unless re-provisioning.
------------------------------------------------------------

Press Enter once you have executed the join command on worker node..

....
Do you want to add a new worker node? (y/N):

Enter the worker hostname and primary interface IP address when prompted.
Copy the join command and run it on the worker node with "sudo" root permissions, and press Enter in the current flow.

Configure Versa Secure Lens and DRS

This section describes how to configure Versa Secure Lens and the device risk score (DRS) service.

Prerequisites

Before you perform the deployment, you must perform the following steps as a root user:

To run the setup script (setup.sh) from the location /opt/versa/scripts/install/asc-infra:

Issue the cd /opt/versa/scripts/install/asc-infra CLI command.

Issue the sudo ./setup.sh CLI command to run the setup script. For example:

[root@vmscontroller1: asc-infra] $ ./setup.sh
================================================
Setting up ASC Infra
================================================
Applying local-path-storage.yaml
================================================
namespace/local-path-storage created
serviceaccount/local-path-provisioner-service-account created
role.rbac.authorization.k8s.io/local-path-provisioner-role created
clusterrole.rbac.authorization.k8s.io/local-path-provisioner-role created
rolebinding.rbac.authorization.k8s.io/local-path-provisioner-bind created
clusterrolebinding.rbac.authorization.k8s.io/local-path-provisioner-bind created
daemonset.apps/local-path-provisioner created
storageclass.storage.k8s.io/local-path-asc-worker created
configmap/local-path-config created
Applying asc-redis-setup.yaml
================================================

Install the required packages:
1. Issue the cd /opt/versa/scripts/install/asc-infra/versa-cluster-admin/scripts CLI command.
2. Issue the sudo ./install_root_packages_onprem.sh --use-local-registry CLI command.

Note: To avoid installing versa-cluster-admin, we run two scripts instead:

install_root_packages_onprem.sh (/home/admin/versa-cluster-admin/scripts)—Runs with limited applications.
setup.sh (/opt/versa/scripts/install/asc-infra/setup.sh)—Creates and configures namespaces, service accounts, roles, and role bindings.

Configure Versa Secure Lens

To configure Versa Secure Lens:

Edit the configuration file (api-dp-config.yaml) by issuing the vi /opt/versa/scripts/install/asc-infra/api-dp-config.yaml CLI command.

Enter the following information:

cluster_ingress_ip—Enter the IP address of the new cluster's ingress or load balancer (applicable only bare-metal; leave unchanged for cloud deployments)
base_domain_name—Enter the base domain name of the new cluster.
cluster_hostname—Enter the FQDN of the new worker node. This is typically the NLB or load balancer DNS hostname.

For example:

# FQDNS
cluster_ingress_ip: "10.xx.xx.x"  # Only applicable to baremetal >>>>>>>>>>>>>>>CHANGE THIS FOR NEW CLUSTER
dns_solver: true  # false to use http solver if aws r53 credentials does not have access to the hosted zone present in cluster_hostname
base_domain_name: "abc.com"  #>>>>>>>>>>>>>>>CHANGE THIS FOR NEW CLUSTER
cluster_hostname: "workers-nlb2-b4xxxx5xxxxxx8xx.elb.us-west-1.abc.com"  #>>>>>>>>>>>>>>>CHANGE THIS FOR NEW CLUSTER

Run the ASC Infra binary from its directory with the configuration file and a node role flag (--control-plane or --worker).

Navigate to the install directory by issuing the cd /opt/versa/scripts/install/asc-infra CLI command.
Run the binary with the configuration file and the appropriate node flag.
For a control plane node, run the ./<asc-infra.bin> /opt/versa/scripts/install/asc-infra/api-dp-config.yaml --control-plane CLI command.

For example:

[root@vms-1: asc-infra-bin-files] $ ./versa-asc-infra-20251210-030132-1cc5003fd-dev-vms-apidp.bin /home/admin/asc-infra-bin-files/api-dp-config.yaml
Verifying archive integrity...  100%   MD5 checksums are OK. All good.
Uncompressing Versa ASC Infra Binary Package  100%
Current bin execution directory is: /tmp/selfgz25462
Using config JSON file: /home/admin/asc-infra-bin-files/api-dp-config.yaml
Installing ASC Infra with config file: /home/admin/asc-infra-bin-files/api-dp-config.yaml
[2025-12-12 08:39:56] Using storage class: local-path-asc-worker
[2025-12-12 08:39:56] Install/Upgrade redis ...
[2025-12-12 08:40:02] Install/Upgrade redis ... [5s elapsed]
[2025-12-12 08:40:07] Install/Upgrade redis ... [10s elapsed]
[2025-12-12 08:40:12] Install/Upgrade redis ... [15s elapsed]
[2025-12-12 08:40:17] Install/Upgrade redis ... [20s elapsed]
[2025-12-12 08:40:22] Install/Upgrade redis ... [25s elapsed]
...
[2025-12-12 08:50:32] Install/Upgrade asc-deps [completed in 2.01s]
[2025-12-12 08:50:32] ASC-INFRA Deployment completed in 635.51s
ASC Infra Installation complete!

This completes the Versa Secure Lens installation.

Configure DRS

Run the ASC infra binary from its directory with the configuration file and a node role flag (--control-plane or --worker).
Navigate to the install directory by issuing the cd /opt/versa/scripts/install/asc-infra CLI command.
Run the binary with the configuration file and the appropriate node flag.

For a control plane node, run the ./<apidp.bin> /opt/versa/scripts/install/asc-infra/api-dp-config.yaml --control-plane CLI command. For example:

[root@vms-1: asc-infra-bin-files] $ ./versa-apidp-20251212-012720-5e58f3330-dev-vms-apidp.bin /home/admin/asc-infra-bin-files/api-dp-config.yaml
Verifying archive integrity...  100%   MD5 checksums are OK. All good.
Uncompressing Versa APIDP Binary Package  100%
Current bin execution directory is: /tmp/selfgz7612
Using config JSON file: /home/admin/asc-infra-bin-files/api-dp-config.yaml
Installing APIDP with config file: /home/admin/asc-infra-bin-files/api-dp-config.yaml
[2025-12-12 11:06:54] Using storage class: local-path-asc-worker
[2025-12-12 11:06:54] Verifying ASC-INFRA status...
[2025-12-12 11:06:56] ASC-INFRA status verified, proceeding with the deployment of APIDP.
[2025-12-12 11:06:57] Install/Upgrade volume ...
[2025-12-12 11:06:58] Install/Upgrade volume [completed in 1.01s]
[2025-12-12 11:06:58] Install/Upgrade apidp-deps ...
[2025-12-12 11:06:59] Install/Upgrade apidp-deps [completed in 1.01s]
[2025-12-12 11:06:59] Install/Upgrade drs ...
[2025-12-12 11:07:04] Install/Upgrade drs ... [5s elapsed]
[2025-12-12 11:07:09] Install/Upgrade drs ... [10s elapsed]
[2025-12-12 11:07:10] Install/Upgrade drs [completed in 11.03s]
[2025-12-12 11:07:10] APIDP Deployment completed in 15.12s
APIDP Installation complete!

This completes the DRS installation.

Perform Validation and Maintenance

To verify Kubernetes pods in the DRS and Versa Secure Lens environments, run the kubectl get pods -A. All pods must be running and scheduled on worker nodes.
If a worker node goes down and up, or is unstable, run the sudo /opt/versa/scripts/maintenance/flannel-recover.sh script to refresh the flannel of the worker node. Then, refresh the Flannel DaemonSet by issuing the kubectl rollout restart daemonset kube-flannel-ds -n kube-flannel CLI command.

Verify Cluster and Deployment

To verify the cluster information, issue the k get nodes -A -o wide or kubectl get nodes -A -o wide CLI command. For example:

[root@control-node-vms1: admin] $ k get nodes -A -o wide
NAME                        STATUS  ROLES          AGE  VERSION  INTERNAL-IP  EXTERNAL-IP  OS-IMAGE            KERNEL-VERSION      CONTAINER-RUNTIME
control-node-vms1           Ready   control-plane  23d  v1.33.3  x.x.x.x      <none>       Ubuntu 18.04.6 LTS  4.15.0-1141-fips    containerd://1.6.12
vms-2.versa-networks.com    Ready   worker         11d  v1.33.3  x.x.x.x      <none>       Ubuntu 18.04.6 LTS  4.15.0-1141-fips    containerd://1.6.12
vms-3.versa-networks.com    Ready   worker         10d  v1.33.3  x.x.x.x      <none>       Ubuntu 18.04.6 LTS  4.15.0-1141-fips    containerd://1.6.12
vms-4.versa-networks.com    Ready   worker         10d  v1.33.3  x.x.x.x      <none>       Ubuntu 18.04.6 LTS  4.15.0-1141-fips    containerd://1.6.12

To verify the charts deployed in Versa Secure Lens, issue the helm list -n asc-infra CLI command. For example:

[root@control-node-vms1: admin] $ helm list -n asc-infra
NAME        NAMESPACE   REVISION   UPDATED                                   STATUS     CHART            APP VERSION
k8s-deps    asc-infra   1          2025-12-02 11:26:27.192321488 +0000 UTC   deployed   k8s-deps-0.1.4   1.16.0
mongodb     asc-infra   1          2025-12-02 11:25:58.814093302 +0000 UTC   deployed   mongodb-0.1.0    1.0
redis       asc-infra   1          2025-12-02 11:25:00.562131176 +0000 UTC   deployed   redis-24.0.0     8.4.0

To verify the charts deployed in DRS, issue the helm list -n apidp CLI command. For example:

[root@control-node-vms1: admin] $ helm list -n apidp
NAME   NAMESPACE   REVISION   UPDATED                                   STATUS     CHART                       APP VERSION
drs    apidp       1          2025-12-05 09:01:46.415933467 +0000 UTC   deployed   saas-partner-services-0.1.0  1.0

Supported Software Information

VMS Releases 5.3.1 and later support all content described in this article.

Additional Information

Configure VMS to Integrate EDR Platforms
Enable and Configure VMS Services
Install and Configure VMS