Minimum System Requirements

This section summarizes the minimum infrastructure requirements for deploying the Forcepoint Data Security Posture Management (DSPM) platform and its optional add-on modules, based on the current internal sizing matrix. All values represent minimum starting points for a production deployment; additional capacity may be required depending on data volumes, enabled features, and integration scope.

Basic pre-requisites

Ensure the following items are in place and configured properly:

Domain Name Service (DNS) with public name resolution enabled.
Network Time Protocol (NTP)
Software Update Service- access to a network-based repository for software update packages.
Fixed private IPv4 address
Unique static host name

Operating System

The commands have been tested on following OS versions:

Ubuntu	24.04, 22.04
RHEL	8.x,9.x

Note: Only Server edition versions are supported. No Desktop Environment installed. No other Linux distributions are supported.

Other Requirements

Note: For hardened systems, see: Deploying Product in CIS hardened OS or K3s. Refer to the official K3s documentation and our troubleshooting guide for additional setup.

Ubuntu	disable ufw, systemd-resolved, apparmor /var partition should not have noexec flag
RHEL/CentOS/Oracle Linux	`firewalld` `systemctl disable firewalld --now` `fapolicyd` `systemctl disable fapolicyd.service` `nm-cloud-setup` `systemctl disable nm-cloud-setup.service nm-cloud-setup.timer reboot` If you are using a dedicated partition (/var/lib/rancher) to run K3s make sure to NOT have mounted it using `noexec` flag inside /etc/fstab file. Check FIPS mode If you have FIPS mode enabled is necessary to disable it otherwise some of our workloads running in K3s will crash at start up. To check if FIPS is enabled run: `sysctl crypto.fips_enabled` Value of 1 means FIPS mode is enabled, in order to disable, please refer to the steps as mentioned in below article: How to disable FIPS in RHEL/CentOS. Check if running iptables newer than 1.8.4 RHEL like systems have buggy version of iptables 1.8.4 which is causing issues with firewall, service routing and external network reachability as well as performance issues. It is required to configure k3s to use bundled version by modifying k3s service( same for k3s-agent service on worker nodes in HA deployments) file and adding --prefer-bundled-bin option to service’s cmd and restarting service. `~$ cat /etc/systemd/system/k3s.service ExecStart=/usr/local/bin/k3s \ server \ '--node-name=local-01' \ '--prefer-bundled-bin' \ ~$ sudo systemctl daemon-reload ~$ sudo systemctl stop k3s ~$ sudo systemctl start k3s ~$`

Ubuntu

disable ufw, systemd-resolved, apparmor
/var partition should not have noexec flag

RHEL/CentOS/Oracle Linux

firewalld
```
systemctl disable firewalld --now
```
fapolicyd
```
systemctl disable fapolicyd.service
```

nm-cloud-setup

systemctl disable nm-cloud-setup.service nm-cloud-setup.timer
reboot

If you are using a dedicated partition (/var/lib/rancher) to run K3s make sure to NOT have mounted it using noexec flag inside /etc/fstab file.
Check FIPS mode
If you have FIPS mode enabled is necessary to disable it otherwise some of our workloads running in K3s will crash at start up. To check if FIPS is enabled run:
```
sysctl crypto.fips_enabled
```
Value of 1 means FIPS mode is enabled, in order to disable, please refer to the steps as mentioned in below article: How to disable FIPS in RHEL/CentOS.
Check if running iptables newer than 1.8.4
RHEL like systems have buggy version of iptables 1.8.4 which is causing issues with firewall, service routing and external network reachability as well as performance issues. It is required to configure k3s to use bundled version by modifying k3s service( same for k3s-agent service on worker nodes in HA deployments) file and adding --prefer-bundled-bin option to service’s cmd and restarting service.
```
~$ cat  /etc/systemd/system/k3s.service
ExecStart=/usr/local/bin/k3s \
    server \
	'--node-name=local-01' \
	'--prefer-bundled-bin' \


~$ sudo systemctl daemon-reload
~$ sudo systemctl stop k3s
~$ sudo systemctl start k3s
~$
```

Also, firewalldnm-cloud-setup.service and nm-cloud-setup.timer must be disabled and the server must be restarted before the installation, click here for more information.

Hardware requirements

Note: Minimum requirement for the a single node Kubernetes cluster is one virtual machine for supporting up to 5000 users.

Note: Sizes mentioned below are meant to be sufficient for both structured and unstructured data.

Choosing a DSPM classification tier

DSPM offers two classification tiers. Advanced is the recommended tier for most deployments and should be your starting point unless you have a specific reason to choose otherwise.

DSPM Sizing	Advanced (Recommended)	Essential
Classification approach	Out-of-the-box DLP classifiers - deterministic outcomes.	AI-based small language models (AI Mesh)
Accuracy	Proven - mature, tuned rule sets, consistent and repeatable results	Sensitive to tuning; accuracy varies by data set
Tuning required	Minimal - works out of the box with mature rule sets	Ongoing tuning needed to reach and maintain target accuracy
Best suited for	Production environments requiring high classification accuracy at scale	Discovery and early-stage deployments
CPU	32 vCPUs	20 vCPUs
Memory	128 GB	80 GB
Hard Disk	1200 GB	1200 GB

Which tier should you choose?

Choose Advanced if you are deploying to production, need consistent and defensible classification results, or want the system to be effective immediately without a tuning cycle. The out-of-the-box DLP classifiers are mature and require minimal ongoing maintenance.
Choose Essential only for discovery exercises or early-stage deployments where you are exploring your data estate rather than enforcing policy. Plan for an ongoing tuning effort - accuracy on this tier depends on it, and the operational cost of that tuning typically outweighs the difference in hardware.

Additional requirements for each feature

Add-on	CPU (vCPUs)	Memory (GB)	Storage (GB)
FDC	4	16	500
DDR	8	16	500
Structured	12	32	500

Add-on values are cumulative with the tier sizing above. Add-ons can be enabled on either tier.

Sample configurations

These examples illustrate how to combine the component values to size a deployment.

Example 1 – Advanced tier (recommended), no add-ons

CPU: 32 vCPUs
Memory: 128 GB
Storage: 1200 GB

Example 2 – Advanced tier with FDC (recommended)

CPU: 36 vCPUs (32 + 4)
Memory: 144 GB (128 + 16)
Storage: 1700 GB (1200 + 500)

Example 3 – Advanced tier with FDC, DDR, and Structured

CPU: 56 vCPUs (32 + 4 + 8 + 12)
Memory: 192 GB (128 + 16 + 16 + 32)
Storage: 2700 GB (1200 + 500 + 500 + 500)

Use this approach to derive totals for any combination of add-ons.

Filesystem inode guidance

For deployments on filesystems with a specified inode limit, allocate at least 50 million inodes for the basic configuration.

Plan for an additional 25 million inodes for each additional component or add-on that is enabled to avoid inode exhaustion as the platform scales.

Capacity planning and review

The values in this document are minimum requirements intended to provide a safe starting point for initial deployment and proof-of-concept work.

During a PoC engagement and after that every six months of production use, customers should utilization to validate assumptions and adjust capacity as needed.

It is recommended to incorporate this utilization data into the organization’s standard capacity-planning process to ensure the platform can accommodate future data growth, additional connectors, and new use cases.

When in doubt, engage Forcepoint representatives or support to review sizing and growth plans before making major changes to the environment.

Storage and partition details

Only SSD storage is supported
Locally mounted storage is mandatory (NAS or network-attached storage is not supported).
Performance baseline (minimum):
- IOPS: ≥ 4,500 sustained
- Throughput: ≥ 250 MB/s sustained
- Latency: Low (< 1 ms typical for NVMe/SSD; NAS introduces bursty throttling and is unsuitable).
Recommended type: NVMe SSDs (preferred) or enterprise-grade locally mounted SSDs.
SWAP must be disabled
/ root requires at least 20GB
/var requires at least 20GB
/var/lib/rancher requires at least 500GB (in case of EDC, use the correct disk space according to the type of deployment shown above).
/tmp requires at least 75GB

Note:

if neither /var nor /var/lib/rancher /tmp is specifically assigned to a partition you must assign the full 500GB to root
if /var is specifically assign to a partition but /var/lib/rancher is not, then you must assign the 500GB to /var
if /var/lib/rancher is specifically assign to a partition but /var is not, then you must assign the 500GB to /var/lib/rancher

Networking Specifications

To download application artifacts (Docker images and binaries), updates, and configuration files, the cluster requires a public internet connection with a minimum download speed of 40 mbps and an upload speed of 8 mbps. For a faster initial setup, a download speed of 100 mbps or more is recommended. The cluster needs a public internet connection to download Docker images, binaries, updates, and configuration files.

K3s needs port 443/TCP open **inbound** and this is needed for any user accessing the dashboard and any endpoint where the agent wants to connect from. It does not have to be publicly accessible, if all users of dashboard / users of agents are on company VPN for example, then this port only needs to be open on the internal network.

Your network should be configured to allow the following public URLs to be accessible by the server over the outbound 443 (HTTPS) and HTTPS traffic bypassed (NOT intercepted) i.e. SSL inspection must be disabled:

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. Only required during K3s install and only on RHEL systems)
https://agents.master.k3s.getvisibility.com (Agent client binaries and OfficeAddins)
https://api.master.k3s.getvisibility.com (Private API server)
https://rancher.$RESELLER_NAME.k3s.getvisibility.com (Rancher management server, $RESELLER_NAME, depending on license/reseller will be one of: master, forcepointemea, fpemea, forcepointapac, forcepointus, saas, forcepointpocemea, forcepointpocapac, forcepointpocus)

https://registry2.getvisibility.com/content/artifacts

Note: K3s running on the customer server might try to reach to "git.rancher.io" since it is the default hard-coded repository, but we have our own private repository with all our charts. So, it is ok, to block it as we cannot disable it.

Downloads

Note: Below file downloads are also needed for Rancher and helm online type of deployments.

Download following file sets:

Custom K3s installation files: https://assets.master.k3s.getvisibility.com
Private Docker registry: https://images.master.k3s.getvisibility.com
Private Helm registry: https://charts.master.k3s.getvisibility.com
Docker registry AWS CDN: https://prod-eu-west-1-starport-layer-bucket.s3.eu-west-1.amazonaws.com
Rancher RPM repo for configuring SELinux packages on RHEL or CentOS: https://rpm.rancher.io
Private API server: https://api.master.k3s.getvisibility.com
Rancher management server: https://rancher.master.k3s.getvisibility.com
Forcepoint locations:

K3s and Antivirus

It is recommended to disable antivirus or any other third party software before proceeding with installation. See section Degraded performance due to Antivirus for issues when antivirus is not disabled.