How Container Workload Protection Works

CWP is powered by a lightweight integration (Defend for Containers BETA) that is bundled and configured by the Elastic Agent. The agent is installed as a daemonset on supported Kubernetes clusters and the integration uses eBPF LSM and tracepoint probes to produce system events. Events are evaluated against eBPF LSM hook points, enabling a configured policy to be evaluated before system activity is allowed to proceed.

The policy determines which system behaviors (for example, process executions, file creations or deletions, etc) will result in an action. Actions are simple: logging the behavior to Elasticsearch, creating an alert in Elasticsearch, or blocking the behavior.

The system ships with a default policy configured featuring two selectors and responses. The first selector is designed to stream process telemetry events to the user’s Elasticsearch cluster. The policy uses the selector allProcesses which specifies fork and exec operations. This selector is mapped to the allProcesses response, which specifies a log action.

The resulting telemetry data is transformed into an ECS document and streamed back to the user’s Elasticsearch cluster, where the Elastic Security SIEM evaluates the data to detect malicious behavior.

The second selector is written to detect the modification of existing executables or the creation of new executables within a container (This is how Elastic detects “container drift”). The policy selector is named executableChanges and is mapped to a response section called executableChanges which specifies an alert action.

This policy is configured with an alert response, meaning that when drift conditions are detected, the matching event(s) are collected and written as an alert to the user’s Elasticsearch cluster. A prebuilt rule “escalation rule” in the SIEM watches for these alert documents and raises an alert in the SIEM when drift is detected. This policy can also be modified to block drift operations by changing the response action to block.

Users that want to use the full strength of CWP will benefit to understand the system’s policy syntax, which enables fine-grained policies to be constructed. Policies can be built to precisely match expected container behaviors– disallowing any unexpected behaviors– and thereby substantially hardening the security posture of container workloads.

Policies are composed of selectors and responses. A given policy must contain at least one selector and one response. Currently, the system supports two types of selectors and responses, file and process. Selectors tell the service what system operations to match and have a number of conditions that can be grouped together (using a logical AND operation) to provide precise control. Responses instruct the system on what actions to take when system operations match selectors.

The service can be deployed in two ways: declaratively using Elastic Agent in standalone mode, or as a managed D4C integration through Fleet. With the former, teams have the flexibility to integrate their policies into Git for an infrastructure-as-code (IoC) approach, streamlining the deployment process and enabling easier management.

securityContext:
    runAsUser: 0
    # The following capabilities are needed for 'Defend for containers' integration (cloud-defend)
    # If you are using this integration, please uncomment these lines before applying.
    capabilities:
      add:
        - BPF1
        - PERFMON2
        - SYS_RESOURCE3

1. (since Linux 5.8) allows loading of BPF programs, create most map types, load BTF, iterate programs and maps.
2. (since Linux 5.8) allows attaching of BPF programs used for performance metrics and observability operations.
3. Allow use of special resources or raising of resource limits. Used by 'Defend for Containers' to modify 'rlimit_memlock'

A given policy must contain at least one selector (file or process) and one response.

process:
  selectors:
    - name: allProcesses
      operation: [fork, exec]
    - name: interactiveProcesses
      operation: [fork, exec]
      sessionLeaderInteractive: true
  responses:
    - match: [allProcesses]
      actions: [log]
    - match: [interactiveProcesses]
      actions: [alert]
file:
  selectors:
    - name: executableChanges
      operation: [createExecutable, modifyExecutable]
  responses:
    - match: [executableChanges]
      actions: [alert]

Due to the fact that file and process operations happen asynchronously, their selectors and responses must be managed as separate entities. A file selector cannot be used to trigger a process response and vice versa.

A selector tells the service what system operations to match on and has a number of conditions that can be grouped together (using a logical AND operation) to provide precise control.

- name: exampleFileSelector
  operation: [createExecutable, modifyExecutable]
  containerImageName: [nginx]
  containerImageTag: [latest]
  targetFilePath: [/usr/bin/**]
  kubernetesClusterId: [cluster1]
  kubernetesClusterName: [stagingCluster]
  kubernetesNamespace: [default]
  kubernetesPodLabel: [‘production:*’]
  kubernetesPodName: [‘nginx-pod-*’]
  ignoreVolumeMounts: true

A selector MUST contain a name and at least one of the following conditions.

For example, the following selector will match attempts to create executables on any portion of a file system, in any container as long as its Pod has the label environment:production or service:auth*

- name:
  operation: [createExecutable]
  kubernetesPodLabel: [environment:production, service:auth*]

Consider the following selector example:

- name:
  targetFilePath: [/usr/bin/echo, /usr/sbin/*, /usr/local/**]

In this example,

• /usr/bin/echo will match on the echo binary, and only this binary
• /usr/local/** will match on everything recursively under /usr/local/ including /usr/local/bin/something
• /usr/sbin/* includes everything that’s a direct child of /usr/sbin

Responses instruct the system on what actions to take when system operations match selectors.

A policy can contain one or more responses. Each response is comprised of the following:

responses:
  - match: [allProcesses]
    exclude: [excludeSystemDServices]
    actions: [log]
  - match: [nefariousActivity]
    actions: [alert, block]

Consider the following yaml.

file:
  selectors:
    - name: binDirExeMods
      operation:
        - createExecutable
        - modifyExecutable
      targetFilePath:
        - /usr/bin/**
    - name: etcFileChanges
      operation:
        - createFile
        - modifyFile
        - deleteFile
      targetFilePath:
        - /etc/**
    - name: nginx
      containerImageName:
        - nginx

  responses:
    - match:
        - binDirExeMods
        - etcFileChanges
      exclude:
        - nginx
      actions:
        - alert
        - block

We have three file selectors. Two are used to match (logically OR'd), and one to exclude.

This could be read as: If an executable is created or modified under /usr/bin or a file is created, modified or deleted under /etc, block and create an alert as long as it's not an nginx container.

e.g.

IF (binDirExeMods OR etcFileChanges) AND NOT nginx = RUN ACTIONS alert and block

The following fields are populated for all events where event.category: process

The following fields are populated for all events where event.category: file