topic Re: XDR Endpoint with Containers in Cortex XDR Discussions

XDR Endpoint with Containers

tlmarques — Mon, 06 Apr 2026 17:18:52 GMT

Hello, I would like your help to understand what protections I have with Cortex XDR Endpoint Pro on a Linux server running containers/Docker.

Will XDR also protect against malicious activity originating from the container to the network, or is it more of a black box?

Re: XDR Endpoint with Containers

susekar — Mon, 06 Apr 2026 17:25:26 GMT

Hello @tlmarques ,

Greetings for the day.

Cortex XDR Endpoint Pro provides comprehensive protection for Linux servers running Docker by operating at the host kernel level. It is not a “black box”; rather, it extends the same security modules used for the host OS to all processes running within containers.

Protection and Visibility Scope:

The agent uses deep hooks into the host kernel to monitor system calls (syscalls), providing visibility into activities inside containers without requiring an agent to be installed in each individual container.

Process Protection: The agent monitors and protects all containerized processes using standard Exploit and Malware protection modules.
File System Monitoring: It tracks file access and modifications within containers. Recent versions (Agent 8.5.0+) have enhanced visibility for file system activity in container environments.
Container-Specific Security: Includes a dedicated Container Escaping Protection module designed to detect and block attempts by a process to break out of a container to the host.
Vulnerability Scanning: Starting with agent version 8.4, the Advanced Vulnerability Analysis (AVA) feature can scan running Docker containers for vulnerabilities directly on the host.

Network-Level Protection:

Cortex XDR is not a “black box” regarding network activity. It monitors network traffic originating from containers and can block or report malicious behavior.

Behavioral Threat Protection (BTP): BTP and Analytics rules detect malicious network patterns, such as command-and-control (C2) communication or cryptocurrency mining protocols (e.g., Stratum) originating from containerized processes.
Reverse Shell Protection: This module blocks attempts to redirect standard input/output streams to network sockets, preventing attackers from gaining remote shell access via a container.
Host Firewall: You can configure Host Firewall policies to enforce network rules directly on the endpoint, allowing you to block outbound traffic from the server (including its containers) to specific malicious IP addresses.

Limitations:

Does not provide full network segmentation (this requires Prisma Cloud).
Does not perform direct URL filtering at the network layer (typically handled by a Next-Generation Firewall).

If you feel this has answered your query, please let us know by clicking like and on "mark this as a Solution".

Thanks & Regards,
S. Subashkar Sekar

Re: XDR Endpoint with Containers

tlmarques — Mon, 06 Apr 2026 18:04:22 GMT

Hi @susekar ,

I appreciate your response. I understand that Cortex XDR is not a “black box” — my question is specifically about containers running inside the host.

I have a Linux server with an XDR Pro license, and inside this host there are multiple containers. My questions are:

What level of protection do we have for workloads running inside containers?
Do we need an additional license for container protection, or is XDR Endpoint Pro sufficient?
If a malicious script is executed inside a container, will XDR detect and respond to it?

Re: XDR Endpoint with Containers

susekar — Mon, 06 Apr 2026 19:09:55 GMT

Hello @tlmarques ,

Thank you for the response.

Cortex XDR provides comprehensive visibility and protection for containerized workloads on Linux hosts by operating at the host kernel level. When the agent is installed on the underlying Linux host, it automatically extends its monitoring and prevention capabilities to all containers sharing that kernel, such as Docker or Podman, without requiring an agent inside each container.

1. Workload Protection Levels:

Workloads running inside containers receive the same level of security as processes running natively on the host. This includes:

Runtime Protection & EDR: Real-time monitoring of containerized processes and their activities.
Visibility: Telemetry collection for network traffic originating from containers and file system activity within container environments (enhanced in Agent 8.5.0 and later).
Vulnerability Scanning: Starting with agent version 8.4, the Advanced Vulnerability Analysis (AVA) feature can scan running Docker containers for known vulnerabilities.
Container-Escaping Protection: Specific Behavioral Threat Protection (BTP) modules are designed to detect and block attempts to escape the container and compromise the host.

2. Licensing Requirements:

The license required depends on whether the containers are part of an orchestrated environment:

Non-orchestrated Containers (e.g., Docker/Podman on a standalone server):
The Cortex XDR Pro per Endpoint license is sufficient. A single license covers the host and all its containers.
Orchestrated Environments (e.g., Kubernetes/OpenShift):
These environments require a Cortex XDR Cloud per Host license for full support and visibility.

To verify the agent is correctly monitoring the host and its containers, you can use the following command on the Linux server:
/opt/traps/bin/cytool runtime query

If you feel this has answered your query, please let us know by clicking like and on "mark this as a Solution".

Thanks & Regards,
S. Subashkar Sekar

Re: XDR Endpoint with Containers

tlmarques — Tue, 07 Apr 2026 08:56:06 GMT

@susekar thanks a lot for your help.

I have one final question regarding the differences between non-orchestrated containers and orchestrated environments (e.g., Kubernetes/OpenShift).

Is the main difference related to visibility inside containers?

For example, if I have a Rocky Linux server with Cortex XDR Endpoint Pro installed, and I’m running OpenShift on top of it:

What level of protection do I have?
What capabilities am I missing compared to a fully supported/orchestrated scenario?

On my system, I currently see the following components running:

pmd
clad
dypd
sandboxd
lted
pyxd
cned (stopped)
piud (stopped)

Based on what I’ve read, my understanding is that my Linux host (and, to some extent, the containers running on it) is protected against:

Known and unknown malware (via WildFire and Local Analysis)
Exploits of vulnerabilities (via pmd)
Suspicious behavior / ransomware (via dypd)
Remote access for investigation (via lted)

Is this understanding correct?

Re: XDR Endpoint with Containers

susekar — Tue, 07 Apr 2026 13:13:53 GMT

Hello @tlmarques ,

Thank you for the response.

1. Visibility and Protection: Non-Orchestrated vs. Orchestrated:

While visibility is a key differentiator, the differences between these two scenarios also involve licensing, deployment architecture, and metadata enrichment.

Visibility:
Both deployment types (standard Linux agent and Kubernetes DaemonSet) operate at the host kernel level, allowing them to see containerized processes, network traffic, and file system activity.

The Main Difference (Orchestration):
In an orchestrated environment (Kubernetes/OpenShift), the agent is deployed as a DaemonSet. This provides orchestration metadata (cluster name, pod name, Kubernetes namespace) in the Cortex XDR console and alerts, which is not available when using a standard host agent.

Licensing:
Orchestrated environments require a Cortex XDR Cloud per Host license. If a standard "Pro per Endpoint" license is used on a node running an orchestrator, the agent may identify the host as a Kubernetes node and display a "Partially Protected" or "Unprotected" status because it expects the cloud license.

---------------------------------

2. Level of Protection and Missing Capabilities:

Running OpenShift on top of a standard Rocky Linux agent installation provides host-level security, but the following capabilities are likely missing:

Kubernetes Metadata:
Container processes appear in the Causality Card, but they are associated with the host endpoint name rather than specific pods or namespaces.

Posture Management (KSPM):
Full orchestration support typically includes the Kubernetes Connector, which provides cloud security posture management (identifying misconfigurations). The XDR agent alone provides only runtime protection.

Lifecycle Management:
Orchestrated agents follow an accelerated lifecycle cleanup policy, automatically deleting inactive agents from the inventory after 6 hours to prevent clutter in dynamic environments.

-----------------------------------------

3. Running Components (Daemons):

Your understanding of the running components is largely correct. Here is the breakdown:

Daemon	Function
pmd	Policy Management Daemon: Handles policy application, process injection, and forensic reporting
clad	Cortex Local Analysis Daemon: Responsible for local malware analysis of files
dypd	Dynamic Protection Daemon: Powers Behavioral Threat Protection (BTP) to stop suspicious behavior and ransomware
sandboxd	Sandbox Daemon: Used for local analysis/emulation of suspicious files
lted	Live Terminal Engine Daemon: Enables remote investigation and response actions
pyxd	Python Executor: Executes scripts and payloads for response actions
cned (stopped)	Cortex Network Engine Daemon: Introduced in v8.7; expected to be stopped if features are not active
piud (stopped)	Post Installation Upgrade Daemon: Introduced in v8.7; expected to be stopped if not in use

4. Verification of Protection Scope:

Your summary of the protection areas is correct:

Known and unknown malware: Protected via WildFire (cloud) and local analysis (clad)
Exploits: Protected via the Policy Management Daemon (pmd), which manages Exploit Protection Modules (EPMs)
Suspicious behavior / ransomware: Protected via Behavioral Threat Protection (BTP) managed by dypd
Remote access for investigation: Enabled via the Live Terminal Engine (lted)

Recommendation:

For a production OpenShift environment, it is strongly recommended to switch to the Cortex XDR Cloud per Host license and deploy the agent as a DaemonSet using the Kubernetes YAML or Helm installer to ensure full compatibility and visibility.

If you feel this has answered your query, please let us know by clicking like and on "mark this as a Solution".

Thanks & Regards,
S. Subashkar Sekar