This is Step 1 of the DSPM DRA Setup |
|---|
Requirements
| Info |
|---|
We use Kubernetes, an open-source container orchestration system to manage our applications. At the moment the only Kubernetes distribution supported is K3s (click here for the official documentation) by Suse Linux for both on-premise and cloud deployments. |
The minimum requirements for the Kubernetes cluster is a single node (1 virtual machine) with the following specs:
DSPM | |||
|---|---|---|---|
CPU | 20 cores | ||
⚠️ The CPU must support the instructions SSE4.1, SSE4.2, AVX, AVX2, FMA. Only x86_64 architecture is supported. Minimum CPU speed is 2.2 GHz | |||
Memory | 80GB | ||
Storage | 700GB Min available inodes for ext4: 39M | ||
Storage details |
| ||
Operating System | Ubuntu 20.04 LTS Server is recommended, other supported operating systems include:
Only Server edition versions are supported. No Desktop Environment installed. No other linux distributions are supported.
| ||
Firewall |
| ||
K3s version support | 1.23, 1.24, 1.26 | ||
Other requirements |
For hardened systems, see: Deploying Product in CIS hardened OS or K3s When deploying using RHEL / CentOS / Suse:
When deploying using Ubuntu:
|
Network settings
Your network should be configured to allow the following public URLs to be accessible over port 443 (HTTPS) and HTTPS traffic is bypassed (NOT intercepted):
| Code Block |
|---|
https://assets.master.k3s.getvisibility.com (Custom K3s installation files) https://images.master.k3s.getvisibility.com (Private Docker registry) https://charts.master.k3s.getvisibility.com (Private Helm registry) https://prod-eu-west-1-starport-layer-bucket.s3.eu-west-1.amazonaws.com (Docker registry AWS CDN) https://rpm.rancher.io (Rancher RPM repo for configuring SELinux packages on RHEL or CentOS) https://api.master.k3s.getvisibility.com (Private API server) https://rancher.master.k3s.getvisibility.com (Rancher management server) https://rancher.$RESELLER_NAME.k3s.getvisibility.com (Rancher management server, where $RESELLER_NAME is Getvisibility for direct customers) For Forcepoint these are: https://rancher.forcepointus.k3s.getvisibility.com/ https://rancher.forcepointapac.k3s.getvisibility.com/ https://rancher.forcepointemea.k3s.getvisibility.com/ |
Installation
| Info | ||
|---|---|---|
If using proxy, please run this before using
|
Before installation please use the following command to see if product requirements are met.
| Code Block |
|---|
curl -sfL https://assets.master.k3s.getvisibility.com/k3s/k3s.sh | PRODUCT_NAME=ultimate ONLY_PRECHECK=true bash - |
Run k3s installer using the following command as root user:
| Code Block |
|---|
curl -sfL https://assets.master.k3s.getvisibility.com/k3s/k3s.sh | INSTALL_K3S_VERSION="v1.26.10+k3s1" K3S_KUBECONFIG_MODE="644" sh -s - server --node-name=local-01 |
| Info |
|---|
Few more arguments that can be used to customize the execution of the k3s script: These skips can be used if the machine is undersized or incompletely configured. However, installing on such a machine is not recommended and can impact performance. |
Use the license key
| Note |
|---|
For Forcepoint customers, Forcepoint’s SE generates the DSPM license key, which is shared with the customer via email. For all other partner customers, Getvisibility will provide the kubectl registration command. |
Run the kubectl registration command:
| Code Block |
|---|
The command below is just an example, it will not work during deployment! kubectl apply -f https://....k3s.getvisibility.com/v3/import/dxslsxcf84....yaml |
| Warning |
|---|
For security reasons the registration command can be used only a single time, the command becomes invalid after the first use. In case you need to run it again you must contact the support team for a new registration command. |
Monitor the progress of the installation: watch -c "kubectl get deployments -A"
The K3s deployment is complete when elements of all the deployments (coredns, local-path-provisioner, metrics-server, traefik and cattle-cluster-agent) show at least "1" as "AVAILABLE"
In case of errors you can inspect the logs of a pod using
kubectl logs, e.g.kubectl logs cattle-cluster-agent-d96d648d8-wjvl9 -n cattle-system
Now, go to the Step 2, which is available via this link – DSPM DRA - Rancher Configuration |
|---|
Appendix
K3s support matrix
Please note that we don’t use Docker as the container runtime, instead we use containerd.
| View file | ||
|---|---|---|
|
Why K3s ?
Kubernetes has been widely adopted in modern software development as it offers a powerful, portable and open-source platform that automates the management of containerized applications.
When setting up a Kubernetes environment, it comes in two flavours: vanilla Kubernetes and managed Kubernetes. With vanilla Kubernetes, a software development team has to pull the Kubernetes source code binaries, follow the code path, and build the environment on the machine. On the other hand, managed Kubernetes comes pre-compiled and pre-configured with tools that improve features to enhance a certain focus area, such as storage, security, deployment, monitoring, etc. Managed Kubernetes versions are also known as Kubernetes distributions. Some popular Kubernetes distributions are Rancher, Red Hat OpenShift, Mirantis, VMware Tanzu, EKS, GKE and AKS.
Kubernetes distributions can have different components that may cause applications that work in one distribution to not necessarily work or even crash into another. Some of the most important components that differ between distributions are:
Container Runtime: The container runtime is the software that is responsible for running containers. Each Kubernetes Distribution may offer support for different Container Runtimes. Some popular container runtimes include Docker, CRI-O, Apache Mesos, CoreOS, rkt, Canonical LXC and frakti among others.
Storage: Storage is important for Kubernetes applications as it offers a way to persist this data. Kubernetes’ Container Storage Interface (CSI) allows third-party vendors to easily create storage solutions for containerized applications. Some Kubernetes Distributions build their own storage solutions while others integrate with existing third party solutions. Popular storage solutions for Kubernetes include: Amazon ElasticBlock Storage (EBS), GlusterFS, Portworx, Rook, OpenEBS among others.
Networking: Kubernetes applications are typically broken down into container-based microservices which are hosted in different PODs, running in different machines. Networking implementations allow for the seamless communication and interaction between different containerized components. Networking in Kubernetes is a herculean task, and each distribution may rely on a networking solution to facilitate communication between pods, services and the internet. Popular networking implementations include Flannel, Weave Net, Calico and Canal among others.
In order to offer our customers a better and more seamless experience while configuring, running, upgrading and troubleshooting our products while also avoiding compatibility issues between different distributions we decided to officially support ONLY ONE Kubernetes distribution: K3s. The main reasons for choosing K3s are:
Costs — K3s is 100% open source and there’s no need to pay for any expensive licenses.
Less setup overhead — a lot of time is saved when setting up a new environment because you don’t need to go through a lengthy process of acquiring extra licenses based on how many CPU cores you have. Also, K3s can be installed using only one command.
Easy to update — Thanks to its reduced dependencies.
Batteries included — CRI, CNI, service load balancer, and ingress controller are included.
Smaller attack surface — Thanks to its small size and reduced amount of dependencies.
Certified — K3s is an official CNCF project that delivers a powerful certified Kubernetes distribution.