---

title: "System and technical requirements when installing KSPM"description: "This section includes system and technical requirements for Kubernetes clusters when installing Kubernetes® Security Posture Management (KSPM) in Security Deck."title: "System and technical requirements when installing KSPM"
description: "This section includes system and technical requirements for Kubernetes clusters when installing Kubernetes® Security Posture Management (KSPM) in Security Deck."

System and technical requirements

Before onboarding clusters to KSPM, make sure they meet the minimum requirements.

Technical requirementsTechnical requirements

To install the KSPM components, the resources available in the cluster must meet the following technical requirements:

• Kubernetes 1.30 or higher.
• There is no Kyverno-based admission control in the Kubernetes cluster. If Kyverno was previously deployed, remove it along with all CustomResourceDefinition resources it has created.
• Networking must be set up between the Kubernetes cluster nodes and Yandex Container Registry.
• Network access must be allowed on port 54321 from the pod running a runtime security monitoring sensor to the cluster pods.
• TCP access from the cluster to the KSPM API (kspm.api.cloud.yandex.net) must be allowed on port 443.
• Security groups must allow access from the cluster’s master node to KSPM components running on the cluster nodes.

System requirementsSystem requirements

To install the KSPM components, the resources available in the cluster must meet the minimum system requirements.

Requirements for the cluster node groupRequirements for the cluster node group

Number of nodes	CPU, requests (Admission + Runtime sensor)	Memory, requests (Admission + Runtime sensor)
2	2 vCPU	4 GB

Resource usage by KSPM componentsResource usage by KSPM components

Installing KSPM in a Managed Service for Kubernetes cluster deploys several components in the cluster. The tables below list these components and the minimum amount of cluster resources reserved for each of them. However, actual resource usage may be higher depending on the load.

Admission components (Kyverno and admission reporter)

These components run in a fixed number of replicas and do not depend on the number of nodes in the cluster.

Component	Replicas	CPU, requests 1	Memory, requests
kyverno-admission-controller	3	—	512 MB × 3
kyverno-background-controller	1	100m	64 MB
kyverno-cleanup-controller	1	100m	64 MB
kyverno-reports-controller	1	100m	64 MB
admission-reporter	1	100m	64 MB
Total		400m	1.75 GB

¹ The values are specified in thousandths of a vCPU (millicores).

Runtime sensor components (Tetragon)

Some of these components run in a fixed number of replicas and do not depend on the number of nodes in the cluster, while others run on every cluster node as DaemonSet.

Component	Replicas	CPU, requests	Memory, requests
runtime-sensor-operator	1	10m	64 MB
runtime-sensor-agent	1	50m	256 MB
tetragon (DaemonSet, per node)	×N	200m	256 MB
tetragon-server-proxy (DaemonSet, per node)	×N	—	—
Total (fixed portion)		60m	320 MB

Kube-bench component

kube-bench-reporter runs on each cluster node as DaemonSet.

Component	Replicas	CPU, requests	Memory, requests
kube-bench-reporter (DaemonSet, per node)	×N	50m	128 MB

osquery components

The osquery-agent and osqueryd components run within one DaemonSet on each cluster node.

Component	Replicas	CPU, requests	Memory, requests
osquery-agent	xN	20m	64 MB
osqueryd	xN	50m	128 MB

Useful linksUseful links

Kubernetes® Security Posture Management (KSPM)