Get started with CWP

[beta] This functionality is in beta and is subject to change. The design and code is less mature than official GA features and is being provided as-is with no warranties. Beta features are not subject to the support SLA of official GA features.

This page describes how to set up Cloud Workload Protection (CWP) for Kubernetes.

Requirements

Kubernetes node operating systems must have Linux kernels 5.10.16 or higher.

Initial setup

edit

First, you’ll need to deploy Elastic’s Defend for Containers integration to the Kubernetes clusters you wish to monitor.

Find Container Workload Security in the navigation menu or use the global search field. Click Add D4C Integration.
Name the integration. The default name, which you can change, is cloud_defend-1.
Optional — make any desired changes to the integration’s policy by adjusting the Selectors and Responses sections. (For more information, refer to the Defend for Containers policy guide). You can also change these later.
Under Where to add this integration, select an existing or new agent policy.
Click Save & Continue, then Add Elastic Agent to your hosts.
On the Elastic Agent policy page, click Add agent to open the Add agent flyout.
In the flyout, go to step 3 (Install Elastic Agent on your host) and select the Kubernetes tab.
Download or copy the manifest (elastic-agent-managed-kubernetes.yml).

Open the manifest using your favorite editor, and uncomment the #capabilities section:

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

From the directory where you saved the manifest, run the command kubectl apply -f elastic-agent-managed-kubernetes.yml.
Wait for the Confirm agent enrollment dialogue to show that data has started flowing from your newly-installed agent, then click Close.

Get started with threat detection

edit

One of the default D4C policies sends process telemetry events (fork and exec) to Elasticsearch.

In order to detect threats using this data, you’ll need active detection rules. Elastic has prebuilt detection rules designed for this data. (You can also create your own custom rules.)

To install and enable the prebuilt rules:

Find Detection rules (SIEM) in the navigation menu or use the global search field, then click Add Elastic rules.
Click the Tags filter next to the search bar, and search for the Data Source: Elastic Defend for Containers tag.
Select all the displayed rules, then click Install x selected rule(s).
Return to the Rules page. Click the Tags filter next to the search bar, and search for the Data Source: Elastic Defend for Containers tag.
Select all the rules with the tag, and then click Bulk actions → Enable.

Get started with drift detection and prevention

edit

Elastic Security defines container drift as the creation or modification of an executable within a container. Blocking drift restricts the number of attack vectors available to bad actors by prohibiting them from using external tools.

To enable drift detection, you can use the default D4C policy:

Make sure the default D4C policy is active.
Make sure you enabled at least the "Container Workload Protection" rule, by following the steps to install prebuilt rules, above.

To enable drift prevention, create a new policy:

Find Container Workload Security in the navigation menu or use the global search field, then select your integration.
Under Selectors, click Add selector → File Selector. By default, it selects the operations createExecutable and modifyExecutable.
Name the selector, for example: blockDrift.
Scroll down to the Responses section and click Add response → File Response.
Under Match selectors, add the name of your new selector, for example: blockDrift.
Select the Alert and Block actions.
Click Save integration.

Before you enable blocking, we strongly recommend you observe a production workload that’s using the default D4C policy to ensure that the workload does not create or modify executables as part of its normal operation.

Policy validation

edit

To ensure the stability of your production workloads, you should test policy changes before implementing them in production workloads. We also recommend you test policy changes on a simulated environment with workloads similar to production. This approach allows you to test that policy changes prevent undesirable behavior without disrupting your production workloads.

« Container workload protection Container workload protection policies »