System Requirements

Component	# of Instances	Recommended vCPU	Minimum Memory	Notes
Controller	min. 1 3 for HA (odd # only)	1	1GB	vCPU core may be shared
Enforcer	1 per node/VM	1+	1GB	One or more dedicated vCPU for higher network throughput in Protect mode
Scanner	min. 1 2+ for HA/Performance	1	1GB	CPU core may be shared for standard workloads. Dedicate 1 or more CPU for high volume (10k+) image scanning. Registry image scanning is performed by the scanner and managed by the controller and the image is pulled by the scanner and expanded in memory. The minimum memory recommendation assumes images to be scanned are not larger than .5GB. When scanning images larger than 1GB, scanner memory should be calculated by taking the largest image size and adding .5GB. Example - largest image size = 1.3GB, the scanner container memory should be 1.8GB
Manager	min 1 2+ for HA	1	1GB	vCPU may be shared

Component

# of Instances

Recommended vCPU

Minimum Memory

Notes

Controller

min. 1
3 for HA (odd # only)

1GB

vCPU core may be shared

Enforcer

1 per node/VM

1GB

One or more dedicated vCPU for higher network throughput in Protect mode

Scanner

min. 1
2+ for HA/Performance

1GB

CPU core may be shared for standard workloads.
Dedicate 1 or more CPU for high volume (10k+) image scanning.
Registry image scanning is performed by the scanner and managed by the controller and the image is pulled by the scanner and expanded in memory.
The minimum memory recommendation assumes images to be scanned are not larger than .5GB.
When scanning images larger than 1GB, scanner memory should be calculated by taking the largest image size and adding .5GB.
Example - largest image size = 1.3GB, the scanner container memory should be 1.8GB

Manager

min 1
2+ for HA

1GB

vCPU may be shared

For configuration backup/HA, a RWX PVC of 1Gi or more. See Backups and Persistent Data section for more details.
Recommended browser: Chrome for better performance

Supported Platforms

Officially supported linux distributions, SUSE Linux, Ubuntu, CentOS/Red Hat (RHEL), Debian, CoreOS, AWS Bottlerocket and Photon.
AMD64 and Arm architectures
CoreOS is supported (November 2023) for CVE scanning through RHEL mapping table provided by RedHat. Once an official feed is published by RedHat for CoreOS it will be supported.
Officially supported Kubernetes and Docker compliant container management systems. The following platforms are tested with every release of SUSE® Security: Kubernetes 1.19-1.30, SUSE Rancher (RKE, RKE2, K3s etc), RedHat OpenShift 4.6-4.14 (3.x to 4.12 supported prior to SUSE® Security 5.2.x), Google GKE, Amazon EKS, Microsoft Azure AKS, IBM IKS, native docker, docker swarm. The following Kubernetes and docker compliant platforms are supported and have been verified to work with SUSE® Security: VMware Photon and Tanzu, SUSE CaaS, Oracle OKE, Mirantis Kubernetes Engine, Nutanix Kubernetes Engine, docker UCP/DataCenter, docker Cloud.
Docker run-time version: 1.9.0 and up; Docker API version: 1.21, CE and EE.
Containerd and CRI-O run-times (requires changes to volume paths in sample yamls). See changes required for Containerd in the Kubernetes deployment section and CRI-O in the OpenShift deployment section.
SUSE® Security is compatible with most commercially supported CNI’s. Officially tested and supported are openshift ovs (subnet/multitenant), calico, flannel, cilium, antrea and public clouds (gke, aks, iks, eks). Note: The multus cni is not currently supported but is on the 2024 roadmap.
Console: Chrome or Firefox browser recommended. IE 11 not supported due to performance issues.
Minikube is supported for simple initial evaluation but not for full proof of concept. See below for changes required for the Allinone yaml to run on Minikube.

AWS Bottlerocket Note: Must change path of the containerd socket specific to Bottleneck. Please see Kubernetes deployment section for details.

Not Supported

GKE Autopilot.
The multus cni is not currently supported but is on the 2024 roadmap.
AWS ECS is no longer supported. (NOTE: No functionality has been actively removed for operating SUSE® Security on ECS deployments. However, testing on ECS is no longer being perfromed by SUSE. While protecting ECS workloads with SUSE® Security likely will operate as expected, issues will not be investigated.)
Docker on Mac
Docker on Windows
Rkt (container linux) from CoreOS
AppArmor on K3S / SLES environments. Certain configurations may conflict with SUSE® Security and cause scanner errors; AppArmor should be disabled when deploying SUSE® Security.
IPv6 is not supported
VMWare Integrated Containers (VIC) except in nested mode
CloudFoundry
Console: IE 11 not supported due to performance issues.
Nested container host in a container tools used for simple testing. For example, deployment of a Kubernetes cluster using 'kind' https://kind.sigs.k8s.io/docs/user/configuration/.

PKS is field tested and requires enabling privileged containers to the plan/tile, and changing the yaml hostPath as follows for Allinone, Controller, Enforcer:

            hostPath:
            path: /var/vcap/sys/run/docker/docker.sock

SUSE® Security supports running on linux-based VMs on Mac/Windows using Vagrant, VirtualBox, VMware or other virtualized environments.

Minikube

Please make the following changes to the Allinone deployment yaml.

apiVersion: apps/v1 <<-- required for k8s 1.19
kind: DaemonSet
metadata:
 name: neuvector-allinone-pod
 namespace: neuvector
spec:
 selector: <-- Added
 matchLabels: <-- Added
 app: neuvector-allinone-pod <-- Added
 minReadySeconds: 60
...
 nodeSelector: <-- DELETE THIS LINE
 nvallinone: "true" <-- DELETE THIS LINE
apiVersion: apps/v1 <<-- required for k8s 1.19
kind: DaemonSet
metadata:
 name: neuvector-enforcer-pod
 namespace: neuvector
spec:
 selector: <-- Added
 matchLabels: <-- Added
 app: neuvector-enforcer-pod <-- Added

Performance and Scaling

As always, performance planning for SUSE® Security containers will depend on several factors, including:

(Controller & Scanner) Number and size of images in registry to be scanned (by Scanner) initially
(Enforcer) Services mode (Discover, Monitor, Protect), where Protect mode runs as an inline firewall
(Enforcer) Type of network connections for workloads in Protect mode

In Monitor mode (network filtering similar to a mirror/tap), there is no performance impact and the Enforcer handles traffic at line speed, generating alerts as needed. In Protect mode (inline firewall), the Enforcer requires CPU and memory to filter connections with deep packet inspection and hold them to determine whether they should be blocked/dropped. Generally, with 1GB of memory and a shared CPU, the Enforcer should be able to handle most environments while in Protect mode.

For throughput or latency sensitive environments, additional memory and/or a dedicated CPU core can be allocated to the SUSE® Security Enforcer container.

For performance tuning of the Controller and Scanner for registry scanning, see System Requirements above.

For additional advice on performance and sizing, see the Onboarding/Best Practices section.

Throughput

As the chart below shows, basic throughput benchmark tests showed a maximum throughput of 1.3 Gbps PER NODE on a small public cloud instance with 4 CPU cores. For example, a 10 node cluster would then be able to handle a maximum of 13 Gbps of throughput for the entire cluster for services in Protect mode.

Throughput

This throughput would be projected to scale up as dedicated a CPU is assigned to the Enforcer, or the CPU speed changes, and/or additional memory is allocated. Again, the scaling will be dependent on the type of network/application traffic of the workloads.

Latency

Latency is another performance metric which depends on the type of network connections. Similar to throughput, latency is not affected in Monitor mode, only for services in Protect (inline firewall) mode. Small packets or simple/fast services will generate a higher latency by SUSE® Security as a percentage, while larger packets or services requiring complex processing will show a lower percentage of added latency by the SUSE® Security enforcer.

The table below shows the average latency of 2-10% benchmarked using the Redis benchmark tool. The Redis Benchmark uses fairly small packets, so the the latency with larger packets would expected to be lower.

Test	Monitor	Protect	Latency
PING_INLINE	34,904	31,603	9.46%
SET	38,618	36,157	6.37%
GET	36,055	35,184	2.42%
LPUSH	39,853	35,994	9.68%
RPUSH	37,685	36,010	4.45%
LPUSH (LRANGE Benchmark)	37,399	35,220	5.83%
LRANGE_100	25,539	23,906	6.39%
LRANGE_300	13,082	12,277	6.15%

The benchmark above shows average TPS of Protect mode versus Monitor mode, and the latency added for Protect mode for several tests in the benchmark. The main way to lower the actual latency (microseconds) in Protect mode is to run on a system with a faster CPU. You can find more details on this open source Redis benchmark tool at https://redis.io/topics/benchmarks.