Yandex Cloud
Search
Discuss with expertTry it for free
  • Customer Stories
  • Documentation
  • Blog
  • All Services
    • Cloud Interconnect
    • Cloud Backup
    • Cloud Registry
    • Yandex AI Studio
    • Compute Cloud
    • Object Storage
    • Managed Service for Kubernetes®
    • Yandex BareMetal
    • Smart Web Security
    • Security Deck
    • Managed Service for PostgreSQL
    • Managed Service for ClickHouse®
    • Monium
    • Cloud CDN
    • Network Load Balancer
    • Virtual Private Cloud
    • Cloud DNS
    • Application Load Balancer
    • Yandex Cloud Video
    • Stackland
    • Yandex Cloud Router
    • Yandex Managed Service for Trino
    • Managed Service for MySQL®
    • Managed Service for Valkey™
    • Managed Service for Apache Spark™
    • Yandex StoreDoc
    • Managed Service for OpenSearch
    • Managed Service for Apache Kafka®
    • Data Transfer
    • Yandex MPP Analytics Engine for PostgreSQL
    • Yandex Managed Service for Apache Airflow®
    • Data Processing
    • Yandex MetaData Hub
    • Managed Service for YDB
    • Managed Service for Sharded PostgreSQL
    • Managed Service for YTsaurus
    • Yandex WebSQL
    • DataLens
    • Yandex Search API
    • SpeechSense
    • SpeechKit
    • DataSphere
    • Vision OCR
    • Translate
    • Yandex Identity Hub
    • Key Management Service
    • Certificate Manager
    • Yandex Lockbox
    • Audit Trails
    • SmartCaptcha
    • Cloud Desktop
    • Yandex SIEM
    • SourceCraft Code Assistant
    • Container Registry
    • Managed Service for GitLab
    • Managed Service for Prometheus®
    • Cloud Functions
    • API Gateway
    • Yandex Cloud Postbox
    • Message Queue
    • Serverless Integrations
    • IoT Core
    • Data Streams
    • Serverless Containers
    • Cloud Notification Service
    • Yandex Query
    • Identity and Access Management
    • Yandex Cloud Console
    • Resource Manager
    • Yandex Cloud Billing
    • Yandex Cloud Quota Manager
    • Cloud Apps
  • System Status
  • Marketplace
    • Featured
    • Infrastructure & Network
    • Data Platform
    • AI for business
    • Security
    • DevOps tools
    • Serverless
    • Monitoring & Resources
  • All Solutions
    • By industry
    • By use case
    • Economics and Pricing
    • Security
    • Technical Support
    • Start testing with double trial credits
    • Cloud credits to scale your IT product
    • Gateway to Russia
    • Cloud for Startups
    • Center for Technologies and Society
    • Yandex Cloud Partner program
    • Price calculator
    • Pricing plans
  • Customer Stories
  • Documentation
  • Blog
© 2026 Direct Cursus Technology L.L.C.
Yandex Security Deck
  • Pricing policy
    • Overview
    • All rules
    • CSPM
    • KSPM
  • Audit Trails events
  • Release notes

In this article:

  • KSPM — Kubernetes® Security Posture Management
  • Restrictive permissions for Kubelet service file are set
  • Kubelet service file ownership is set to root:root
  • Restrictive permissions for kubeconfig configuration file are set
  • The owner of kubeconfig configuration file is set to root:root
  • Restrictive permissions for Kubelet configuration file are set
  • The owner of Kubelet configuration file is set to root:root
  • Requests from anonymous users to Kubelet server are disabled
  • Only explicitly authorized requests to Kubelet server are allowed
  • Kubelet authentication via certificates is enabled
  • Kubelet is allowed to manage iptables
  • Kubelet client certificate rotation is enabled
  • OS-level AppArmor inventory
  • OS-level installed package inventory
  • OS-level APT repository inventory
  • Base OS property inventory
  • OS kernel inventory
  • OS user login inventory
  • OS-level network settings inventory
  • OS process inventory
  • OS-level seccomp event inventory
  • Osquery agent self-monitoring inventory
  • OS-level shared memory inventory
  • OS-level sysctl parameter inventory
  • OS-level user inventory
  1. Rule reference
  2. KSPM
Written by
Yandex Cloud
Updated at September 11, 2026
View in Markdown
  • KSPM — Kubernetes® Security Posture Management
    • Restrictive permissions for Kubelet service file are set
    • Kubelet service file ownership is set to root:root
    • Restrictive permissions for kubeconfig configuration file are set
    • The owner of kubeconfig configuration file is set to root:root
    • Restrictive permissions for Kubelet configuration file are set
    • The owner of Kubelet configuration file is set to root:root
    • Requests from anonymous users to Kubelet server are disabled
    • Only explicitly authorized requests to Kubelet server are allowed
    • Kubelet authentication via certificates is enabled
    • Kubelet is allowed to manage iptables
    • Kubelet client certificate rotation is enabled
    • OS-level AppArmor inventory
    • OS-level installed package inventory
    • OS-level APT repository inventory
    • Base OS property inventory
    • OS kernel inventory
    • OS user login inventory
    • OS-level network settings inventory
    • OS process inventory
    • OS-level seccomp event inventory
    • Osquery agent self-monitoring inventory
    • OS-level shared memory inventory
    • OS-level sysctl parameter inventory
    • OS-level user inventory

KSPM — Kubernetes® Security Posture ManagementKSPM — Kubernetes® Security Posture Management

Rules for checking Kubernetes cluster configuration.

Restrictive permissions for Kubelet service file are setRestrictive permissions for Kubelet service file are set

kind

severity

ID

HostSecurity

Medium

host-security.kubelet-service-file-perm-600

DescriptionDescription

The kubelet service file controls various parameters that set the behavior of the kubelet service in the worker node.
You should restrict its file permissions to maintain the integrity of the file.
The file should be writable by only the administrators on the system.

RecommendationsRecommendations

To perform the audit manually:

Run the below command (based on the file location on your system) on the each worker node.
For example:

stat -c %a /etc/systemd/system/kubelet.service.d/kubeadm.conf

Verify that the permissions are set as 600 or more restrictive.

Remediation:

Run the below command (based on the file location on your system) on the each worker node.
For example:

chmod 600 /etc/systemd/system/kubelet.service.d/kubeadm.conf

Kubelet service file ownership is set to root:rootKubelet service file ownership is set to root:root

kind

severity

ID

HostSecurity

Medium

host-security.kubelet-service-file-owner-root

DescriptionDescription

The kubelet service file controls various parameters that set the behavior of the kubelet service in the worker node.
You should set its file ownership to maintain the integrity of the file.
The file should be owned by root:root.

RecommendationsRecommendations

To perform the audit manually:

Run the below command (based on the file location on your system) on the each worker node.
For example:

stat -c %U:%G /etc/systemd/system/kubelet.service.d/kubeadm.conf

Verify that the ownership is set to root:root.

Remediation:

Run the below command (based on the file location on your system) on the each worker node.
For example:

chown root:root /etc/systemd/system/kubelet.service.d/kubeadm.conf

Restrictive permissions for kubeconfig configuration file are setRestrictive permissions for kubeconfig configuration file are set

kind

severity

ID

HostSecurity

Medium

host-security.kubelet-conf-600

DescriptionDescription

The kubelet.conf file is the kubeconfig file for the node. It controls various parameters that set the behavior and identity of the worker node.
You should restrict its file permissions to maintain the integrity of the file.
The file should be writable by only the administrators on the system.

RecommendationsRecommendations

To perform the audit manually:

Run the below command (based on the file location on your system) on the each worker node.
For example:

stat -c %a /etc/kubernetes/kubelet.conf

Verify that the permissions are 600 or more restrictive.

Remediation:

Run the below command (based on the file location on your system) on the each worker node.
For example:

chmod 600 /etc/kubernetes/kubelet.conf

The owner of kubeconfig configuration file is set to root:rootThe owner of kubeconfig configuration file is set to root:root

kind

severity

ID

HostSecurity

Medium

host-security.kubelet-conf-owner-root

DescriptionDescription

The kubelet.conf file is the kubeconfig file for the node. It controls various parameters that set the behavior and identity of the worker node.
You should set its file ownership to maintain the integrity of the file.
The file should be owned by root:root.

RecommendationsRecommendations

To perform the audit manually:

Run the below command (based on the file location on your system) on the each worker node.
For example:

stat -c %U:%G /etc/kubernetes/kubelet.conf

Verify that the ownership is set to root:root.

Remediation:

Run the below command (based on the file location on your system) on the each worker node.
For example:

chown root:root /etc/kubernetes/kubelet.conf

Restrictive permissions for Kubelet configuration file are setRestrictive permissions for Kubelet configuration file are set

kind

severity

ID

HostSecurity

Medium

host-security.kubelet-config-permissions-600

DescriptionDescription

Ensure that if the kubelet refers to a configuration file with the --config argument, that file has permissions of 600 or more restrictive.
The kubelet reads various parameters, including security settings, from a config file specified by the --config argument.
If this file is specified, you should restrict its file permissions to maintain the integrity of the file.
The file should be writable by only the administrators on the system.

RecommendationsRecommendations

To perform the audit manually:

Run the below command (based on the file location on your system) on the each worker node.
For example:

stat -c %a /var/lib/kubelet/config.yaml

Verify that the permissions are set as 600 or more restrictive.

Remediation:

Run the following command (using the config file location identified in the Audit step):

chmod 600 /var/lib/kubelet/config.yaml

The owner of Kubelet configuration file is set to root:rootThe owner of Kubelet configuration file is set to root:root

kind

severity

ID

HostSecurity

Medium

host-security.kubelet-config-owner-root

DescriptionDescription

Ensure that if the kubelet refers to a configuration file with the --config argument, that file is owned by root:root.
The kubelet reads various parameters, including security settings, from a config file specified by the --config argument.
If this file is specified, you should restrict its file permissions to maintain the integrity of the file.
The file should be owned by root:root.

RecommendationsRecommendations

To perform the audit manually:

Run the below command (based on the file location on your system) on the each worker node.
For example:

stat -c %U:%G /var/lib/kubelet/config.yaml

Verify that the ownership is set to root:root.

Remediation:

Run the following command (using the config file location identied in the Audit step):

chown root:root /etc/kubernetes/kubelet.conf

Requests from anonymous users to Kubelet server are disabledRequests from anonymous users to Kubelet server are disabled

kind

severity

ID

HostSecurity

Medium

host-security.anonymous-auth-false

DescriptionDescription

Disable anonymous requests to the Kubelet server.
When enabled, requests that are not rejected by other configured authentication methods are treated as anonymous requests.
These requests are then served by the Kubelet server.
You should rely on authentication to authorize access and disallow anonymous requests.

RecommendationsRecommendations

To perform the audit manually:

If using a Kubelet configuration file, check that there is an entry for authentication: anonymous: enabled set to false.
Run the following command on each node:

ps -ef | grep kubelet

Verify that the --anonymous-auth argument is set to false.
This executable argument may be omitted, provided there is a corresponding entry set to false in the Kubelet config file.

Remediation:

If using a Kubelet config file, edit the file to set authentication: anonymous: enabled to false.
If using executable arguments, edit the kubelet service file /etc/kubernetes/kubelet.conf on each worker node and set the below parameter in KUBELET_SYSTEM_PODS_ARGS variable:
--anonymous-auth=false
Based on your system, restart the kubelet service. For example:

systemctl daemon-reload
systemctl restart kubelet.service

Only explicitly authorized requests to Kubelet server are allowedOnly explicitly authorized requests to Kubelet server are allowed

kind

severity

ID

HostSecurity

Medium

host-security.auth-mode-not-always-allow

DescriptionDescription

Do not allow all requests. Enable explicit authorization.
Kubelets, by default, allow all authenticated requests (even anonymous ones) without needing explicit authorization checks from the apiserver.
You should restrict this behavior and only allow explicitly authorized requests.

RecommendationsRecommendations

To perform the audit manually:

Run the following command on each node:

ps -ef | grep kubelet

If the --authorization-mode argument is present, check that it is not set to AlwaysAllow.
If it is not present, check that there is a Kubelet config file specified by --config, and that file sets authorization: mode to something other than AlwaysAllow.
It is also possible to review the running configuration of a Kubelet via the /configz endpoint on the Kubelet API port (typically 10250/TCP).
Accessing these with appropriate credentials will provide details of the Kubelet's configuration.

Remediation:

If using a Kubelet config file, edit the file to set authorization: mode to Webhook.
If using executable arguments, edit the kubelet service file /etc/kubernetes/kubelet.conf on each worker node and set the below parameter in KUBELET_AUTHZ_ARGS variable:
--authorization-mode=Webhook
Based on your system, restart the kubelet service.
For example:

systemctl daemon-reload
systemctl restart kubelet.service

Kubelet authentication via certificates is enabledKubelet authentication via certificates is enabled

kind

severity

ID

HostSecurity

Medium

host-security.client-ca-file-set

DescriptionDescription

Enable Kubelet authentication using certificates.
The connections from the apiserver to the kubelet are used for fetching logs for pods, attaching (through kubectl) to running pods, and using the kubelet's port-forwarding functionality.
These connections terminate at the kubelet's HTTPS endpoint.
By default, the apiserver does not verify the kubelet's serving certificate, which makes the connection subject to man-in-the-middle attacks, and unsafe to run over untrusted and/or public networks.
Enabling Kubelet certificate authentication ensures that the apiserver could authenticate the Kubelet before submitting any requests.

RecommendationsRecommendations

To perform the audit manually:

Run the following command on each node:

ps -ef | grep kubelet

Verify that the --client-ca-file argument exists and is set to the location of the client certificate authority file.
If the --client-ca-file argument is not present, check that there is a Kubelet config file specified by --config, and that the file sets authentication: x509: clientCAFile to the location of the client certificate authority file.

Remediation:

If using a Kubelet config file, edit the file to set authentication: x509: clientCAFile to the location of the client CA file.
If using command line arguments, edit the kubelet service file /etc/kubernetes/kubelet.conf on each worker node and set the below parameter in KUBELET_AUTHZ_ARGS variable:
--client-ca-file=<path/to/client-ca-file>
Based on your system, restart the kubelet service.
For example:

systemctl daemon-reload
systemctl restart kubelet.service

Kubelet is allowed to manage iptablesKubelet is allowed to manage iptables

kind

severity

ID

HostSecurity

Medium

host-security.make-iptables-util-chains-true

DescriptionDescription

Allow Kubelet to manage iptables.
Kubelets can automatically manage the required changes to iptables based on how you choose your networking options for the pods.
It is recommended to let kubelets manage the changes to iptables.
This ensures that the iptables configuration remains in sync with pods networking configuration.
Manually configuring iptables with dynamic pod network configuration changes might hamper the communication between pods/containers and to the outside world.
You might have iptables rules too restrictive or too open.

RecommendationsRecommendations

To perform the audit manually:

Run the following command on each node:

ps -ef | grep kubelet

Verify that if the --make-iptables-util-chains argument exists, then it is set to true.
If the --make-iptables-util-chains argument does not exist, and there is a Kubelet config file specified by --config, verify that the file does not set makeIPTablesUtilChains to false.

Remediation:

If using a Kubelet config file, edit the file to set makeIPTablesUtilChains: true.
If using command line arguments, edit the kubelet service file /etc/kubernetes/kubelet.conf on each worker node and remove the --make-iptables-util-chains argument from the KUBELET_SYSTEM_PODS_ARGS variable.
Based on your system, restart the kubelet service.
For example:

systemctl daemon-reload
systemctl restart kubelet.service

Kubelet client certificate rotation is enabledKubelet client certificate rotation is enabled

kind

severity

ID

HostSecurity

Medium

host-security.rotate-certs-not-false

DescriptionDescription

Enable kubelet client certificate rotation.
The --rotate-certificates setting causes the kubelet to rotate its client certificates by creating new CSRs as its existing credentials expire.
This automated periodic rotation ensures that there is no downtime due to expired certificates and thus addressing availability in the CIA security triad.
Note: This recommendation only applies if you let kubelets get their certificates from the API server.
In case your kubelet certificates come from an outside authority/tool (e.g. Vault) then you need to take care of rotation yourself.
Note: This feature also requires the RotateKubeletClientCertificate feature gate to be enabled (which is the default since Kubernetes v1.7)

RecommendationsRecommendations

To perform the audit manually:

Run the following command on each node:

ps -ef | grep kubelet

Verify that the RotateKubeletServerCertificate argument is not present, or is set to true.
If the RotateKubeletServerCertificate argument is not present, verify that if there is a Kubelet config file specified by --config, that file does not contain RotateKubeletServerCertificate: false.

Remediation:

If using a Kubelet config file, edit the file to add the line rotateCertificates: true or remove it altogether to use the default value.
If using command line arguments, edit the kubelet service file /etc/kubernetes/kubelet.conf on each worker node and remove --rotate-certificates=false argument from the KUBELET_CERTIFICATE_ARGS variable or set --rotate-certificates=true.
Based on your system, restart the kubelet service.
For example:

systemctl daemon-reload
systemctl restart kubelet.service

Rules for collecting Kubernetes node inventory data.

OS-level AppArmor inventoryOS-level AppArmor inventory

kind

severity

ID

inventory

low

inventory.apparmor

DescriptionDescription

This inventory rule collects AppArmor events and profiles across worker nodes using an inventory agent.

Queries:

apparmor_events. AppArmor events.

SELECT * FROM apparmor_events;

profiles. AppArmor profiles changes.

SELECT * FROM apparmor_profiles;

profiles_s. AppArmor profiles snaphost.

SELECT * FROM apparmor_profiles;

You can analyze the results by exporting event data from Audit Trails to your SIEM or SOC system.

Instructions and solutionsInstructions and solutions

This rule does not require guidance since it is informational and used to collect inventory events within Audit Trails.

You can configure event collection for Security Deck in Audit Trails and export the data to SIEM or SOC systems to analyze the inventory results.

OS-level installed package inventoryOS-level installed package inventory

kind

severity

ID

inventory

low

inventory.apps

DescriptionDescription

This inventory rule collects data on installed packages across worker nodes using an inventory agent.

Queries:

installed. Shows changes in installed packages.

SELECT os_version.name AS os_name, os_version.version AS os_version, os_version.major AS os_major, os_version.minor AS os_minor, os_version.platform AS os_platform, os_version.codename AS os_codename, deb_packages.name AS pkg_name, deb_packages.source AS pkg_source, deb_packages.version AS pkg_version, deb_packages.arch AS pkg_arch, deb_packages.status AS pkg_status FROM os_version JOIN deb_packages;

installed_s. Shows all installed packages.

SELECT os_version.name AS os_name, os_version.version AS os_version, os_version.major AS os_major, os_version.minor AS os_minor, os_version.platform AS os_platform, os_version.codename AS os_codename, deb_packages.name AS pkg_name, deb_packages.source AS pkg_source, deb_packages.version AS pkg_version, deb_packages.arch AS pkg_arch, deb_packages.status AS pkg_status FROM os_version JOIN deb_packages;

You can analyze the results by exporting event data from Audit Trails to your SIEM or SOC system.

Instructions and solutionsInstructions and solutions

This rule does not require guidance since it is informational and used to collect inventory events within Audit Trails.

You can configure event collection for Security Deck in Audit Trails and export the data to SIEM or SOC systems to analyze the inventory results.

OS-level APT repository inventoryOS-level APT repository inventory

kind

severity

ID

inventory

low

inventory.apt-sources

DescriptionDescription

This inventory rule collects data on configured APT repositories across worker nodes using an inventory agent.

Queries:

all. All apt sources changes.

SELECT name, release, source, base_uri, maintainer, components, architectures FROM apt_sources;

all_s. All apt sources snapshot.

SELECT name, release, source, base_uri, maintainer, components, architectures FROM apt_sources;

external. External apt sources (non-Yandex or non-secure Yandex) changes.

SELECT name, release, source, base_uri FROM apt_sources WHERE base_uri NOT IN ('http://common-secure.dist.yandex.ru/common','http://dist.yandex.ru/mdb-bionic-secure','http://dist.yandex.ru/mdb-jammy-secure','http://dist.yandex.ru/yandex-cloud-common-secure','http://dist.yandex.ru/yandex-cloud-secure','http://dist.yandex.ru/yandex-cloud-upstream-bionic-secure','http://yandex-cloud-common-focal-secure.dist.yandex.ru/yandex-cloud-common-focal-secure','http://yandex-cloud-common-secure.dist.yandex.ru/yandex-cloud-common-secure','http://yandex-cloud-focal-secure.dist.yandex.ru/yandex-cloud-focal-secure','http://yandex-cloud-secure.dist.yandex.ru/yandex-cloud-secure','http://yandex-cloud-secure.dist.yandex.ru/yandex-cloud','http://yandex-cloud-upstream-focal-secure.dist.yandex.ru/yandex-cloud-upstream-focal-secure','http://yandex-cloud-upstream-xenial-secure.dist.yandex.ru/yandex-cloud-upstream-xenial-secure','http://yandex-cloud-xenial-esm-secure.dist.yandex.ru/yandex-cloud-xenial-esm-secure','http://yandex-xenial-secure.dist.yandex.ru/yandex-xenial','https://common-secure.dist.yandex.ru/common','https://dist.yandex.ru/mdb-bionic-secure','https://dist.yandex.ru/mdb-jammy-secure','https://dist.yandex.ru/yandex-cloud-common-secure','https://dist.yandex.ru/yandex-cloud-secure','https://dist.yandex.ru/yandex-cloud-upstream-bionic-secure','https://yandex-cloud-common-focal-secure.dist.yandex.ru/yandex-cloud-common-focal-secure','https://yandex-cloud-common-secure.dist.yandex.ru/yandex-cloud-common-secure','https://yandex-cloud-focal-secure.dist.yandex.ru/yandex-cloud-focal-secure','https://yandex-cloud-secure.dist.yandex.ru/yandex-cloud-secure','https://yandex-cloud-secure.dist.yandex.ru/yandex-cloud','https://yandex-cloud-upstream-focal-secure.dist.yandex.ru/yandex-cloud-upstream-focal-secure','https://yandex-cloud-upstream-xenial-secure.dist.yandex.ru/yandex-cloud-upstream-xenial-secure','https://yandex-cloud-xenial-esm-secure.dist.yandex.ru/yandex-cloud-xenial-esm-secure','https://yandex-xenial-secure.dist.yandex.ru/yandex-xenial');

external_s. External apt sources (non-Yandex or non-secure Yandex) snapshot.

SELECT name, release, source, base_uri FROM apt_sources WHERE base_uri NOT IN ('http://common-secure.dist.yandex.ru/common','http://dist.yandex.ru/mdb-bionic-secure','http://dist.yandex.ru/mdb-jammy-secure','http://dist.yandex.ru/yandex-cloud-common-secure','http://dist.yandex.ru/yandex-cloud-secure','http://dist.yandex.ru/yandex-cloud-upstream-bionic-secure','http://yandex-cloud-common-focal-secure.dist.yandex.ru/yandex-cloud-common-focal-secure','http://yandex-cloud-common-secure.dist.yandex.ru/yandex-cloud-common-secure','http://yandex-cloud-focal-secure.dist.yandex.ru/yandex-cloud-focal-secure','http://yandex-cloud-secure.dist.yandex.ru/yandex-cloud-secure','http://yandex-cloud-secure.dist.yandex.ru/yandex-cloud','http://yandex-cloud-upstream-focal-secure.dist.yandex.ru/yandex-cloud-upstream-focal-secure','http://yandex-cloud-upstream-xenial-secure.dist.yandex.ru/yandex-cloud-upstream-xenial-secure','http://yandex-cloud-xenial-esm-secure.dist.yandex.ru/yandex-cloud-xenial-esm-secure','http://yandex-xenial-secure.dist.yandex.ru/yandex-xenial','https://common-secure.dist.yandex.ru/common','https://dist.yandex.ru/mdb-bionic-secure','https://dist.yandex.ru/mdb-jammy-secure','https://dist.yandex.ru/yandex-cloud-common-secure','https://dist.yandex.ru/yandex-cloud-secure','https://dist.yandex.ru/yandex-cloud-upstream-bionic-secure','https://yandex-cloud-common-focal-secure.dist.yandex.ru/yandex-cloud-common-focal-secure','https://yandex-cloud-common-secure.dist.yandex.ru/yandex-cloud-common-secure','https://yandex-cloud-focal-secure.dist.yandex.ru/yandex-cloud-focal-secure','https://yandex-cloud-secure.dist.yandex.ru/yandex-cloud-secure','https://yandex-cloud-secure.dist.yandex.ru/yandex-cloud','https://yandex-cloud-upstream-focal-secure.dist.yandex.ru/yandex-cloud-upstream-focal-secure','https://yandex-cloud-upstream-xenial-secure.dist.yandex.ru/yandex-cloud-upstream-xenial-secure','https://yandex-cloud-xenial-esm-secure.dist.yandex.ru/yandex-cloud-xenial-esm-secure','https://yandex-xenial-secure.dist.yandex.ru/yandex-xenial');

You can analyze the results by exporting event data from Audit Trails to your SIEM or SOC system.

Instructions and solutionsInstructions and solutions

This rule does not require guidance since it is informational and used to collect inventory events within Audit Trails.

You can configure event collection for Security Deck in Audit Trails and export the data to SIEM or SOC systems to analyze the inventory results.

Base OS property inventoryBase OS property inventory

kind

severity

ID

inventory

low

inventory.general

DescriptionDescription

This inventory rule collects data on base OS properties across worker nodes using an inventory agent.

Queries:

os_version_s. Retrieves information about the OS version, kernel and CPU.

SELECT os_name, os_version, major, minor, patch, build, platform, platform_like, codename, version AS kernel_version, phys_cpu, log_cpu, cpu_microcode FROM kernel_info, (SELECT cpu_physical_cores AS phys_cpu, cpu_logical_cores AS log_cpu, cpu_microcode FROM system_info), (SELECT name AS os_name, version AS os_version, major, minor, patch, build, platform, platform_like, codename FROM os_version);

authorized_keys_s. Authorized_keys file snapshot.

WITH homes AS MATERIALIZED (SELECT substr(path, 7, length(path)-7) AS uname FROM file WHERE path LIKE '/home/%' UNION SELECT 'root'), uids AS MATERIALIZED (SELECT username, uid, gid, directory FROM users WHERE username IN homes) SELECT u.username, u.uid, u.gid, k.key_file, k.key FROM authorized_keys AS k JOIN uids AS u ON k.uid = u.uid WHERE k.key IS NOT NULL;

authorized_keys. Authorized_keys present.

WITH homes AS MATERIALIZED (SELECT substr(path, 7, length(path)-7) AS uname FROM file WHERE path LIKE '/home/%' UNION SELECT 'root'), uids AS MATERIALIZED (SELECT username, uid, gid, directory FROM users WHERE username IN homes) SELECT u.username, u.uid, u.gid, k.key_file, k.key FROM authorized_keys AS k JOIN uids AS u ON k.uid = u.uid WHERE k.key IS NOT NULL;

sudoers_rules_s. Sudoers rules snapshot.

SELECT * FROM sudoers;

known_hosts_s. Known_hosts snapshot.

SELECT * FROM known_hosts;

crontab. Line parsed values from system and user cron/tab.

SELECT * FROM crontab;

crontab_s. Line parsed values from system and user cron/tab.

SELECT * FROM crontab;

disk_encryption_s. Disk encryption status and information.

SELECT * FROM disk_encryption;

disk_encryption_mounts_s. Disk encryption status and information.

SELECT * FROM mounts m, disk_encryption d WHERE m.device_alias = d.name AND m.path = '/' AND d.encrypted = 0;

sshd_config_s. Critical options in sshd_config.

SELECT DISTINCT SUBSTRING(node, 8 + LENGTH(path)) AS node, LOWER(label) AS label, value FROM augeas WHERE path = '/etc/ssh/sshd_config' AND label != '#comment' AND (node LIKE '%/PasswordAuthentication' OR node LIKE '%/PermitRootLogin' OR node LIKE '%/LogLevel' OR node LIKE '%/AuthorizedKeysCommand' OR node LIKE '%/PermitEmptyPasswords');

nss_s. Nss configuration for passwd/shadow/hosts. Should sort GROUP_CONCAT using OVER(ORDER BY) clause, but its works bad.

WITH dta AS MATERIALIZED (SELECT * FROM augeas WHERE path = '/etc/nsswitch.conf'), dbs AS (SELECT node, value AS name FROM dta WHERE label = 'database' AND value IN ('passwd', 'shadow', 'hosts')) SELECT dbs.name AS db, GROUP_CONCAT(dta.value, ' ') AS services FROM dta JOIN dbs ON dta.node LIKE dbs.node || '/%' WHERE label = 'service' GROUP BY dbs.name;

oslogin_present_s. Returns true if oslogin is present, else false.

WITH dta AS MATERIALIZED (SELECT * FROM augeas WHERE path = '/etc/nsswitch.conf'), dbs AS (SELECT node, value AS name FROM dta WHERE label = 'database' AND value IN ('passwd', 'shadow', 'hosts')) SELECT CASE WHEN EXISTS(SELECT dbs.name, GROUP_CONCAT(dta.value, ' ') AS services FROM dta JOIN dbs ON dta.node LIKE dbs.node || '/%' AND dta.value LIKE '%oslogin%') THEN 'true' ELSE 'false' END AS oslogin_present;

You can analyze the results by exporting event data from Audit Trails to your SIEM or SOC system.

Instructions and solutionsInstructions and solutions

This rule does not require guidance since it is informational and used to collect inventory events within Audit Trails.

You can configure event collection for Security Deck in Audit Trails and export the data to SIEM or SOC systems to analyze the inventory results.

OS kernel inventoryOS kernel inventory

kind

severity

ID

inventory

low

inventory.kernel

DescriptionDescription

This inventory rule collects data on kernel versions, loaded modules, and untrusted address blocklists across worker nodes using an inventory agent.

Queries:

kernel. Kernel version and cmdline.

SELECT * FROM kernel_info;

kernel_s. Kernel version and cmdline.

SELECT * FROM kernel_info;

kernel_modules. Loaded modules and changes.

SELECT name, status, size, used_by FROM kernel_modules;

kernel_modules_s. Loaded modules snapshot.

SELECT name, status, size, used_by FROM kernel_modules;

algif_aead_disable. CVE-2026-31431 blacklist check.

SELECT node, label, value FROM augeas WHERE path='/etc/modprobe.d/disable-algif.conf' AND label != 'disable-algif.conf';

modules_lpe_check. LPE vulnerabilities module check.

SELECT node, label, value FROM augeas WHERE path='/etc/modprobe.d/blacklist-lpe.conf' AND label != 'blacklist-lpe.conf';

You can analyze the results by exporting event data from Audit Trails to your SIEM or SOC system.

Instructions and solutionsInstructions and solutions

This rule does not require guidance since it is informational and used to collect inventory events within Audit Trails.

You can configure event collection for Security Deck in Audit Trails and export the data to SIEM or SOC systems to analyze the inventory results.

OS user login inventoryOS user login inventory

kind

severity

ID

inventory

low

inventory.logins

DescriptionDescription

This inventory rule collects data on user logins across worker nodes using an inventory agent.

Queries:

serial. Serial console logins in system.

SELECT ue.auid AS auid, ue.message AS message, ue.type AS event_type, ue.path AS logon_path, ue.terminal AS terminal, ue.pid AS logon_pid, pe.cmdline AS logon_cmdline, u.username AS user, regex_match(pe.cmdline, '/bin/login -p -- (\w+)', 1) AS serial_user, datetime(ue.time, 'unixepoch') AS dt FROM user_events ue LEFT JOIN users u ON ue.auid=u.uid LEFT JOIN process_events pe ON ue.pid=pe.pid WHERE terminal LIKE '/dev/tty%' AND ue.type IN (1112,1105);

root. Root logins and elevations in system.

SELECT ue.uid, ue.auid, u.username AS audit_user, u.shell AS shell, ue.pid, ue.message, ue.type, ue.path, ue.address, ue.terminal, pe.cmdline, pe.time, datetime(ue.time, 'unixepoch') AS dt FROM user_events ue LEFT JOIN users u ON ue.auid=u.uid LEFT JOIN process_events pe ON ue.pid=pe.pid WHERE ue.uid=0 AND ue.type=1105 AND ue.auid NOT IN (-1,4294967295) AND (terminal='ssh' OR terminal LIKE '/dev/pts%');

failed. Multiple failed logins from same IP address.

SELECT type, message, address, terminal, count() AS count, datetime(min(time), 'unixepoch') AS earliest, datetime(max(time), 'unixepoch') AS latest, count()*60.0/(max(time)-min(time)) AS speed FROM user_events WHERE type=1109 AND time>unixepoch('now', '-30 minutes') GROUP BY address, terminal, message HAVING count >= 5;

You can analyze the results by exporting event data from Audit Trails to your SIEM or SOC system.

Instructions and solutionsInstructions and solutions

This rule does not require guidance since it is informational and used to collect inventory events within Audit Trails.

You can configure event collection for Security Deck in Audit Trails and export the data to SIEM or SOC systems to analyze the inventory results.

OS-level network settings inventoryOS-level network settings inventory

kind

severity

ID

inventory

low

inventory.network

DescriptionDescription

This inventory rule collects data on network settings across worker nodes using an inventory agent.

Queries:

check_external_fqdn. Check external connectivity with google.

SELECT url, response_code FROM curl WHERE url = 'https://google.ru' AND user_agent='Mozilla/5.0';

check_external_ip. Check external connectivity with google.

SELECT url, response_code FROM curl WHERE url = 'https://8.8.8.8' AND user_agent='Mozilla/5.0';

iptables. Iptables.

SELECT * FROM iptables;

iptables_s. Iptables snapshot.

SELECT * FROM iptables;

dns_resolvers. Dns_resolvers.

SELECT * FROM dns_resolvers;

dns_resolvers_s. Dns_resolvers snapshot.

SELECT * FROM dns_resolvers;

etc_hosts. Etc_hosts.

SELECT * FROM etc_hosts;

etc_hosts_s. Etc_hosts snapshot.

SELECT * FROM etc_hosts;

processes_binding_to_ports. Listening ports binded to processes.

SELECT DISTINCT ps.name name, ln.port port, ln.protocol protocol, ln.family family, ln.address address, ps.pid pid, ps.path path, ps.on_disk on_disk, ps.parent parent, u.username username FROM processes ps JOIN listening_ports ln USING(pid) JOIN users u USING(uid) WHERE ps.path NOT IN ('/usr/local/bin/netmon-agent', '/bin/ping', '/usr/bin/ping', '/bin/ping6', '/usr/bin/ping6');

processes_binding_to_ports_s. Listening ports binded to processes snapshot.

SELECT DISTINCT ps.name name, ln.port port, ln.protocol protocol, ln.family family, ln.address address, ps.pid pid, ps.path path, ps.on_disk on_disk, ps.parent parent, u.username username FROM processes ps JOIN listening_ports ln USING(pid) JOIN users u USING(uid) WHERE ps.path NOT IN ('/usr/local/bin/netmon-agent', '/bin/ping', '/usr/bin/ping', '/bin/ping6', '/usr/bin/ping6');

interface_addresses. Interface_addresses.

SELECT * FROM interface_addresses;

interface_addresses_s. Interface_addresses snapshot.

SELECT * FROM interface_addresses;

process_open_sockets. Processes which have open network sockets on the system.

SELECT * FROM process_open_sockets WHERE NOT (local_address=remote_address) AND NOT (remote_address IN ('', '169.254.169.254', '0.0.0.0', '::', '2a02:6b8::1d9', '::1')) AND (protocol IN (6, 17)) AND NOT (fd=-1) AND NOT (remote_port IN (0, 30080));

You can analyze the results by exporting event data from Audit Trails to your SIEM or SOC system.

Instructions and solutionsInstructions and solutions

This rule does not require guidance since it is informational and used to collect inventory events within Audit Trails.

You can configure event collection for Security Deck in Audit Trails and export the data to SIEM or SOC systems to analyze the inventory results.

OS process inventoryOS process inventory

kind

severity

ID

inventory

low

inventory.processes

DescriptionDescription

This inventory rule collects data on running processes across worker nodes using an inventory agent.

Queries:

executions_lite. All processes in the system (without tree).

SELECT ps.pid pid, ps.path path, ps.cmdline cmdline, ps.cwd cwd, ps.parent parent, ps.time time, ps.uid uid, ps.auid auid FROM process_events ps WHERE ps.syscall IN ('execve', 'execveat');

running. Changes in running processes.

SELECT pid, parent, uid, euid, path, cmdline, on_disk FROM processes;

running_s. Running processes snapshot.

SELECT pid, parent, uid, euid, path, cmdline, on_disk FROM processes;

You can analyze the results by exporting event data from Audit Trails to your SIEM or SOC system.

Instructions and solutionsInstructions and solutions

This rule does not require guidance since it is informational and used to collect inventory events within Audit Trails.

You can configure event collection for Security Deck in Audit Trails and export the data to SIEM or SOC systems to analyze the inventory results.

OS-level seccomp event inventoryOS-level seccomp event inventory

kind

severity

ID

inventory

low

inventory.seccomp

DescriptionDescription

This inventory rule collects seccomp events across worker nodes using an inventory agent.

Queries:

seccomp_events. Seccomp events.

SELECT * FROM seccomp_events;

You can analyze the results by exporting event data from Audit Trails to your SIEM or SOC system.

Instructions and solutionsInstructions and solutions

This rule does not require guidance since it is informational and used to collect inventory events within Audit Trails.

You can configure event collection for Security Deck in Audit Trails and export the data to SIEM or SOC systems to analyze the inventory results.

Osquery agent self-monitoring inventoryOsquery agent self-monitoring inventory

kind

severity

ID

inventory

low

inventory.selfmon

DescriptionDescription

This inventory rule collects resource usage metrics for the osquery agent across worker nodes using an inventory agent.

Queries:

resource_usage. Osquery daemon CPU in seconds, RAM in MiB usage and db size in MiB.

SELECT SUM(resident_size)/1024/1024 AS mem, ((SUM(user_time) + SUM(system_time)) / 1000) AS cpu, db.db_size_mb AS db_size FROM processes, (SELECT (SUM(size) / 1024) / 1024 AS db_size_mb FROM (SELECT value FROM osquery_flags WHERE name = 'database_path' LIMIT 1) flags, file WHERE path LIKE flags.value || '%%' AND type = 'regular') db WHERE name = 'osqueryd' OR name = 'osqueryd.exe';

You can analyze the results by exporting event data from Audit Trails to your SIEM or SOC system.

Instructions and solutionsInstructions and solutions

This rule does not require guidance since it is informational and used to collect inventory events within Audit Trails.

You can configure event collection for Security Deck in Audit Trails and export the data to SIEM or SOC systems to analyze the inventory results.

OS-level shared memory inventoryOS-level shared memory inventory

kind

severity

ID

inventory

low

inventory.shared-memory

DescriptionDescription

This inventory rule collects data on shared memory segments across worker nodes using an inventory agent.

Queries:

shm_s. Shared-memory events pack.

SELECT sm.shmid, sm.owner_uid, o.username AS owner_username, sm.size, sm.permissions, sm.atime, sm.attached, sm.creator_pid, pe_c.path AS creator_path_bin, pe_c.cmdline AS creator_cmdline, sm.creator_uid, c.username AS creator_username, sm.ctime, sm.dtime, sm.locked, sm.pid, pe.path AS path_bin, pe.cmdline, sm.status FROM shared_memory sm LEFT JOIN users o ON sm.owner_uid = o.uid LEFT JOIN users c ON sm.creator_uid = c.uid LEFT JOIN process_events pe_c ON sm.creator_pid = pe_c.pid LEFT JOIN process_events pe ON sm.pid = pe.pid;

You can analyze the results by exporting event data from Audit Trails to your SIEM or SOC system.

Instructions and solutionsInstructions and solutions

This rule does not require guidance since it is informational and used to collect inventory events within Audit Trails.

You can configure event collection for Security Deck in Audit Trails and export the data to SIEM or SOC systems to analyze the inventory results.

OS-level sysctl parameter inventoryOS-level sysctl parameter inventory

kind

severity

ID

inventory

low

inventory.sysctl

DescriptionDescription

This inventory rule collects data on kernel sysctl parameters across worker nodes using an inventory agent.

Queries:

options. Listing every system control options.

SELECT * FROM system_controls;

You can analyze the results by exporting event data from Audit Trails to your SIEM or SOC system.

Instructions and solutionsInstructions and solutions

This rule does not require guidance since it is informational and used to collect inventory events within Audit Trails.

You can configure event collection for Security Deck in Audit Trails and export the data to SIEM or SOC systems to analyze the inventory results.

OS-level user inventoryOS-level user inventory

kind

severity

ID

inventory

low

inventory.users

DescriptionDescription

This inventory rule collects data on users across worker nodes using an inventory agent.

Queries:

logged. List logged in users with ssh keys.

SELECT lu.user, lu.tty, lu.host, lu.time, u.directory, u.shell, u.uid, au.key, au.key_file FROM (SELECT * FROM logged_in_users WHERE type='user') lu JOIN users u ON u.username = lu.user JOIN authorized_keys au USING (uid);

groups. Users and groups from etc_passwd.

SELECT users.uid, users.gid, groups.groupname, users.directory, users.username, users.shell FROM users LEFT JOIN groups ON groups.gid = users.gid;

groups_s. Users and groups from etc_passwd snapshot.

SELECT users.uid, users.gid, groups.groupname, users.directory, users.username, users.shell FROM users LEFT JOIN groups ON groups.gid = users.gid;

empty_passwd. List users with empty passwords.

SELECT * FROM shadow WHERE (password_status = 'empty') OR (hash_alg='' AND password_status='active');

password_expires. To warn users when password expires.

SELECT * FROM shadow WHERE (expire < 7) AND (expire > 0);

list. List changes in users.

SELECT * FROM users;

list_s. List users.

SELECT * FROM users;

list_groups. List changes in groups.

SELECT * FROM groups;

list_groups_s. List groups.

SELECT * FROM groups;

ipmi. Detect ipmi login.

SELECT type, user, tty, pid FROM logged_in_users WHERE type != 'dead' AND tty LIKE 'tty%';

You can analyze the results by exporting event data from Audit Trails to your SIEM or SOC system.

Instructions and solutionsInstructions and solutions

This rule does not require guidance since it is informational and used to collect inventory events within Audit Trails.

You can configure event collection for Security Deck in Audit Trails and export the data to SIEM or SOC systems to analyze the inventory results.

Was the article helpful?

Previous
CSPM
Next
Authentication
© 2026 Direct Cursus Technology L.L.C.