Standalone Virtual Machine
Installer Guide for Standalone Virtual Machine
Last updated
Installer Guide for Standalone Virtual Machine
Last updated
We will deploy a three-node LightBeam Kubernetes v1.28.0 (or above) cluster requiring three dedicated VMs to set up the cluster.
Internet access is required on all nodes to download LightBeam docker images and to connect with datasources for scanning.
A default admin account for LightBeam will get created to access the LightBeam UI. For multi-user onboarding, SMTP server needs to be configured on LightBeam.
The LightBeam UI can be accessed using Master node IP over http or https as desired.
LightBeam requires AVX support on the CPU . Please refer to the compatible details for more information.
Which operating system are we planning to use for VMs?
Ubuntu
Are there any additional default policies that are already configured (or will get configured) for the Kubernetes services?
E.g. Are there any policies configured which stop services automatically? If yes, we will need to exclude it for the VMs of the cluster.
Is it possible to get a sub domain for LightBeam endpoint? Yes/No
Context: To configure LightBeam UI on a known domain. E.g. lightbeam.yourdomian.com
Yes
In case SMTP server needs to be configured, is the SMTP server reachable from the Kubernetes cluster (both VMs)?
No
We will set up a three-worker-node Kubernetes cluster for the LightBeam cluster deployment where one node will be set up as a Master (control plane) with scheduling disabled and three nodes as Worker nodes. All LightBeam cluster services will be deployed on Worker nodes. After the Master and Worker nodes are provisioned as a Kubernetes cluster, using helm cli we can deploy the LightBeam cluster.
LightBeam deployment on Standalone VMs is certified on Ubuntu OS. The information below captures the OS version and the resource requirements for the Standalone VM deployments. We need 4 VMs, one as Master node (control plane) and three for Worker nodes. All VMs need to be within the same subnet.
Count
1 VM
3 VMs
Compute
4 vCPU, 8 GiB Memory
8 vCPU, 32 GiB Memory **
Local Storage
200GB on / with < 5ms latency
50 GB / and 500GB on /var with < 5ms latency
OS Flavor
Network
10Gbps b/w with internet Access to install dependent packages
10Gbps b/w with internet Access to install dependent packages
User Access
sudo
sudo
Helm (Only on the master node)
kubelet, kubeadm and kubectl
docker-ce docker-ce-cli and containerd.io On Ubuntu
A Kubernetes cluster consists of two types of nodes: master and worker nodes.
The master node hosts the Kubernetes control plane and manages the cluster, including scheduling and scaling applications and maintaining the state of the cluster.
The worker nodes are responsible for running the containers and executing the workloads.
The master node hosts the Kubernetes control plane and manages the cluster, including scheduling and scaling applications and maintaining the state of the cluster.
The master node has several components, such as:
API server: This is the main component that exposes the Kubernetes API and communicates with other components. It is the endpoint that the Kubernetes CLI (kubectl) and other clients talk to when creating or managing resources.
etcd: This is a distributed key-value store that stores the cluster state and configuration data. It is the source of truth for the cluster.
Controller manager: This runs multiple controller processes that watch for changes in the desired state of the cluster and take actions to make it happen. For example, it can create or delete pods, services, or endpoints.
Scheduler: This assigns pods to worker nodes based on various criteria, such as resource requirements, labels, or affinity rules. It works with the API server to schedule the workloads on the cluster.
Cloud controller manager: This runs controllers that are specific to the cloud provider and can manage resources outside of the cluster, such as nodes, load balancers, or routes. This component only runs if the cluster is running in the cloud.
To set up the control plane / master node, execute the script available here:
For Ubuntu:
For RHEL:
Once the above script is executed successfully run kubectl to get nodes command to check if the Master node is set up successfully. This command will show one node as ready.
The worker nodes are responsible for running the containers and executing the workloads. The worker node has these components:
Kubelet: This is an agent that runs on each worker node and communicates with the API server. It manages the containers and pods on the node, ensuring that they are running and healthy. It also reports the node status and resources to the master node.
Container runtime: This is responsible for working with the containers and executing them. It can be Docker or another container runtime, such as containerd or cri-o. It uses the container runtime interface (CRI) to communicate with the kubelet.
Pods: These are groups of one or more containers that share storage and network resources, and a specification for how to run them. Pods are the smallest units of a Kubernetes application. They can be created and managed by workload resources, such as deployments or statefulsets.
Kube-proxy: This is a network proxy that runs on each worker node and enforces network rules on them. It helps Kubernetes in managing the connectivity among pods and services. It also acts as an egress-based load-balancing controller that monitors the Kubernetes API server and updates node’s iptables subsystem based on it.
To install all required packages on the worker node execute the script available here:
For Ubuntu:
For RHEL:
Once the Master node is ready, we need to get the join token using the command:
kubeadm token create --print-join-command
Copy the output of the above command and run it on the Worker node. Once the command is successfully completed, once again run the following command from the Master node:
kubectl get nodes
This command will now display three nodes as a Kubernetes cluster, with one serving as the Master node and the other two as Worker nodes.
In this scenario, just the Worker node will support all services.
Copy lightbeam.zip file shared by the LightBeam team on the Master node VM.
Use the --self_managed flag in the installer command to specify the platform used is a self-managed kubernetes cluster.
LightBeam automates Privacy, Security, and AI Governance, so businesses can accelerate their growth in new markets. Leveraging generative AI, LightBeam has rapidly gained customers’ trust by pioneering a unique privacy-centric and automation-first approach to security. Unlike siloed solutions, LightBeam ties together sensitive data cataloging, control, and compliance across structured and unstructured data applications providing 360-visibility, redaction, self-service DSRs, and automated ROPA reporting ensuring ultimate protection against ransomware and accidental exposures while meeting data privacy obligations efficiently. LightBeam is on a mission to create a secure privacy-first world helping customers automate compliance against a patchwork of existing and emerging regulations.
Follow the installation instructions in the .
For any questions or suggestions, please get in touch with us at: .
