Container Security with Alert Logic

Alert Logic Managed Detection & Response (MDR) gives you visibility into your containerized workloads, using a combination of container discovery and agent-based data collection. Specific container types, capabilities, and best practices are described in detail below. For answers to common questions about container security, refer to Container Security Frequently Asked Questions. 

Agent Container Features

Like the regular Linux agent, the Alert Logic Agent Container forwards network traffic to the Alert Logic IDS appliance and sends logs directly back to Alert Logic for analysis. In regards to incident content, you can expect container traffic to fire the same kind of incidents as its server-side analog (i.e. you will receive Apache-related incidents from Apache containers).

However, there are a few key differences in functionality to consider. While Alert Logic can run vulnerability scans against the ports exposed by containers, scans cannot be run inside the containers themselves (agent-based scanning). Likewise, flat file collection and file integrity monitoring only function at the host level and are not possible within the containers themselves.

Discovering and Ingesting from Containers

To discover and hook into your containers, Alert Logic uses the built-in container APIs to run the equivalent of commands like docker ps or docker inspect. We stream logs from any discovered containers using the API equivalents of docker logs -f or docker attach. Containers must be set to run in Host network mode so the agent will see the base network interfaces of the node/host.

Similarly, the Agent Container requires privileged mode (superuser access) to enter other containers’ network namespaces and open their network adapters for capture. This is the same level of access used by the Alert Logic Agent for Linux and enables you to only need one copy of the container agent per container instance (instead of running it as a sidecar in each task or pod).

Where privileged mode is a compliance issue, the following individual superuser capabilities (--cap-add) can be used instead of privileged mode:

• SYS_ADMIN (required to enter other containers' namespaces)

• SYS_PTRACE (required to enter other containers' namespaces)

• NET_ADMIN (required to capture traffic from network adapters)

• NET_BIND_SERVICE (required to listen on network ports lower than 1024, if configured by log policy)

However, future versions of the Alert Logic agent might require additional capabilities. Restricting the Agent Container capabilities could break your deployment automation and existing Alert Logic Agent Container deployments following a remote update. Therefore, if you choose to restrict Alert Logic Agent Container's capabilities in this way, you do so at your own risk.

Prerequisites

Before you can deploy the Alert Logic Agent Container, you must deploy and configure your Network IDS appliance.

Note: Alert Logic only supports containers running Linux.

You can deploy the Alert Logic Agent Container on the following container platforms:

Amazon Web Services (AWS)

• Amazon Elastic Container Service for Kubernetes (Amazon EKS)

• Amazon Elastic Container Service (Amazon ECS)

• Amazon ECS using AWS Fargate

• AWS Elastic Beanstalk for Multicontainer Docker Environments

• CoreOS or Bottlerocket OS deployed on AWS EC2 instances

• Docker

• Kubernetes deployed on AWS EC2 instances

Microsoft Azure

• Azure Kubernetes Service (AKS)

• CoreOS on Azure

• Docker

• Kubernetes ACS-Engine

Google Cloud Platform

• Google Kubernetes Engine (GKE)

Data Center

• CoreOS

• OpenShift/OKD

• Docker

• Kubernetes

Runtime Engines

• Docker

• Containerd

• CRI-O

Deploying the Alert Logic Agent Container

Alert Logic hosts the readme files and the agent for each supported container platform on the public Alert Logic GitHub page.

See below for a general diagram of how the container agent works in regular Docker or Kubernetes environments.

Alert Logic Support for AWS ECS Fargate

Security support for the AWS ECS Fargate environment differs because ECS Fargate is a managed environment without access to the underlying container host. Thus, the agent must be deployed as a sidecar in each ECS task running in Fargate. See below for a general diagram of how the container works within ECS Fargate environments.

To learn more about AWS Fargate support, see Deploy the Alert Logic Agent Container for AWS Fargate.

Alert Logic Support for Istio

The Alert Logic Agent Container includes an Istio detector to inspect the traffic between your containers. See below for a general diagram of how this differs from the typical agent container setup in Kubernetes.

To learn more about Istio support, see Istio Support for Containers.

Best Practices

Use X-Forwarded-For Headers Wherever Possible

X-Forwarded-For headers transmit the original IP of the traffic source as it travels through your network. This is helpful as Alert Logic needs to preserve the real source IP of the containers for our incidents to accurately describe evidence, as well as for functionality like our Web Log Analytics to work. Different container technologies and web server types allow you to configure this in different ways.

When to Use the Agent Container vs. Standard Agent

When you have control of the underlying container host, you can use either the agent container or a standard agent. The standard agent is also capable of detecting container workloads on the host.

The main considerations here are typically:

1. Do you want to use flat file ingestion, file integrity monitoring, or agent-based scanning on the underlying host? In this case, the standard agent would grant you that in addition to monitoring your containers' network and log traffic.

2. Do you want to automate the deployment of the agent? Using the agent container allows you to install agents at scale with no manual intervention.

The agent container and the standard agent are mostly interchangeable. You are not able to perform flat file ingestion, file integrity monitoring, or agent-based scanning from within the agent’s container, but aside from these features, the agent container and standard agent are functionally identical. Ultimately, we recommend that our customers use the type of agent packaging that most closely adheres to their specific use case.