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.
|Request||1.5 cores||4 GiB||100 GiB|
|Limit||4 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.
|Request||1.2 cores||2700 MiB|
|Limit||5 cores||8000 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.
|Request||1 core||1 GiB|
|Limit||2 cores||4 GiB|
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.
|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|
Collector includes compliance data collection functions. The resource requirements for Compliance are:
|Request||.1 cores||10 MiB|
|Limit||1 core||2 GiB|
We're happy to help! Reach out to us to discuss questions, issues, or feature requests.