The StackRox Kubernetes Security Platform includes services across three tiers. All services are deployed using standard orchestrator APIs, such as Kubernetes Deployments and DaemonSets.
The exact resource usage depends on the number of clusters you monitor, the number of nodes your monitor, and certain behavioral attributes of the containerized workloads you monitor. See the Sizing guidelines section for recommend values.
This topic outlines requested resources, and the limits that are applied. Actual usage may be lower than the Request, but won’t be more than the specified Limit.
Centralized services are deployed once and can monitor multiple separate clusters.
A single containerized service called Central handles data persistence, API interactions, UI access, and other functions. Only Central uses persistent storage.
Central requires persistent storage:
- You can provide storage with a PersistentVolumeClaim (pvc) or hostPath.
- Use the host-mounted storage only if all your hosts (or a group of hosts) mount a shared filesystem, such as an NFS share or a storage appliance. Otherwise, your data is only saved on a single node.
- We recommend using Solid-State Drives (SSDs) for best performance. However, you can use another storage type if you don’t have SSDs available.
The following table lists the minimum memory and storage values required to install and run Central. Refer to Central’s sizing guidelines section to view the recommended values.
For the StackRox Kubernetes Security Platform version 3.0.50 and newer
Central CPU Memory Storage Request 1.5 cores 4 GiB 100 GiB Limit 4 cores 8 GiB 100 GiB
For the StackRox Kubernetes Security Platform version 3.0.49 and older
Central CPU Memory Storage Request 1.5 cores 4 GiB 100 GiB Limit 2 cores 8 GiB 100 GiB
For deploying Central, we recommend that you use a machine type with 4 or more cores and apply scheduling policies to launch Central on such nodes.
We recommend the following compute resources and storage values depending upon the number of nodes in your cluster.
|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|
The StackRox Kubernetes Security Platform includes an image vulnerability scanner called StackRox Scanner. This service scans images that aren’t already scanned by scanners integrated into image registries.
For Scanner version 1.3.6 and older:
Scanner CPU Memory Request .5 cores 500 MiB Limit 2 cores 2000 MiB
For Scanner version 1.3.7 and newer:
Scanner CPU Memory Request 1.2 cores 2700 MiB Limit 5 cores 8000 MiB
With the StackRox Kubernetes Security Platform version 3.0.39 and older, you could optionally deploy monitoring services alongside Central. These services receive telemetry from StackRox services in monitored clusters. Sidecar containers are deployed alongside per-cluster and per-node services, which adds a nominal resource request to each (0.05 cores and 50 MiB of RAM).
|Request||.6 cores||600 MiB|
|Limit||1.2 cores||1200 MiB|
Central services may be deployed in a separate cluster of their own, or in a cluster used for other purposes. For security reasons, customers may wish to deploy these services in a cluster to which administrative access is limited.
Per-cluster services are deployed into each monitored cluster.
StackRox Sensor monitors your Kubernetes and OpenShift clusters. These services currently deploy in a single deployment, which handles interactions with the Kubernetes API and coordinates with Per-Node services.
Beginning from the StackRox Kubernetes Security Platform version 3.0.40, Sensor handles policy evaluation and deployment and image detection.
For the StackRox Kubernetes Security Platform version 3.0.44 and newer
Sensor CPU Memory Request 1 core 1 GiB Limit 2 cores 4 GiB
For the StackRox Kubernetes Security Platform version 3.0.43 and older
Sensor CPU Memory Request .5 cores 500 MiB Limit 1 core 1000 MiB
The StackRox 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.
To use admission controller enforcement on OpenShift, you need the StackRox Kubernetes Security Platform version 3.0.49 or newer.
|Request||.05 cores||100 MiB|
|Limit||.5 cores||500 MiB|
StackRox Collector monitors runtime activity on each node in your secured clusters. It connects to StackRox Sensor to report this information.
|Request||.05 cores||320 MiB|
|Limit||.75 cores||1 GiB|
Starting with the StackRox Kubernetes Security Platform version 188.8.131.52, Collector includes compliance data collection functions. In the StackRox Kubernetes Security Platform version 184.108.40.206 and older, a separate DaemonSet collects Compliance data. The resource requirements for Compliance are:
|Request||.1 cores||10 MiB|
|Limit||1 core||2 GiB|
Starting with the StackRox Kubernetes Security Platform version 220.127.116.11, Collector uses a mutable
image tag (
<version>-latest) so you get support for newer Linux kernel
versions more easily. We don’t change code, preexisting kernel modules, or eBPF
programs in image updates. We only add a single image layer with support for new
kernel versions published after the initial release. See the
Mutable image tags
section for more information.
We're happy to help! Reach out to us to discuss questions, issues, or feature requests.