Chapter 2. Default resource requirements for Red Hat Advanced Cluster Security for Kubernetes 2.1. General RHACS requirements Before you can install RHACS, your system must meet several requirements. Warning You must not install RHACS on: Amazon Elastic File System (Amazon EFS). Use the Amazon Elastic Block Store (Amazon EBS) with the default gp2 volume type instead. Older CPUs that do not have the Streaming SIMD Extensions (SSE) 4.2 instruction set. For example, Intel processors older than Sandy Bridge and AMD processors older than Bulldozer . These processors were released in 2011. To install RHACS, you must have one of the following systems: OpenShift Container Platform version 4.11 or later, and cluster nodes with a supported operating system of Red Hat Enterprise Linux CoreOS (RHCOS) or Red Hat Enterprise Linux (RHEL) A supported managed Kubernetes platform, and cluster nodes with a supported operating system of Amazon Linux, CentOS, Container-Optimized OS from Google, Red Hat Enterprise Linux CoreOS (RHCOS), Debian, Red Hat Enterprise Linux (RHEL), or Ubuntu For information about supported platforms and architecture, see the Red Hat Advanced Cluster Security for Kubernetes Support Matrix . For life cycle support information for RHACS, see the Red Hat Advanced Cluster Security for Kubernetes Support Policy . The following minimum requirements and suggestions apply to cluster nodes. Architecture amd64 , ppc64le , or s390x Note Starting with RHACS 4.3, both Central and secured cluster services are supported on IBM Power( ppc64le ), IBM Z( s390x ), and IBM(R) LinuxONE( s390x ) clusters. Processor 3 CPU cores are required. Memory 6 GiB of RAM is required. Note See the default memory and CPU requirements for each component and ensure that the node size can support them. Storage A persistent volume claim (PVC) is required on the cluster where Central is installed. It is strongly recommended on the secured clusters where Scanner V4 is enabled. Use Solid-State Drives (SSDs) for best performance. However, you can use another storage type if you do not have SSDs available. Important You must not use Ceph FS storage with Red Hat Advanced Cluster Security for Kubernetes. Red Hat recommends using RBD block mode PVCs for Red Hat Advanced Cluster Security for Kubernetes. If you plan to install RHACS by using Helm charts, you must meet the following requirements: You must have Helm command-line interface (CLI) v3.2 or newer, if you are installing or configuring RHACS using Helm charts. Use the helm version command to verify the version of Helm you have installed. You must have access to the Red Hat Container Registry. For information about downloading images from registry.redhat.io , see Red Hat Container Registry Authentication . 2.2. Central services (self-managed) Note If you are using Red Hat Advanced Cluster Security Cloud Service (RHACS Cloud Service), you do not need to review the requirements for Central services, because they are managed by Red Hat. You only need to look at the requirements for secured cluster services. Central services contain the following components: Central Scanner Scanner V4 (optional) 2.2.1. Central A containerized service called Central handles API interactions and RHACS web portal access while a containerized service called Central DB (PostgreSQL 13) handles data persistence. Central DB requires persistent storage in the cluster where Central is installed. You can provide storage with a persistent volume claim (PVC). Note You can use a hostPath volume for storage only if all your hosts (or a group of hosts) mount a shared file system, such as an NFS share or a storage appliance. Otherwise, your data is only saved on a single node. Red Hat does not recommend using a hostPath volume. Use Solid-State Drives (SSD) for best performance. However, you can use another storage type if you do not have SSDs available. If you use a web proxy or firewall, you must configure bypass rules to allow traffic for the definitions.stackrox.io domain and enable RHACS to trust your web proxy or firewall. Otherwise, updates for vulnerabilities will fail. You must also ensure that incoming connections from Sensor on secured clusters to Central on port 443 are possible. Red Hat Advanced Cluster Security for Kubernetes requires access to: definitions.stackrox.io for downloading updated vulnerability data. Vulnerability updates allow Red Hat Advanced Cluster Security for Kubernetes to maintain up-to-date vulnerability data when new vulnerabilities are discovered or additional data sources are added. Note For security reasons, you should deploy Central in a cluster with limited administrative access. CPU, memory, and storage requirements The following table lists the minimum CPU and memory values required to install and run Central. Central CPU Memory Request 1.5 cores 4 GiB Limit 4 cores 8 GiB Central requires Central DB to store data. The following table lists the minimum CPU, memory, and storage values required to install and run Central DB. Central DB CPU Memory Storage Request 4 cores 8 GiB 100 GiB Limit 8 cores 16 GiB 100 GiB 2.2.2. Scanner Scanner is responsible for scanning images, nodes, and the platform for vulnerabilities. Beginning with version 4.4, RHACS includes two image vulnerability scanners: StackRox Scanner and Scanner V4. StackRox Scanner is planned to be removed in a future release, but is still required at this time to perform node and platform scanning. Scanner V4 is the preferred image scanner because it provides additional features over the StackRox Scanner, such as expanded language and operating system support and data from additional vulnerability sources. CPU, memory, and storage requirements The following table lists the minimum CPU and memory values required to install and run Scanner. The requirements in this table are based on the default of 3 replicas. StackRox Scanner CPU Memory Request 3 cores 4500 MiB Limit 6 cores 12 GiB The StackRox Scanner requires Scanner DB (PostgreSQL 15) to store data. This data is not persisted. The following table lists the minimum CPU and memory values required to install and run Scanner DB. Scanner DB CPU Memory Request 0.2 cores 512 MiB Limit 2 cores 4 GiB 2.2.3. Scanner V4 Scanner V4 is the preferred image scanner because it provides additional features over the StackRox Scanner, such as expanded language and operating system support and data from additional vulnerability sources. CPU, memory, and storage requirements Scanner V4 Indexer The requirements in this table are based on the default of 3 replicas. Scanner V4 Indexer CPU Memory Request 3 cores 4500 MiB Limit 6 cores 9 GiB Scanner V4 Matcher The requirements in this table are based on the default of 2 replicas. Scanner V4 Matcher CPU Memory Request 2 cores 1000 MiB Limit 4 cores 4 GiB Scanner V4 DB Scanner V4 requires Scanner V4 DB (PostgreSQL 15) to store data. For Scanner V4 DB, a PVC is required to ensure optimal performance. The following table lists the minimum CPU, memory, and storage values required to install and run Scanner V4 DB. Scanner V4 DB CPU Memory Storage Request 0.2 cores 3 GiB 50 GiB Limit 2 cores 4 GiB 50 GiB 2.3. Secured cluster services Secured cluster services contain the following components: Sensor Admission controller Collector Scanner (optional) Scanner V4 (optional) If you use a web proxy or firewall, you must ensure that secured clusters and Central can communicate on HTTPS port 443. 2.3.1. Sensor Sensor monitors your Kubernetes and OpenShift Container Platform clusters. These services currently deploy in a single deployment, which handles interactions with the Kubernetes API and coordinates with the other Red Hat Advanced Cluster Security for Kubernetes components. CPU and memory requirements The following table lists the minimum CPU and memory values required to install and run sensor on secured clusters. Sensor CPU Memory Request 2 cores 4 GiB Limit 4 cores 8 GiB 2.3.2. Admission controller The Admission controller prevents users from creating workloads that violate policies you configure. CPU and memory requirements By default, the admission control service runs 3 replicas. The following table lists the request and limits for each replica. Admission controller CPU Memory Request 0.05 cores 100 MiB Limit 0.5 cores 500 MiB 2.3.3. Collector Collector monitors runtime activity on each node in your secured clusters as a DaemonSet. It connects to Sensor to report this information. The collector pod has three containers. The first container is collector, which monitors and reports the runtime activity on the node. The other two are compliance and node-inventory. Collection requirements To use the CORE_BPF collection method, the base kernel must support BTF, and the BTF file must be available to collector. In general, the kernel version must be later than 5.8 (4.18 for RHEL nodes) and the CONFIG_DEBUG_INFO_BTF configuration option must be set. Collector looks for the BTF file in the standard locations shown in the following list: Example 2.1. BTF file locations /sys/kernel/btf/vmlinux /boot/vmlinux-<kernel-version> /lib/modules/<kernel-version>/vmlinux-<kernel-version> /lib/modules/<kernel-version>/build/vmlinux /usr/lib/modules/<kernel-version>/kernel/vmlinux /usr/lib/debug/boot/vmlinux-<kernel-version> /usr/lib/debug/boot/vmlinux-<kernel-version>.debug /usr/lib/debug/lib/modules/<kernel-version>/vmlinux If any of these files exists, it is likely that the kernel has BTF support and CORE_BPF is configurable. CPU and memory requirements By default, the collector pod runs 3 containers. The following tables list the request and limits for each container and the total for each collector pod. Collector container Type CPU Memory Request 0.06 cores 320 MiB Limit 0.9 cores 1000 MiB Compliance container Type CPU Memory Request 0.01 cores 10 MiB Limit 1 core 2000 MiB Node-inventory container Type CPU Memory Request 0.01 cores 10 MiB Limit 1 core 500 MiB Total collector pod requirements Type CPU Memory Request 0.07 cores 340 MiB Limit 2.75 cores 3500 MiB 2.3.4. Scanner CPU and memory requirements The requirements in this table are based on the default of 3 replicas. StackRox Scanner CPU Memory Request 3 cores 4500 MiB Limit 6 cores 12 GiB The StackRox Scanner requires Scanner DB (PostgreSQL 15) to store data. The following table lists the minimum memory and storage values required to install and run Scanner DB. Scanner DB CPU Memory Request 0.2 cores 512 MiB Limit 2 cores 4 GiB 2.3.5. Scanner V4 Scanner V4 is optional. If Scanner V4 is installed on secured clusters, the following requirements apply. CPU, memory, and storage requirements Scanner V4 Indexer The requirements in this table are based on the default of 2 replicas. Scanner V4 Indexer CPU Memory Request 2 cores 3000 MiB Limit 4 cores 6 GiB Scanner V4 DB Scanner V4 requires Scanner V4 DB (PostgreSQL 15) to store data. The following table lists the minimum CPU, memory, and storage values required to install and run Scanner V4 DB. For Scanner V4 DB, a PVC is not required, but it is strongly recommended because it ensures optimal performance. Scanner V4 DB CPU Memory Storage Request 0.2 cores 2 GiB 10 GiB Limit 2 cores 4 GiB 10 GiB

Commands:
/sys/kernel/btf/vmlinux /boot/vmlinux-<kernel-version> /lib/modules/<kernel-version>/vmlinux-<kernel-version> /lib/modules/<kernel-version>/build/vmlinux /usr/lib/modules/<kernel-version>/kernel/vmlinux /usr/lib/debug/boot/vmlinux-<kernel-version> /usr/lib/debug/boot/vmlinux-<kernel-version>.debug /usr/lib/debug/lib/modules/<kernel-version>/vmlinux