Before installing RHACS on other platforms such as Amazon Elastic Kubernetes Service (Amazon EKS), Google Kubernetes Engine (Google GKE), and Microsoft Azure Kubernetes Service (Microsoft AKS), ensure that you have met the prerequisites.
RHACS has some system requirements that must be met before installing.
You must not install Red Hat Advanced Cluster Security for Kubernetes on:
|
To install Red Hat Advanced Cluster Security for Kubernetes, you must have:
A supported managed Kubernetes platform. For more information, see Red Hat Advanced Cluster Security for Kubernetes Support Policy.
Cluster nodes with a supported operating system:
Operating system: Amazon Linux, CentOS, Container-Optimized OS from Google, Red Hat Enterprise Linux CoreOS (RHCOS), Debian, Red Hat Enterprise Linux (RHEL), or Ubuntu.
Processor and memory: 2 CPU cores and at least 3GiB of RAM.
For deploying Central, use a machine type with four or more cores and apply scheduling policies to launch Central on such nodes. |
Architectures: AMD64, ppc64le, or s390x.
For ppc64le, or s390x architectures, you can only install RHACS Secured cluster services on IBM Power, IBM zSystems, and IBM® LinuxONE clusters. Central is not supported at this time. |
Persistent storage by using persistent volume claim (PVC).
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. |
Use Solid-State Drives (SSDs) for best performance. However, you can use another storage type if you do not have SSDs available.
To install using Helm charts:
You must have Helm command-line interface (CLI) v3.2 or newer, if you are installing or configuring Red Hat Advanced Cluster Security for Kubernetes 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.
A containerized service called Central handles API interactions and user interface (Portal) access while a containerized service called Central DB (PostgreSQL 13) handles data persistence.
Both Central and Central DB require persistent storage:
You can provide storage with a persistent volume claim (PVC).
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
and collector-modules.stackrox.io
domains and enable Red Hat Advanced Cluster Security for Kubernetes to trust your web proxy or firewall. Otherwise, updates for vulnerability definitions and kernel support packages will fail.
Red Hat Advanced Cluster Security for Kubernetes requires access to:
definitions.stackrox.io
for downloading updated vulnerability definitions. Vulnerability definition 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.
collector-modules.stackrox.io
to download updated kernel support packages. Updated Kernel support packages ensure that Red Hat Advanced Cluster Security for Kubernetes can monitor the latest operating systems and collect data about the network traffic and processes running inside the containers. Without these updates, Red Hat Advanced Cluster Security for Kubernetes might fail to monitor containers if you add new nodes in your cluster or if you update your nodes' operating system.
For security reasons, you should deploy Central in a cluster with limited administrative access. |
The following table lists the minimum memory and storage values required to install and run Central.
Central | CPU | Memory | Storage |
---|---|---|---|
Request |
1.5 cores |
4 GiB |
100 GiB |
Limit |
4 cores |
8 GiB |
100 GiB |
Central DB | CPU | Memory | Storage |
---|---|---|---|
Request |
4 cores |
8 GiB |
100 GiB |
Limit |
8 cores |
16 GiB |
100 GiB |
Use the following compute resources and storage values depending upon the number of nodes in your cluster.
Nodes | Deployments | Central CPU | Central Memory | Central Storage |
---|---|---|---|---|
Up to 100 |
Up to 1000 |
2 cores |
4 GiB |
100 GiB |
Up to 500 |
Up to 2000 |
4 cores |
8 GiB |
100 GiB |
More than 500 |
More than 2000 |
8 cores |
12 - 16 GiB |
100 - 200 GiB |
Nodes | Deployments | Central DB CPU | Central DB Memory | Central DB Storage |
---|---|---|---|---|
Up to 100 |
Up to 1000 |
2 cores |
4 GiB |
100 GiB |
Up to 500 |
Up to 2000 |
4 cores |
8 GiB |
100 GiB |
More than 500 |
More than 2000 |
8 cores |
12 - 16 GiB |
100 - 200 GiB |
Red Hat Advanced Cluster Security for Kubernetes includes an image vulnerability scanner called Scanner. This service scans images that are not already scanned by scanners integrated into image registries.
Scanner | CPU | Memory |
---|---|---|
Request |
1.2 cores |
2700 MiB |
Limit |
5 cores |
8000 MiB |
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 Collector.
Sensor | CPU | Memory |
---|---|---|
Request |
2 cores |
4 GiB |
Limit |
4 cores |
8 GiB |
The Admission controller prevents users from creating workloads that violate policies you configure.
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 |
.05 cores |
100 MiB |
Limit |
.5 cores |
500 MiB |
Collector monitors runtime activity on each node in your secured clusters. It connects to Sensor to report this information.
To install Collector on systems that have Unified Extensible Firmware Interface (UEFI) and that have Secure Boot enabled, you must use eBPF probes because kernel modules are unsigned, and the UEFI firmware cannot load unsigned packages. Collector identifies Secure Boot status at the start and switches to eBPF probes if required. |
Collector | CPU | Memory |
---|---|---|
Request |
.05 cores |
320 MiB |
Limit |
.75 cores |
1 GiB |
Collector uses a mutable image tag ( |