Skip to main content

Linux Agent FAQs

Are root privileges required for installing a Lacework agent?
Yes, you must install the Lacework agent using root privileges:
  • Log in as root and run the installer.
  • Run the installer with sudo. Running a command with just the sudo prefix invokes the command with root privileges.
During startup, the agent checks that the agent binary and configuration files are owned by root.
Does the Lacework agent have any package dependencies?
No. The Lacework agent has no package dependencies. When the Lacework agent package is installed, Lacework does not install any shared libraries. The Lacework agent is a statically linked binary that uses the following libraries:
Does the Lacework agent support containers/microservices?
Yes, the Lacework agent runs in the following environments:
  • Agent runs as a Docker container - For more information, see Install on a Dockerized Host. For Docker containers, the Lacework agent must be run as a privileged container.
  • Agent is deployed across a Kubernetes cluster as a daemonset - For more information, see Deploy Using Kubernetes.
When an agent is installed on a node as a DaemonSet or Pod or on the node itself, the agent has container visibility of the following resources:
  • Processes running on the host
  • Processes running in a container that make a network connection (server or client)
  • All container internal servers and processes that are listening actively on certain ports
  • File Integrity Monitoring (FIM) on the host
  • Host vulnerability on the host
What is the impact of the Lacework agent on CPU?
The number of connections made by the host determines the CPU impact on an individual system. However, for an average workload, Lacework has observed CPU usage of 1-3% but the CPU usage varies depending on the number of connections. You can optionally configure a limit for agent CPU usage. For more information, see Usage Impact of Agent Deployment.
How much disk size does the agent use on a machine?
The agent uses approximately 250 MB of disk space on a machine.
How much memory does the Lacework agent consume?
Lacework has observed an average of 250-300 MB of memory usage, but memory usage can vary depending on the host workload, such as the number of network connections, running applications, running containers, the amount of metadata processing, etc. Lacework also has guardrails on the Lacework agent to prevent the agent from consuming an unlimited amount of memory and CPU on a host. A host is where the agent process is running, either a Docker container or as part of a Kubernetes cluster, virtual machine, or standalone machine.

You can optionally configure a limit for agent memory usage. For more information, see Usage Impact of Agent Deployment.
What is the impact of the Lacework agent on network resources?
The number of network connections made by the host determines the impact on the individual system. Lacework has observed data usage of 1-2 Kilo Bytes/sec in current deployments, which translates to around 100-150 MB per system per day of data. A system is where the agent process is running, either a Docker or Kubernetes container, virtual machine, or standalone machine.
Does the Lacework agent work in the kernel or user space?
The Lacework agent works in the user space in a passive mode. There is no dependency on IP tables, and the agent does not slow down containerized applications and network connections.
How often does the Lacework agent collect data?
Lacework is a continuous monitoring system that collects and monitors metadata of all the processes associated with a network activity. The Polygraph is computed every hour.
What happens to the data collected by the agent if it cannot connect to the Lacework platform?
The agent can buffer up to 40MB of compressed data which is the equivalent of four hours of data collected on most hosts. When the data in the buffer exceeds 40MB, the agent drops data on a first in, first out basis.
What does the Lacework agent monitor?
The Lacework agent monitors the following:
  • Every process that sends UDP or TCP packets over the network or receives UDP or TCP packets (client process or server process)
  • Processes in all containers
  • Any process that is used to log in (if the agent detects that it has network connections)

For every process that the agent monitors, it also monitors the dependent processes. These are the dependent processes:

  • Parent process of the monitored process
  • Process that belongs to the process group ID of the current monitored process
  • Process that belongs to the session ID of the current monitored process
  • Process that traces the current monitored process (if there is one)

The agent discovers the dependent processes recursively until it detects a cycle or reaches the root of the process hierarchy.

What affects retrieving vulnerability reports?
The following factors can affect the ability to retrieve vulnerability assessment reports:
  • Falling outside of the viewable timeframe
  • A container registry is not integrated with Lacework

To help prevent this, consider integrating container registries with Lacework because a host running for less than 60 minutes (applicable to host vulnerability only).

How is the Linux agent updated?
By default, the Linux agent is automatically updated when a new fleet upgrade version is available. You can disable automatic updates if you want to manually update the agent. For more information, see Upgrade the Linux Agent.
Does the Lacework agent have remote access?
Lacework does not enable remote connection to our Agent. Customers will be notified of any material changes affecting agent connectivity and access.
How can I deploy the agent?
You can deploy the agent with any configuration management tool such as Chef, Puppet, Ansible, or Salt. You can also use the installation script provided by Lacework for these configuration management tools.

For single host installations, you can also use the Lacework installation script or embed the Lacework agent in a base image or AMI.

You can also install from Debian-based (APT) and RPM-based (YUM and Zypper) repositories. For more information, see Linux Agent Installation Options.

Does the Lacework agent work with a proxy?
The Lacework agent supports a proxy configuration. If required, the agent can be configured to use a network proxy by adding proxy information to a configuration file or by creating an https_proxy environment variable. For more information about configuring a Lacework agent to use a proxy, see Required Connectivity, Proxies & Certificates.
What Linux versions are supported by the agent?
The agent requires minimal system resources and runs on most 64-bit Linux distributions. For the supported agent Linux operating systems, see Supported Operating Systems.
What kind of connectivity is needed by the agent?
To be able to communicate with Lacework, the installed agents must be allowed to reach specific URLs. For more information, see Required Connectivity, Proxies & Certificates.
What authentication methods are used by the Lacework agent to connect to the Lacework platform?
To connect to the Lacework platform, agents require an active access token. If you have a Lacework account, an agent access token is automatically generated for you. In addition, you can create and disable agent access tokens. For more information, see Agent Access Tokens.
Is the data encrypted when in transit from the agent?
The Lacework agent encrypts all data when it is in transit to our SAAS service. The data is encrypted over https with port 443 using TLS 1.2.
Is the data compressed by the agent?
The Lacework agent compresses data before transmission (end-to-end).
Does the agent support the ability to add custom tags?
In addition to importing AWS, GCP, and Azure tags, local tags can be added to agents. For more information, see Add Agent Tags.
Why do some events not report event details in the Lacework Console?
The monitoring and collection capability of the Lacework agent was designed to minimize the impact on host VM resources—CPU, memory, and the network. In most conditions, the Lacework agent is able to attribute a connection to the owning process either as a client or a server. But in certain conditions, the Lacework agent may not be able to report full details about the owning process. In such cases, the connections are attributed to the virtual machine. Some of those conditions may be associated with the untimely exit of a process while the Linux kernel continues to report the underlying data structures as in the case of socket cleanup timeout. Another condition is when the binary file associated with the process is unreadable (file not found, file content read failure, etc.) from the filesystem, which prevents the Lacework agent from fully reporting process details.
How can I view where the agents are running in my environment and what version of the agents are running?
From the Lacework Console select Resources > Agents to view the Agent monitor table. This page lists the IP addresses where the agent is running and the version number. Also, the Agent upgrades table lists the agent versions that have generated events in your environment over time.
Can the agent capture command-line arguments from processes that generate no network activity?
If it is inside container, it is captured, provided it is long-lived (> 1 minute).

If it is outside the container, even if it opens a local Unix socket, it is monitored.
If you don't want a process to be monitored, ensure that it meets the following requirements:

  • Be a process that does not do network activity
  • Does not open Unix sockets
  • Is not inside containers
  • Is not a parent (parent group/trace) of any process that is being monitored
  • Is not a login process (like shell)
What is a pod?
A pod defines a running process in Kubernetes and is the smallest entity that can be created or deployed in Kubernetes. A pod is a collection of one or more running containers. For more information, see Pod Overview. A Lacework agent can be deployed in Kubernetes.
How does Lacework calculate the monthly agent usage?
Info: This topic describes the legacy Lacework licensing model. For information on the new pricing and packaging model, see Subscription Management and Billing and Usage.

Lacework calculates the 95th percentile at the end of the month to get the total agent usage for the month. The following example demonstrates how this is calculated.
  1. For each hour, Lacework counts the number of unique agents that sent data to Lacework.
  2. At the end of the month, Lacework records 720 individual hourly agent counts for every hour in the month (assuming a 30-day month, 24 * 30=720). If the month has 31 days, the number of hourly agent counts is 24 * 31 = 744
  3. Lacework sorts the hourly agent counts from lowest to highest and takes the 95th percentile of the 720 hourly counts. That is, Lacework sorts the hourly agent counts in ascending order and picks the 684th hourly agent count number. 684 is the 95th percentile of 720 items. For a 31-day month, it’s the 706th position.
  4. The number of agents for the month is the 95th percentile number calculated above.

For example in a 30-day month, there are the following agent counts per hour, sorted in ascending order.

  1. 500
  2. 500
  3. 504
  4. 504
  5. 505
  6. 505
  7. 505
  8. 506
  9. ….

682. 690
683. 690
684. 691 <---
685. 691
686. ….
720. 1020

The 95th percentile of the monthly agent count is 691 agents and therefore, Lacework charges for 691 agents.

What type of agents are counted towards usage and licensing?
Only ACTIVE agents are counted towards usage and licensing. If the agent cannot send data back to backend, it's shown as INACTIVE in the platform.