Glossary
Dictionary for the security specialist.
Раздел «For security specialists»: быстрый переход по подразделам
Who is this page for?
In the For security specialists section, terms for tools (Kyverno, Trivy, Cilium, Vault, Cosign), protocols (TLS, OIDC, LDAPS), standards, policies, reports, and platform modules are used. This page lists brief definitions.
Scanning and vulnerabilities
| Term | Definition |
|---|---|
| Trivy | Security scanner: container images (CVE, misconfigurations, secrets, SBOM), hosts, Kubernetes (CIS Kubernetes Benchmark, NSA Kubernetes Hardening Guide). The platform contains the shturval-scanner module. |
| CVE (Common Vulnerabilities and Exposures) | A unique identifier in the database of known vulnerabilities. Trivy matches image components by their identifiers (purl) to components that are included in the CVE. |
| CVSS (Common Vulnerability Scoring System) | System for assessing the criticality of vulnerabilities. In reports, Trivy is used for Low, Medium, High and Critical levels. |
| SBOM (Software Bill of Materials) | List of software components. Used for vulnerability analysis. |
| VEX (Vulnerability Exploitability eXchange) | A format for documenting the applicability of a vulnerability to a specific product, component, or image. Helps distinguish CVEs that are actually exploitable from those that are not applicable in a given context. |
| BDU FSTEC | Databank of information security threats of the FSTEC of Russia. The section is mentioned as one of the sources of information for the aggregated database of platform vulnerabilities. |
| NVD (National Vulnerability Database) | Public vulnerability database. Can be connected as a source of information for scanning. |
| CIS Kubernetes Benchmark | CIS guidelines for securely configuring Kubernetes. Trivy checks for compliance. |
| NSA Kubernetes Hardening Guide | Guide to Hardening Kubernetes. |
| Pod Security Standards (PSS) | Kubernetes standards (Baseline, Restricted) for limiting pod capabilities. |
| Compliance Reports | Reports on cluster configuration compliance with security requirements. The section interface displays Trivy reports. |
| ClusterComplianceReports | Trivy reporting resources for CIS, NSA, and PSS audits that appear on the Security → Scan Results page. |
Modules and platform configuration
| Term | Definition |
|---|---|
| shturval-scanner | Container image scanning module and cluster configuration scanning based on Trivy. Generates vulnerability and compliance reports. |
| shturval-policy-manager | Module for analyzing application configurations and generating reports on Kyverno security policies. |
| shturval-log-collector | Vector-based local log collection module. Used to collect cluster logs and redirect security logs to external systems. |
| shturval-networking | Cluster network management module based on Cilium CNI. Ensures network connectivity and network policies. |
| ShturvalServicePatch (SSP) | A resource for changing customvalues installed platform service without completely reinstalling the service. Used, for example, to configure scanning, logging, Hubble UI and log export. |
| CustomValues | Custom platform service configuration values that override or supplement service settings. |
| NCI (NodeConfigItem) | Node configuration. Through NCI, Seccomp profiles, the Kubernetes audit policy and other file changes on the nodes are configured. |
| container runtime | Container runtime, such as containerd or CRI-O. Used by Kubernetes to launch containers and apply security profiles. |
| containerd | Container runtime. This section is mentioned in the context of logs and Seccomp profiles. |
| CRI-O | A container runtime that is compatible with the Kubernetes CRI. Seccomp RuntimeDefault profiles may differ between CRI-O, containerd and runtime versions. |
Security policies
| Term | Definition |
|---|---|
| Kyverno | Policy engine for Kubernetes. Policies of the Generate, Mutate, Validate types. Platform - Security Policy Manager. |
| ClusterPolicy | Kyverno cluster policy. Valid in all namespaces of the cluster. |
| Policy | Kyverno namespace policy. Limited to a specific namespace. |
| Generate | A Kyverno rule type that creates or updates associated resources. |
| Mutate | A type of Kyverno rule that modifies a resource before being saved or run. |
| Validate | A type of Kyverno rule that checks a resource and blocks it if necessary. |
| PolicyReport | Namespace report on the results of resource checks by policies. Used to display results in the GUI. |
| ClusterPolicyReport | Cluster report on the results of resource checks by policies. Used for summary reports. |
| Audit | A policy mode in which inconsistencies are recorded in a report, but creation or modification of a resource is not blocked. |
| Enforce | A policy mode in which a resource is blocked if it does not meet policy requirements. |
| failurePolicy | Configuring webhook behavior when a policy check fails. For example, Ignore does not block the request if the check is not available. |
| Seccomp | Linux mechanism for limiting system calls in containers. Reduces attack surface. Profiles are set through NCI. |
| RuntimeDefault | Seccomp profile type Kubernetes, which uses the default profile from container runtime. |
| Localhost | Seccomp profile type Kubernetes, which uses a JSON profile located on the node. |
| Unconfined | Seccomp unlimited launch mode. |
| securityContext | The Kubernetes field of the manifest, which specifies the security parameters of the Pod or container, including the Seccomp profile and privileged mode. |
| privileged | Container mode with extended privileges. For such containers, Seccomp does not restrict system calls. |
| Service Account Token | Service account token Kubernetes. Security policies can control whether such a token is automatically mounted in a Pod. |
| Capabilities | Linux features that can be added or removed from a container process. Capability SYS_ADMIN is considered particularly risky. |
| NodePort | Kubernetes Service type for publishing an application through a port on cluster nodes. In application scenarios, Ingress is usually preferred over NodePort. |
Cilium network policies
| Term | Definition |
|---|---|
| Cilium | Network component Kubernetes based on eBPF. The platform uses the shturval-networking module. |
| Cilium CNI | Cilium CNI plugin that enables pod networking and policy enforcement. |
| Cilium Network Policies | Network policies based on Cilium eBPF. Traffic filtering at L3-L7 level. |
| CiliumNetworkPolicy | Namespace policy of Cilium. Applies to the pod inside the namespace where the policy is created. |
| CiliumClusterwideNetworkPolicy | Cilium cluster policy. It operates at the level of the entire cluster and is not tied to one namespace. |
| NetworkPolicy | Standard Kubernetes policy for ingress and egress management at L3/L4 level. |
| eBPF | Linux kernel technology that Cilium uses for network filtering, observability, and policy enforcement. |
| Ingress | Incoming network traffic to selected pods or endpoints. |
| Egress | Outgoing network traffic from selected pods or endpoints. |
| Default deny | A model in which traffic is denied unless it is explicitly allowed by policy. In Cilium, it is enabled for the selected direction after selecting a pod policy. |
| Allow-rule | A rule that allows a matched network flow. |
| Deny-rule | A rule that explicitly denies a matched network flow and takes precedence over allow rules. |
| endpointSelector | A Cilium selector that selects the pods to which the policy is applied. |
| fromEndpoints / toEndpoints | Selectors for ingress traffic sources and egress traffic destinations. |
| Entities | Special Cilium categories to describe traffic sources or destinations, such as world, cluster, host, remote-node, kube-apiserver. |
| CIDR | IP subnet entry. In Cilium it is used for rules for external networks with stable IP addresses. |
| FQDN (Fully Qualified Domain Name) | Fully qualified domain name. In Cilium, it is used in toFQDNs for egress access to external services by DNS name. |
| DNS proxy | A Cilium engine that considers DNS responses for FQDN policies and associates domain names with IP addresses. |
| kube-dns | DNS service Kubernetes in namespace kube-system. Network policies often require explicitly allowing egress to kube-dns. |
| shturval-caching-dns | A platform DNS component that can be used together with kube-dns to resolve names in a cluster. |
| Ingress Controller | A component that accepts external traffic and forwards it to applications in the cluster. Cilium policies for published applications often allow ingress from the Ingress Controller. |
| L3/L4/L7 | Filtering levels: L3 - addresses and endpoints, L4 - ports and protocols, L7 - application rules of HTTP, DNS and other protocols. |
| SNI (Server Name Indication) | TLS extension, which can be used to restrict TLS traffic in L4/L7 level rules when L7 proxy enforcement is enabled. |
| Hubble UI | Cilium Hubble observability interface for viewing network flows and diagnosing network policies. |
Authentication and encryption
| Term | Definition |
|---|---|
| RBAC | Role-Based Access Control. Role-based access control by roles (Kubernetes, platform). |
| TLS (Transport Layer Security) | Encryption protocol (HTTPS, LDAPS). |
| OIDC (OpenID Connect) | Authentication protocol on top of OAuth 2.0. The platform uses Keycloak or Blitz to connect. |
| LDAP | User directory access protocol. The platform can connect to an LDAP directory and look up users and groups when assigning rights. |
| LDAPS | LDAP over TLS. Secure connection to the directory. |
| AD (Active Directory) | Microsoft User Directory. Can be used as an authentication source. |
| ServiceAccount | The Kubernetes account for processes within the cluster. Used, for example, for authentication to Vault and access to the Kubernetes API. |
| Token Reviewer JWT | The ServiceAccount token that Vault uses to validate Kubernetes tokens when configuring the Kubernetes Auth Method. |
Audit and SIEM
| Term | Definition |
|---|---|
| Audit Logs | Kubernetes audit logs. Register API requests. Configured through NCI. |
| Audit Policy | The Kubernetes audit policy, which determines which API server events to record and at what level of detail. |
| audit event | Audit event Kubernetes generated for an API request at a certain stage of processing. |
| kube-apiserver | API server Kubernetes. Generates audit events and writes them to the configured backend. |
| log backend | Audit backend Kubernetes, which writes events to a file. The section is used for the Audit Logs platform. |
| webhook backend | Audit backend Kubernetes, which sends events to an external webhook receiver. |
| Vector | Agent for collecting and routing logs. Used by the shturval-log-collector module. |
| VLogs | Service for storing and viewing logs in the platform. For Audit Logs, the kube audit project is used. |
| ProjectID | Log project ID in VLogs. Used to filter logs on the Logs tab. |
| stream | A set of logs with a unique set of parameters. In the log interface it is displayed as _stream. |
| auditd | Linux system audit logs. Can be redirected to external systems through the log collection module. |
| journald | systemd system logs, including containerd, kubelet and shturvald logs. |
| k8s_audit | Log type for API audit events Kubernetes in the log redirection settings. |
| k8s_events | Log type for events Kubernetes in the log redirection settings. |
| k8s_logs | Container log type Kubernetes in log redirection settings. |
| sources | Data sources in Vector configuration. |
| transforms | Transformations and data filters in the Vector configuration. |
| sinks | Data recipients in Vector configuration: SIEM, Loki, Elasticsearch, OpenSearch, syslog and others. |
| ClusterVectorPipeline | Pipeline configuration resource for Vector. The section uses k8s_audit as a source for the list of transforms for logs. |
| SIEM (Security Information and Event Management) | System for receiving, accumulating and analyzing events and safety data. In the Shturval platform, the collection and redirection of logs to an external SIEM is performed by the local log collection module. |
| Loki | Log storage and retrieval system. Can be used as an external log recipient. |
| Elasticsearch / OpenSearch | Search and analytical systems that can be used as external log recipients. |
| syslog | System message transmission standard. Can be used to redirect logs to an external system. |
Managing secrets
| Term | Definition |
|---|---|
| HashiCorp Vault | System for storing and issuing secrets. The platform supports Vault integration with clusters. |
| Cert-Manager | Kubernetes component for managing certificates. Can integrate with Vault to issue TLS certificates to applications. |
| Issuer / ClusterIssuer | Cert-Manager resources that describe the source of certificate issuance. Issuer operates in namespace, ClusterIssuer - at the cluster level. |
| Vault Agent Injector | HashiCorp Vault mechanism for injecting secrets into Pods in the form of files or environment variables. |
| Kubernetes Auth Method | A Vault authentication method in which applications or operators are authenticated using the ServiceAccount Kubernetes. |
| Vault Secrets Operator | Operator for synchronizing secrets from Vault to Kubernetes. The section uses the vault-secrets-operator service. |
| External Secrets Operator | Operator for synchronizing secrets from external storages to Kubernetes Secret. |
| VaultConnection | Vault Secrets Operator resource with Vault connection parameters. |
| VaultAuth | Vault Secrets Operator resource with authentication settings in Vault. |
| VaultStaticSecret | A Vault Secrets Operator resource that synchronizes a static secret from Vault to Kubernetes Secret. |
| Secrets Engine | Engine for storing or generating secrets in Vault. The section uses KV Secrets Engine. |
| KV v2 | Key-value Secrets Engine version in Vault with support for secrets versioning. |
| ACL policy | Vault access policy, which specifies allowed actions on secret paths. The section is used to grant permission to read secrets from the Secrets Engine. |
Image signing and secure assembly
| Term | Definition |
|---|---|
| Cosign | Sigstore tool for signing container images, verifying signatures, and adding attestations, including vulnerability reports. |
| Sigstore | A set of tools and services for signing, verifying and transparently accounting for software supply chain artifacts. Cosign is part of the Sigstore ecosystem. |
| Attestation | A signed statement about an artifact, such as a Trivy vulnerability report attached to an image with Cosign. |
| Rekor | A Sigstore transparency log that can be used to verify Cosign signatures. |
| CT log | Certificate Transparency log. Can be used in signature verification policies as part of trust verification. |
| SAST (Static Application Security Testing) | Static analysis of source code for vulnerabilities and weaknesses. |
| SCA (Software Composition Analysis) | Analysis of source code dependencies for known vulnerabilities and generation of SBOM. |
| DAST (Dynamic Application Security Testing) | Dynamic checking of a running application based on available APIs and ports. |
| Image-Scan | Scanning collected container images for vulnerabilities, misconfigurations and secrets. |
| Secret Detection | Search for secrets, keys and tokens in source code and artifacts. |
| Vulnerability Management | The process of accounting, prioritizing, eliminating and marking vulnerabilities. |
| Dependency-Track | A tool for analyzing dependencies and working with SBOM in the SCA process. |
| Syft | SBOM generation tool. |
| gitleaks | A tool for finding secrets in repositories. |
| OWASP ZAP | Dynamic web application security analysis tool. |
| DefectDojo | Vulnerability accounting and management system. |
| Security CI | A secure build process in which artifacts pass SAST, SCA, DAST, image scanning, and other checks. |
| Helm repository | Helm chart repository used to install overlay security tools through the marketplace or by connecting a third-party repository. |
| Helm-chart | A package describing Kubernetes resources for installing an application or service into a cluster. |
Security Overlays
| Term | Definition |
|---|---|
| Overlay security tools | External container security tools that are installed in the cluster as separate services and complement the built-in platform tools. |
| PT CS (Positive Technologies Container Security) | Positive Technologies container security tool for analyzing images, containers, repositories and host operating systems. |
| KCS (Kaspersky Container Security) | Kaspersky container security tool for identifying security issues during the development and operation of container applications. |
| Luntry | A security tool for containers and Kubernetes that increases visibility and control of security processes. |
Glossaries of other sections
| Section | Description |
|---|---|
| Platform Administrator Glossary | Terms on installation, providers, mirror, IAM |
| Cluster Administrator Glossary | Storage, Node, Monitoring Terms |
| Developer glossary | Application delivery, GitOps, Argo CD |