Scalability limitation of ACC-L with docker (overlay2)
Last Modified: 2024-01-23 12:50:14 Etc/GMT
Affected Products
Languages:
This article is available in the following languages:
Trellix CEO, Bryan Palma, explains the critical need for security that’s always learning.
As per Gartner, "XDR is an emerging technology that can offer improved threat prevention, detection and response."
Trellix announced the establishment of the Trellix Advanced Research Center to advance global threat intelligence.
Trellix Advanced Research Center analyzes threat data on ransomware, nation-states, sectors, vectors, LotL, MITRE ATT&CK techniques, and emails.
As of May 14, 2024, Knowledge Base (KB) articles will only be published and updated in our new Trellix Thrive Knowledge space.
Log in to the Thrive Portal using your OKTA credentials and start searching the new space. Legacy KB IDs are indexed and you will be able to find them easily just by typing the legacy KB ID.
Scalability limitation of ACC-L with docker (overlay2)
Technical Articles ID:
KB95991
Last Modified: 2024-01-23 12:50:14 Etc/GMT Environment
Application and Change Control (ACC) 6.4.22 and above Docker or Kubernetes with docker as container runtime NOTE: This KB is limited to the storage driver as overlay2. Problem
There's an increase in the deployment time when the number of containers exceeds, for example, 20. While deploying containers with Kubernetes, the deployment time increases three to four times with an increase in containers. This increase in deployment creates problems in the container orchestrator. Cause
ACC contains a driver module that performs the file system hooking and system call hooking for getting the call-back. When you receive the call-back, the decision to ALLOW or DENY execution, or CHANGE CONTROL for executables and files is taken. For this decision to be taken, you must scan and add hooks (if supported) for all new block devices, both physical and virtual. In cases where deployment (large scale) of containers by Kubernetes is executed using a docker as the container runtime, the above-mentioned problem occurs. Each container image receives multiple calls for mounting and unmounting. In addition, parallel deployment of pods creates a bottleneck and contention for shared resources (protected to avoid data races). This bottleneck leads to delays in the processing of calls and creates a situation such as the Solution
To resolve the issue, add the below processes in the runc:[2:INIT] kubelet dockerd Once added, it appears similar to the following: runc runc:[2:INIT] … } For specific applications, the processes from trusted repositories can also be added for further help. The steps to identify such processes are as follows:
Affected ProductsLanguages:This article is available in the following languages: |
|