- Kaspersky Container Security 2.0 Help
- About the Kaspersky Container Security platform
- Solution architecture
- Standard deployment schemes
- Preparing to install the solution
- Solution installation
- Removing the solution
- Updating the solution
- Solution interface
- Licensing the solution
- Data provisioning
- Working with clusters
- View the list of clusters
- Namespaces in the cluster
- Pods in the cluster
- Visualization of cluster resources
- Working with images from registers
- Investigating security events
- Analyzing container forensics
- Searching container forensics
- Detailed information about a running process
- Detailed information about file operations
- Details information about network traffic
- Detailed information about detected malicious objects
- Restrictions on runtime policies
- Investigating container forensics while accounting for adjacent events
- Analyzing detected vulnerabilities
- Analyzing container forensics
- Integration with third-party resources
- Setting up integration with external image registries
- Минимально достаточные права для интеграции с реестрами
- Working with public registries without authorization
- Adding integrations with external image registries
- Viewing information about integrations with registries
- Deleting integration with external registry
- Harbor integration
- Creating an integration upon Harbor request
- Viewing and editing the Harbor External Integration settings
- Rescanning
- Integration with CI/CD
- Image scanning in CI/CD processes
- Configuring integration with GitLab CI/CD
- Configuring integration with Jenkins CI/CD
- Configuring integration with TeamCity CI/CD
- Defining the path to container images
- Monitoring the integrity and origin of images
- Running the scanner in SBOM mode
- Getting scan results in JSON or HTML format
- Running the scanner in lite SBOM mode
- Specifying secrets when starting a scan
- Configuring integration with image signature validators
- Setting up integration with notification outputs
- Configuring LDAP server integration
- Configuring integration with SIEM systems
- Integrating with HashiCorp Vault
- Setting up integration with external image registries
- Security policies configuration
- Scanner policies
- Assurance policies
- Response policies
- Runtime policies
- Creating a runtime policy
- Editing runtime policy settings
- Managing container runtime profiles
- Managing runtime autoprofiles
- Deleting policies
- Compliance check
- Configuring and generating reports
- File Threat Protection
- Users, roles, and scopes
- Managing users
- About user roles
- Действия в рамках системных ролей
- Displaying list of roles
- About scopes
- Scopes and enforcement of security policies
- Switching between scopes
- Adding users, roles, and scopes
- Resetting password for user accounts
- Changing settings for users, roles, and scopes
- Removing users, roles, and scopes
- Using Kaspersky Container Security OpenAPI
- Security event log
- Information about the status of solution components
- Ensuring safety and reliability of components
- Managing the dynamics of data accumulation
- Creating a user for an external PostgreSQL database
- Backing up and restoring data
- Contacting Technical Support
- Sources of information about the application
- Limitations and warnings
- Glossary
- Third party code information
- Trademark notices
- ATT&CK MITRE Terms of Use
Limitations and warnings
Kaspersky Container Security 2.0 has a number of limitations that are not critical to the operation of the solution:
- When working with PostgreSQL 11.* or later, you need to use the uuid-ossp and pgcrypto extensions with the Kaspersky Container Security database.
- The duration of the Kaspersky Container Security update depends on the volume of available databases. If your database contains a many records of tables with image scanning results, vulnerability descriptions, and accepted risks, the update may take up to several hours.
We recommend updating Kaspersky Container Security outside of active hours.
The following is information about the limitations of earlier versions of Kaspersky Container Security.
Limitations and warnings of Kaspersky Container Security 1.2
Kaspersky Container Security 1.2 has a number of limitations that are not critical to the operation of the solution:
- To ensure maximum compatibility of BPF programs used by Kaspersky Container Security with numerous Linux distributions and Linux kernel versions, the solution uses eBPF CO-RE technology. Kaspersky Container Security works directly with the kernel of the Linux host server (node), thus the following requirements and restrictions must be observed:
- To use eBPF CO-RE, the Linux kernel must be compiled with configuration value
CONFIG_DEBUG_INFO_BTF = y
. Most Linux distributions have this configuration value enabled when building the kernel that is supplied with the distribution. - If kernel versions are updated manually, you must check the availability of the above mentioned configuration value.
For earlier versions of Linux distributions and Linux kernels that do not have built-in support for eBPF CO-RE, backward compatibility is ensured by Kaspersky Container Security.
- To use eBPF CO-RE, the Linux kernel must be compiled with configuration value
- If a manually compiled Linux kernel is used on a host server (node), the following settings must be enabled during the kernel configuration to ensure runtime monitoring using container runtime profiles:
CONFIG_BPF=y
CONFIG_BPF_SYSCALL=y
CONFIG_BPF_EVENTS=y
CONFIG_NET_CLS_BPF=m
CONFIG_NET_ACT_BPF=m
To ensure better BPF code performance, we recommend enabling the following settings:
CONFIG_BPF_JIT = y
CONFIG_HAVE_BPF_JIT = y
- If runtime monitoring using Kaspersky Container Security container runtime profiles is to be conducted simultaneously with CNI Cilium (node-agent pods are deployed on the same host servers with cilium-agent), the following actions must be performed:
- In the cluster with the deployed node-agent, specify the value of the
data.bpf-filter-priority
parameter for the ConfigMap cilium-config greater than 1.We recommend to specify 5 for the
data.bpf-filter-priority
parameter. - Restart the cilium-agent pods to apply the specified setting.
- In the cluster with the deployed node-agent, specify the value of the
- To access Kubernetes, Kaspersky Container Security uses the functionality of the dynamic admission controller provided in Kubernetes. The security of your cluster can be hardened by configuring authorization between the Kubernetes API and kube-agent, which ensures the operation of the solution's dynamic admission controller. Authorization must be configured in accordance with the Kubernetes instructions.
We recommend to limit access to kube-agent to data exchange with the Kubernetes API server. For this purpose, the following Kubernetes network policy must be applied:
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
labels:
app: kcs
name: allow-kube-api-to-kube-agent
namespace: {{ $.Release.Namespace }}
spec:
podSelector:
matchLabels:
app: kube-agent
ingress:
- from:
- podSelector:
matchLabels:
component: kube-apiserver
ports:
- protocol: TCP
port: 8443
Limitations and warnings of Kaspersky Container Security 1.1
Kaspersky Container Security 1.1 has a number of limitations that are not critical to the operation of the solution:
- If you need to run many image vulnerability scans, we advise you to disable the misconfiguration scan option in the scanner policy because this operation may consume substantially more resources, especially when working with large-sized images.
- In cases where an attempt is made to run the solution simultaneously with other container security applications, Kaspersky Container Security has been noted to operate incorrectly. If another application in use is interfering and / or integrating with the operation of containers, the File Threat Protection component may not function correctly. You can temporarily disable the File Threat Protection component in scanner policies.
We recommend that you do not use Kaspersky Container Security simultaneously with other container security applications.
- To use network policies supplied with Kaspersky Container Security, ensure the following:
- In the Helm Chart used to deploy and install the solution, the
networkPolicies.create
parameter is set to true (the default value). - The network plug-in in the cluster, where the solution is deployed, supports Kubernetes network policies. If network policies are not supported, Kaspersky Container Security will create
NetworkPolicies
objects, but they will not be applied and will not filter traffic.If the
NetworkPolicies
objects are missing or not applied, the security level of the solution is lower.
- In the Helm Chart used to deploy and install the solution, the
- Kaspersky Container Security 1.1 supports correct scanning only of images for the linux/amd64 architecture. When scanning multi-platform images, the scanner automatically attempts to apply the linux/amd64 architecture option.
Limitations and warnings of Kaspersky Container Security 1.0
Kaspersky Container Security 1.0 has a number of limitations that are not critical to the operation of the solution:
- If you need to run many image vulnerability scans, we advise you to disable the misconfiguration scan option in the scanner policy because this operation may consume substantially more resources, especially when working with large-sized images.
- If the misconfiguration control is enabled in the scanner policy for the scanner operation, scanning time significantly increases. Images containing up to 1000 configuration files in the YAML, YML and JSON formats were successfully tested, but the correct operation of the scanner on images containing over 1000 configuration files may not be guaranteed.
- You are not recommended to scan images for sensitive data, if the image size is over 10 GB.