Describes how the ZeroLock® Agent (ZA) interacts with containers running on Linux systems.
The following document describes how the ZeroLock Agent (ZA) interacts with containers running on Linux systems. This document addresses a deployment model where ZeroLock Agents are deployed on a bare-metal Linux OS or Linux VM that has containers running inside of it. In this scenario, a single ZA is responsible for protecting a single OS or VM and all containers running on it.
Linux Container Basics
Basic knowledge of how containers are implemented on Linux is helpful to understand how ZeroLock interacts with containers. Processes are actively running executables that have their own virtual address space.
The output to the right shows how processes can be listed on a Linux system using the command ‘ps’.
Linux has a concept called ‘namespaces’ that allows processes to have unique, restricted views of OS resources. Resources that can be restricted by namespaces include, but are not limited to: the filesystem, network stack, and active processes.
Below is an example listing of namespaces on a Linux system using the command lsns. Namespaces with the type “mnt” are mount namespaces that provide processes with unique views of the filesystem, namespaces with the type “net” are network namespaces that restrict what ports and IP addresses a process may use, and namespaces with the type “pid” are process namespaces that restrict what other processes a process can see. 
Containers are implemented using namespaces. Thus, containers are collections of processes that belong to a namespace which provides them with a special, restricted view of OS resources.
ZeroLock and Containers
A ZeroLock Agent consists of two major components, Tyr and Baldur. Baldur is where all the detection and response intelligence is located. Tyr is responsible for ensuring Baldur is healthy, sending commands to Baldur, and receiving telemetry from Baldur.
Baldur detects threats by monitoring the processes running on a system. Baldur is capable of monitoring processes on a Linux system because it injects code into their address space that installs hooks which trigger whenever certain system calls are executed. Examples of system calls that Baldur monitors include execve, open, and connect.
Baldur also monitors the assembly instructions executed by processes on a Linux system. Containers are simply collections of processes that have special namespaces, so Baldur takes the same approach to monitoring them as it does any other process running on a Linux system.
Processes are constantly starting up and shutting down on Linux systems. Baldur monitors when processes are instantiated and when they exit. Because containers are just collections of processes, the ephemeral nature of containers does not have adverse effects on Baldur or alerts produced by Baldur.
ZeroLock Agent Architecture
Baldur is “container-aware” meaning that when it monitors processes in containers, it takes note of their container ID and where the root of the container’s filesystem is located. For example, the file systems for Docker containers and Docker container images are stored in the directory /var/lib/docker/overlay2. Baldur uses this filesystem information when it remediates threats and so is able to restore the filesystem of an attacked container to its clean, pre-attack state.
This container-specific data is aggregated and presented to users in the ZeroLock UI. If an attack occurs inside a container, the container ID is listed at the top of the alert details page.
Container ID in Alert Details Header
If a specific process in an alert’s process tree is selected by a user, detailed information about that process is provided. This detail includes the container ID if one is present.
Container ID in Alert Details
ZeroLock includes a container-aware agent that works seamlessly alongside containerized workloads. ZeroLock provides frictionless container support because, ultimately, containers are just collections of normal Linux processes that have a few special attributes provided by Linux namespaces. ZeroLock tracks those attributes and displays relevant data, such as container IDs, to users in an easy-to-understand format.
ZeroLock and Container Orchestration
“Does ZeroLock work with Kubernetes?” is one of the most common questions when discussing how ZeroLock protects containers. To answer that question, it is important to understand the relationship between containers and orchestration tools, such as Kubernetes, RedHat OpenShift, Rancher/SUSE, VMWare Tanzu, and other similar orchestration tools.
For example, Docker and Kubernetes. Creating containers is the domain of a tool such as Docker. Think of containers as standardized packaging for microservices with all the needed application code and dependencies inside. A container can run anywhere, on a laptop, in the cloud, on local servers, and even on edge devices. Docker tools integrate with code repositories and continuous integration and continuous delivery (CI/CD) pipeline tools to make container operations repeatable and accessible.
A modern application typically consists of many containers potentially allocated across different hardware, networks, or physical locations. Operating containers in production is the job of the orchestration tools, such as Kubernetes. Since containers are easy to replicate, they allow applications to auto-scale: expand or contract processing capacities to match demands made on the application.
Kubernetes is responsible for deploying and managing containerized applications. An application can consist of a few to hundreds of containers that all work together, talk to each other, and that must handle increases and decreases in demand. These multiple containers run on multiple hosts (or clouds) called nodes, and multiple nodes are connected to form a cluster. To be successful, Kubernetes needs to manage these aspects of an application:
- Container deployment: retrieving container images and deploying it on a node, recreating failed containers, and managing the lifecycle of the container.
- Scaling: adding more containers or reducing the number of containers within clusters based on available resources to meet the demands placed on the application.
- Networking: ensuring all the containers that make up an application can communicate securely, services that require external access are properly exposed, and distributing traffic across multiple nodes.
- Observability: track and report on the health of the containers, nodes, clusters, and the overall application.
- Security: encrypting traffic, secret stores, integration into a comprehensive DevSecOps approach.
Kubernetes is also responsible for managing containers within an environment. ZeroLock protects containers as they are deployed, either from the nodes the containers run on or from within the containers themselves. ZeroLock’s container protection capabilities allow it to seamlessly protect containers running in Kubernetes clusters. After all, a container running in a Kubernetes cluster is still just a container!